Mail Archives: geda-user/2017/02/10/15:31:39
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--8323329-1008734977-1486758559=:1490
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8BIT
On Fri, 10 Feb 2017, John Griessen (john AT ecosensory DOT com) [via
geda-user AT delorie DOT com] wrote:
> gnetlist -g drc2 kvboard.sch
> kvboard.sch:487x454: error: could not find refdes on component and could
> not find net= attribute on pin
>
> It gives no clue as to which symbol has problems...
As the error message says, the refdes is missing, so there is no command
line-friendly way to specify which symbol it is. “kvboard.sch:487x454”
means that the offending symbol was found in kvboard.sch at coordinate
487x454 (an information which I added to the error message).
You probably either removed the refdes= attribute of a component by
accident, or you created a power symbol (which doesn't has a refdes) and
didn't set a net= attribute on its pin, so the power symbol doesn't work.
> When I use Vladimir's fork:
>
> Could not find refdes on component and could not find any special attributes!
> Possible attribute conflict for refdes: T1
> name: numslots
> values: (#f 0)
> Possible attribute conflict for refdes: T1
> name: numslots
> values: (#f 0)
> DRC errors found. See output file.
The other messages are unrelated to this error. In fact, they are
misleading because they state a non-error (the numslot= attribute being
set on one component of a package and not on another).
> cat output.net
> Checking non-numbered parts...
> ERROR: Reference not numbered: U?
>
> […]
This won't help you because “U?” is just the way gnetlist used to tell you
it doesn't know the refdes. It could also be that you added a component
and forgot to change the default refdes from “U?”; with the old version of
gnetlist, you can't tell.
> So, the conversion of gnetlist to python has left out a lot of usefulness.
As you can see, it hasn't. However, your mail makes me aware of one thing
I haven't thought about before: gnetlist doesn't touch the output file any
more if there were netlisting errors because the generated file is
probably broken and shouldn't replace the old file. For DRC backends,
however, it is probably desireable to overwrite the existing output even
if there were errors.
How do you suggest solving this? Should a backend whose name starts with
“drc” always force an output file to be generated, even if there have been
netlisting errors?
> so I'm using https://github.com/vzh/geda-gaf/tree/unstable-1.9
The old version of gnetlist is still there in case you need it. To enable
it, just add (set! use-legacy-frontend #t) to your gnetlistrc file.
--8323329-1008734977-1486758559=:1490--
- Raw text -