gEDA-user: ERROR: Unconnected pin U83:3
I am running the drc2 file on my schematic. I am seeing a number of unconnected pins on my ICs. This makes some sense, as the pins are unconnected. Unfortunately these pins are not that important in comparison to other unconnected pins. I think it would be useful to flag in the output the pin type is of unconnected pin, and or not treat it as an error. This makes it easier to spot worse mistakes, such as failing to connect the power! I added the two lines below: (display "Unconnected pin " port) (display ref port) (display ":" port) (display pin port) ;; Start new lines (display " (of type) " port) (display (gnetlist:get-attribute-by-pinnumber ref pin "pintype") port) ;; End new lines (newline port) and now get the output ERROR: Unconnected pin U89:1 (of type) pas ERROR: Unconnected pin U89:3 (of type) in ERROR: Unconnected pin U89:4 (of type) in ERROR: Unconnected pin U89:6 (of type) in ERROR: Unconnected pin U83:1 (of type) pwr ERROR: Unconnected pin U83:3 (of type) unconnected ERROR: Unconnected pin U83:4 (of type) unconnected ERROR: Unconnected pin U83:5 (of type) unconnected ERROR: Unconnected pin U83:6 (of type) unconnected ERROR: Unconnected pin U83:7 (of type) unconnected ERROR: Unconnected pin U83:19 (of type) unconnected ERROR: Unconnected pin U83:20 (of type) unconnected ERROR: Unconnected pin U83:21 (of type) unconnected ERROR: Unconnected pin U83:22 (of type) unconnected ERROR: Unconnected pin U83:23 (of type) unconnected ERROR: Unconnected pin U83:25 (of type) unconnected ERROR: Unconnected pin U83:26 (of type) unconnected ERROR: Unconnected pin U83:27 (of type) unconnected ERROR: Unconnected pin U68:3 (of type) pas ERROR: Unconnected pin U68:7 (of type) pas ERROR: Unconnected pin U67:3 (of type) pas ERROR: Unconnected pin U67:7 (of type) pas ERROR: Unconnected pin U66:3 (of type) pas ERROR: Unconnected pin U66:7 (of type) pas ERROR: Unconnected pin U64:3 (of type) pas ERROR: Unconnected pin U64:7 (of type) pas ERROR: Unconnected pin STAND4:1 (of type) pas ERROR: Unconnected pin STAND3:1 (of type) pas ERROR: Unconnected pin STAND2:1 (of type) pas ERROR: Unconnected pin STAND1:1 (of type) pas ERROR: Unconnected pin U52:3 (of type) in ERROR: Unconnected pin U52:6 (of type) out ERROR: Unconnected pin U51:5 (of type) in ERROR: Unconnected pin U51:6 (of type) oc ERROR: Unconnected pin U51:13 (of type) in ERROR: Unconnected pin U51:12 (of type) oc ERROR: Unconnected pin U51:11 (of type) in ERROR: Unconnected pin U51:10 (of type) oc ERROR: Unconnected pin U51:9 (of type) in ERROR: Unconnected pin U51:8 (of type) oc ERROR: Unconnected pin U46:3 (of type) in ERROR: Unconnected pin U46:6 (of type) out ERROR: Unconnected pin U45:4 (of type) in ERROR: Unconnected pin U45:5 (of type) in ERROR: Unconnected pin U45:6 (of type) out ERROR: Unconnected pin U44:13 (of type) in ERROR: Unconnected pin U44:12 (of type) in ERROR: Unconnected pin U44:11 (of type) out ERROR: Unconnected pin U44:10 (of type) in ERROR: Unconnected pin U44:9 (of type) in ERROR: Unconnected pin U44:8 (of type) out ERROR: Unconnected pin U39:CN2-16 (of type) io ERROR: Unconnected pin U39:CN2-22 (of type) io ERROR: Unconnected pin U39:CN3-18 (of type) io ERROR: Unconnected pin U39:CN3-6 (of type) out ERROR: Unconnected pin U39:CN3-8 (of type) in ERROR: Unconnected pin U39:CN2-15 (of type) io ERROR: Unconnected pin U39:CN3-5 (of type) out ERROR: Unconnected pin U39:CN3-7 (of type) io ERROR: Unconnected pin U39:CN2-25 (of type) io ERROR: Unconnected pin U38:13 (of type) out ERROR: Unconnected pin U38:12 (of type) out ERROR: Unconnected pin U38:11 (of type) out ERROR: Unconnected pin U19:1 (of type) unconnected ERROR: Unconnected pin U19:8 (of type) unconnected ERROR: Unconnected pin U19:5 (of type) unconnected ERROR: Unconnected pin U18:1 (of type) unconnected ERROR: Unconnected pin U18:8 (of type) unconnected ERROR: Unconnected pin U18:5 (of type) unconnected ERROR: Unconnected pin U10:28 (of type) io ERROR: Unconnected pin U10:27 (of type) io ERROR: Unconnected pin U10:26 (of type) io ERROR: Unconnected pin U10:25 (of type) io ERROR: Unconnected pin U1:28 (of type) io ERROR: Unconnected pin U1:27 (of type) io ERROR: Unconnected pin U1:26 (of type) io ERROR: Unconnected pin U1:25 (of type) io Oliver ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: How to make a mask similar to soldermask (not containing any via circles)
I want to define a zone for gold plating. If I put a polygon on a layer it makes the layer included in all the vias. How do I make it not create via circles on this extra layer I defined? Or, how to define a layer that doesn't get via circles? John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: adding information to gerber output, anyone?
On Wed, 09 Feb 2011 23:29:52 +0100 myken wrote: > Hello all, > > I didn't see any reply on my question so I guess the very busy and > overloaded knowledge base of this list didn't find the time to look > at it, so please consider this a friendly reminder ;-) > > Or am I asking a very silly question? (didn't find a answer by google) > > The question was: > I was wondering if it is possible to add more information to the > fabrication layer output of the gerber export (*.fab). > Added: I like to do this through PCB, is there a variable I need to > set? Or a command executed? So that every time the gerber is > generated by PCB this information is stored automatically in the > gerber fabrication layer output file. > I like to add the copper thickness for that specific pcb (preferably > for ever layer individually (inner/outer layer)). > So far I came up with adding this information to the outline layer > (but that doesn't end up in t A text on copper layers? Outside the board area? -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: PCB: adding information to gerber output, anyone?
There's no standard way to add information to the gerbers. However, if you want to hack your PCB to append information from a specifically-named layer to the fab output (and otherwise ignore that layer), go ahead. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: PCB: adding information to gerber output, anyone?
Hello all, I didn't see any reply on my question so I guess the very busy and overloaded knowledge base of this list didn't find the time to look at it, so please consider this a friendly reminder ;-) Or am I asking a very silly question? (didn't find a answer by google) The question was: I was wondering if it is possible to add more information to the fabrication layer output of the gerber export (*.fab). Added: I like to do this through PCB, is there a variable I need to set? Or a command executed? So that every time the gerber is generated by PCB this information is stored automatically in the gerber fabrication layer output file. I like to add the copper thickness for that specific pcb (preferably for ever layer individually (inner/outer layer)). So far I came up with adding this information to the outline layer (but that doesn't end up in the fab-file). Thanks, Robert. Sorry for pinging again. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: drc2 crash
- Original message - > I am attempting to run the drc2 check with gnetlist. I have checked > each individual schematic separately, and drc2 works fine. But when I > tried to run them altogether I am getting the following crash: Stack overflows in gnetlist should never occur in 1.7.0 or later. If you encounter a stack overflow in unstable, please file a specific bug report. In 1.6.x, the stack size increase workaround is required. Peter -- Peter Brett Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: drc2 crash
Oliver King-Smith wrote: > ;; Give us more stack space > (debug-set! stack 20) Sigh. This is the second long standing non-feature in gnetlist that proves to be a newbie trap. It hit me twice over the years. The workaround to to this illness was on the gnetlist FAQ since it has been moved to dokuwiki in 2006: http://geda.seul.org/wiki/geda:faq-gnetlist?rev=0#some_gnetlist_backends_overflow_the_stack_how_do_i_solve_this I filed a fresh, new launchpad bug report: https://bugs.launchpad.net/geda/+bug/716051 ---<)kaimartin(>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Abuse of "reply" considered harmful: how to post to a mailing list
Colin D Bennett wrote: > (If you haven't tried a threaded view, I do recommend it!) +1 BTW, the geda mailing lists are mirrored at gmane.org. Usenet newsreaders are geared to discussions with many participants. So gmane provides a way to get the most of the list. The name of this list on the gmane server is: gmane.comp.cad.geda.user ---<)kaimartin(>--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmk&op=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Abuse of "reply" considered harmful: how to post to a mailing list
To all participants on the geda-user mailing list who wish to begin a new thread of discussion: Whenever you intend to post a message to begin a *new* thread of discussion, do not use the "reply" feature of your e-mail application to do so. Instead, click the "To: gEDA user mailing list " address in another message from the list, or manually compose your new message to "geda-user@moria.seul.org". The "reply" feature is great for capturing the context of a reply because it includes a reference to the original message. The problem with improper use of the "reply" feature is that it clutters the existing thread of discussion with an unrelated, separate thread. There are two negative effects when you use "reply" as a way to post message that is not in fact a reply: (1) To your own detriment, your message is likely to be skipped over by people who are uninterested in the thread to which it was added as a reply. (2) To the detriment of others, it clutters the existing thread of conversation and makes it harder to follow the discussion for other readers. If you don't use a "threaded" view (where messages are displayed as a tree, having each reply as a child of the message to which it is replying), the effects of the "reply" feature are generally not apparent, so this is just a reminder that many readers (and web archives of the list) do read the list in a threaded presentation. (If you haven't tried a threaded view, I do recommend it!) Regards, Colin P.S. I debated whether this message should be a "reply"... ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: drc2 crash
On Feb 9, 2011, at 9:30 AM, Oliver King-Smith wrote: > OK I have fixed my problem (well my scheme problem at least) by adding > this line to the beginning of the gnet-drc2.scm file: > ;; Give us more stack space > (debug-set! stack 20) > I don't know if there is a better fix. I think most of us put that in a gnetlistrc file rather than editing the problematic back end code. But yes, that's the fix. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gattrib not showing part_numbers
On Feb 9, 2011, at 8:48 AM, Oliver King-Smith wrote: > So gnetlist does not know which schematic file it is operating on when > it is processing data? That's just one of many kinds of information a gnetlist back end cannot access. The front end thoroughly digests the input, and only presents certain summaries of it to the back end. That's why we've been working on a tool for more general processing of gEDA schematics at Noqsi Aerospace: https://github.com/xcthulhu/lambda-geda. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: drc2 crash
OK I have fixed my problem (well my scheme problem at least) by adding
this line to the beginning of the gnet-drc2.scm file:
;; Give us more stack space
(debug-set! stack 20)
I don't know if there is a better fix.
Oliver
__
From: Oliver King-Smith
To: gEDA user mailing list
Sent: Wed, February 9, 2011 7:47:29 AM
Subject: gEDA-user: drc2 crash
I am attempting to run the drc2 check with gnetlist. I have checked
each individual schematic separately, and drc2 works fine. But when
I
tried to run them altogether I am getting the following crash:
In /sw/share/gEDA/scheme/gnet-drc2.scm:
518: 647 (if (null? list) 0 ...)
...
525: 648 [+ 0 ...
525: 649* [drc2:count-reference-in-list "FB17" ("R116" "C177"
"C176"
...)]
518: 650 (if (null? list) 0 ...)
...
525: 651 [+ 0 ...
525: 652* [drc2:count-reference-in-list "FB17" ("C177" "C176"
"J36"
...)]
518: 653(if (null? list) 0 ...)
...
525: 654[+ 0 ...
525: 655*[drc2:count-reference-in-list "FB17" ("C176" "J36"
"R115"
...)]
518: 656(if (null? list) 0 ...)
...
525: 657[+ 0 ...
525: 658*[drc2:count-reference-in-list "FB17" ("J36" "R115"
"C175" ...)]
518: 659 (if (null? list) 0 ...)
...
525: 660 [+ 0 ...
525: 661* [drc2:count-reference-in-list "FB17" ("R115" "C175"
"R114" ...)]
518: 662 (if (null? list) 0 ...)
520: 663 (let* ((comparison #)) (if comparison (+ 1 #) (+ 0
#)))
520: 664* (if (defined? #) (string-ci=? refdes #) (string=?
refdes #))
520: 665* [defined? ...
520: 666* (quote case_insensitive)
/sw/share/gEDA/scheme/gnet-drc2.scm:520:42: In expression (quote
case_insensitive):
/sw/share/gEDA/scheme/gnet-drc2.scm:520:42: Stack overflow
This appears to me to be a genuine stack overflow. That is the in
the
line
(+ 0 (drc2:count-reference-in-list refdes (cdr list
my list is so long it is crashing gnetlist. I suspect this is
getting
called from line 538:
(if (> (drc2:count-reference-in-list refdes
(gnetlist:get-non-unique-packages ""))
In my case:
guile> ( gnetlist:get-non-unique-packages "")
("FB17" "J66" "R182" "R181" "R180" "C249" "C248" "C247" "C246" "C245"
"C244" "U89" "C243" "C242" "C241" "C240" "R179" "U88" "C239" "C238"
"R178" "U87" "J65" "J64" "U86" "C237" "C236" "R177" "R176" "J63"
"R175"
"C235" "R174" "C234" "FB16" "J62" "U85" "Q12" "R173" "U84" "R172"
"R171" "J61" "R170" "C233" "R169" "C232" "C231" "C230" "C229" "C228"
"C227" "C226" "C225" "C224" "C223" "C222" "C221" "C220" "C219" "FB15"
"FB14" "C218" "C217" "J60" "C216" "J59" "U83" "C215" "C214" "J58"
"U82"
"R168" "R167" "R166" "J57" "J56" "J55" "J54" "J53" "J52" "R165"
"R164"
"U81" "C213" "Q11" "R163" "U80" "R162" "R161" "R160" "J51" "R159"
"C212" "R158" "Q10" "Q9" "R157" "R156" "U79" "U78" "C211" "C210"
"C209"
"C208" "C207" "R155" "R154" "J50" "R153" "C206" "R152" "U77" "J49"
"R151" "R150" "R149" "R148" "J48" "R147" "C205" "R146" "U76" "U75"
"R145" "R144" "Q8" "Q7" "R143" "R142" "U74" "U73" "C204" "C203"
"C202"
"C201" "C200" "R141" "R140" "J47" "R139" "C199" "R138" "U72" "J46"
"R137" "R136" "R135" "C198" "FB13" "J45" "R134" "J44" "R133" "C197"
"R132" "U71" "U70" "CONN4" "J43" "J42" "R131" "R130" "J41" "J40"
"C196"
"FB12" "J39" "C195" "FB11" "J38" "U69" "R129" "R128" "C194" "C193"
"C192" "C191" "U68" "R127" "R126" "C190" "C189" "C188" "C187" "U67"
"R125" "R124" "C186" "C185" "C184" "C183" "U66" "R123" "R122" "C182"
"C181" "C180" "C179" "U65" "C178" "CONN3" "CONN2" "CONN1" "U64" "Q6"
"R121" "U63" "R120" "R119" "R118" "R117" "J37" "R116" "C177" "C176"
"J36" "R115" "C175" "R114" "J35" "R113" "C174" "R112" "J34" "R111"
"C173" "C172" "C171" "FB10" "J33" "U62" "U61" "TP8" "TP7" "TP6" "TP5"
"TP4" "TP3" "TP2" "TP1" "STAND4" "STAND3" "STAND2" "STAND1" "R110"
"Q5"
"R109" "U60" "R108" "R107" "R106" "Q4" "R105" "U59" "R104" "R103"
"R102" "C170" "C169" "C168" "R101" "J32" "U58" "J31" "R100" "C167"
"C166" "FB9" "J30" "J29" "R99" "C165" "C163" "C162" "C161" "C160"
"C159" "C158" "C157" "C156" "C155" "C154" "C153" "C152" "C151" "C150"
"C149" "C148" "C147" "C146" "C145" "C144" "C143" "C142" "C141" "C140"
"C139" "C138" "C137" "C136" "C135" "C134" "C133" "C132" "C131" "C130"
"FB8" "J28" "C129" "FB7" "J27" "U57" "U56" "U55" "U54" "U53" "U52"
"R98" "U51" "U50" "U49" "U48" "U47" "U46" "U45" "U44" "R97" "J26"
"J25"
"U43" "U42" "U41" "R96" "R95" "R94" "R93" "J24" "U40" "U39" "C128"
"C127" "C126" "C125" "R92" "R91" "
Re: gEDA-user: gattrib not showing part_numbers
So gnetlist does not know which schematic file it is operating on when it is processing data? Oliver __ From: John Doty To: gEDA user mailing list Sent: Wed, February 9, 2011 6:48:02 AM Subject: Re: gEDA-user: gattrib not showing part_numbers On Feb 9, 2011, at 7:38 AM, Oliver King-Smith wrote: > It seems like gnetlist could be used to "promote" an attribute to the > schematic. No. Gnetlist can't do that kind of schematic to schematic translation. John Doty Noqsi Aerospace, Ltd. [1]http://www.noqsi.com/ [2]j...@noqsi.com ___ geda-user mailing list [3]geda-user@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. http://www.noqsi.com/ 2. mailto:j...@noqsi.com 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: drc2 crash
I am attempting to run the drc2 check with gnetlist. I have checked
each individual schematic separately, and drc2 works fine. But when I
tried to run them altogether I am getting the following crash:
In /sw/share/gEDA/scheme/gnet-drc2.scm:
518: 647 (if (null? list) 0 ...)
...
525: 648 [+ 0 ...
525: 649* [drc2:count-reference-in-list "FB17" ("R116" "C177" "C176"
...)]
518: 650 (if (null? list) 0 ...)
...
525: 651 [+ 0 ...
525: 652* [drc2:count-reference-in-list "FB17" ("C177" "C176" "J36"
...)]
518: 653(if (null? list) 0 ...)
...
525: 654[+ 0 ...
525: 655*[drc2:count-reference-in-list "FB17" ("C176" "J36" "R115"
...)]
518: 656 (if (null? list) 0 ...)
...
525: 657 [+ 0 ...
525: 658* [drc2:count-reference-in-list "FB17" ("J36" "R115"
"C175" ...)]
518: 659 (if (null? list) 0 ...)
...
525: 660 [+ 0 ...
525: 661* [drc2:count-reference-in-list "FB17" ("R115" "C175"
"R114" ...)]
518: 662 (if (null? list) 0 ...)
520: 663 (let* ((comparison #)) (if comparison (+ 1 #) (+ 0 #)))
520: 664* (if (defined? #) (string-ci=? refdes #) (string=?
refdes #))
520: 665* [defined? ...
520: 666* (quote case_insensitive)
/sw/share/gEDA/scheme/gnet-drc2.scm:520:42: In expression (quote
case_insensitive):
/sw/share/gEDA/scheme/gnet-drc2.scm:520:42: Stack overflow
This appears to me to be a genuine stack overflow. That is the in the
line
(+ 0 (drc2:count-reference-in-list refdes (cdr list
my list is so long it is crashing gnetlist. I suspect this is getting
called from line 538:
(if (> (drc2:count-reference-in-list refdes
(gnetlist:get-non-unique-packages ""))
In my case:
guile> ( gnetlist:get-non-unique-packages "")
("FB17" "J66" "R182" "R181" "R180" "C249" "C248" "C247" "C246" "C245"
"C244" "U89" "C243" "C242" "C241" "C240" "R179" "U88" "C239" "C238"
"R178" "U87" "J65" "J64" "U86" "C237" "C236" "R177" "R176" "J63" "R175"
"C235" "R174" "C234" "FB16" "J62" "U85" "Q12" "R173" "U84" "R172"
"R171" "J61" "R170" "C233" "R169" "C232" "C231" "C230" "C229" "C228"
"C227" "C226" "C225" "C224" "C223" "C222" "C221" "C220" "C219" "FB15"
"FB14" "C218" "C217" "J60" "C216" "J59" "U83" "C215" "C214" "J58" "U82"
"R168" "R167" "R166" "J57" "J56" "J55" "J54" "J53" "J52" "R165" "R164"
"U81" "C213" "Q11" "R163" "U80" "R162" "R161" "R160" "J51" "R159"
"C212" "R158" "Q10" "Q9" "R157" "R156" "U79" "U78" "C211" "C210" "C209"
"C208" "C207" "R155" "R154" "J50" "R153" "C206" "R152" "U77" "J49"
"R151" "R150" "R149" "R148" "J48" "R147" "C205" "R146" "U76" "U75"
"R145" "R144" "Q8" "Q7" "R143" "R142" "U74" "U73" "C204" "C203" "C202"
"C201" "C200" "R141" "R140" "J47" "R139" "C199" "R138" "U72" "J46"
"R137" "R136" "R135" "C198" "FB13" "J45" "R134" "J44" "R133" "C197"
"R132" "U71" "U70" "CONN4" "J43" "J42" "R131" "R130" "J41" "J40" "C196"
"FB12" "J39" "C195" "FB11" "J38" "U69" "R129" "R128" "C194" "C193"
"C192" "C191" "U68" "R127" "R126" "C190" "C189" "C188" "C187" "U67"
"R125" "R124" "C186" "C185" "C184" "C183" "U66" "R123" "R122" "C182"
"C181" "C180" "C179" "U65" "C178" "CONN3" "CONN2" "CONN1" "U64" "Q6"
"R121" "U63" "R120" "R119" "R118" "R117" "J37" "R116" "C177" "C176"
"J36" "R115" "C175" "R114" "J35" "R113" "C174" "R112" "J34" "R111"
"C173" "C172" "C171" "FB10" "J33" "U62" "U61" "TP8" "TP7" "TP6" "TP5"
"TP4" "TP3" "TP2" "TP1" "STAND4" "STAND3" "STAND2" "STAND1" "R110" "Q5"
"R109" "U60" "R108" "R107" "R106" "Q4" "R105" "U59" "R104" "R103"
"R102" "C170" "C169" "C168" "R101" "J32" "U58" "J31" "R100" "C167"
"C166" "FB9" "J30" "J29" "R99" "C165" "C163" "C162" "C161" "C160"
"C159" "C158" "C157" "C156" "C155" "C154" "C153" "C152" "C151" "C150"
"C149" "C148" "C147" "C146" "C145" "C144" "C143" "C142" "C141" "C140"
"C139" "C138" "C137" "C136" "C135" "C134" "C133" "C132" "C131" "C130"
"FB8" "J28" "C129" "FB7" "J27" "U57" "U56" "U55" "U54" "U53" "U52"
"R98" "U51" "U50" "U49" "U48" "U47" "U46" "U45" "U44" "R97" "J26" "J25"
"U43" "U42" "U41" "R96" "R95" "R94" "R93" "J24" "U40" "U39" "C128"
"C127" "C126" "C125" "R92" "R91" "R90" "R89" "R88" "U38" "C124" "C123"
"C122" "C121" "R87" "R86" "R85" "R84" "R83" "U37" "C120" "C119" "C118"
"C117" "R82" "R81" "R80" "R79" "R78" "C116" "FB6" "J23" "U36" "R77"
"R76" "J22" "R75" "J21" "R74" "C115" "C114" "FB5" "J20" "C113" "C112"
"U35" "U34" "U33" "C111" "U32" "R73" "U31" "D2" "D1" "U30" "U29" "U28"
"R72" "R71" "C110" "C109" "C108" "U27" "C107" "C106" "C105" "C104"
"R70" "C103" "J19" "J18" "J17" "J16" "R69" "Q3" "R68" "U26" "R67" "R66"
"R65" "J15" "C102" "C101" "U25" "J14" "R64" "R63" "J13" "J12" "R62"
"R61" "C100" "FB4" "J11" "J10" "R60" "C99" "R59" "J9" "J8" "R58" "R57"
"R56" "R55" "J7" "R54" "C98" "R53" "R52" "R51" "Q2"
Re: gEDA-user: gattrib not showing part_numbers
On Feb 9, 2011, at 7:38 AM, Oliver King-Smith wrote: > It seems like gnetlist could be used to "promote" an attribute to the > schematic. No. Gnetlist can't do that kind of schematic to schematic translation. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gattrib not showing part_numbers
It seems like gnetlist could be used to "promote" an attribute to the schematic. Does anyone know if someone has tried that? Oliver __ From: Stuart Brorson To: gEDA user mailing list Sent: Wed, February 9, 2011 4:12:18 AM Subject: Re: gEDA-user: gattrib not showing part_numbers IIRC, gattrib will handle attributes embedded in the schematic, not the symbol. The reason is that gattrb cannot reach into a symbol and modify its attributes. It only edits attributs in the schematic. Therefore, this is a feature. Stuart On Tue, 8 Feb 2011, Oliver King-Smith wrote: > I have defined a number of symbols with an embedded part # for ease of > ordering. An example of such a part # is > > T 700 1000 8 10 0 0 0 0 1 > part_number=PMBS3904 > > This is visible on the schematic (if you turn on invisible text). However when > I run gattrib on the schematic with this in it, I don't see the part number show > up. I do see my part numbers show up for items where I entered it as an > attribute for the particular part (such as a capacitor). > > Does anyone know if this is a feature or bug? > > Oliver > > > > ___ geda-user mailing list [1]geda-user@moria.seul.org [2]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:geda-user@moria.seul.org 2. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gattrib not showing part_numbers
IIRC, gattrib will handle attributes embedded in the schematic, not the symbol. The reason is that gattrb cannot reach into a symbol and modify its attributes. It only edits attributs in the schematic. Therefore, this is a feature. Stuart On Tue, 8 Feb 2011, Oliver King-Smith wrote: I have defined a number of symbols with an embedded part # for ease of ordering. An example of such a part # is T 700 1000 8 10 0 0 0 0 1 part_number=PMBS3904 This is visible on the schematic (if you turn on invisible text). However when I run gattrib on the schematic with this in it, I don't see the part number show up. I do see my part numbers show up for items where I entered it as an attribute for the particular part (such as a capacitor). Does anyone know if this is a feature or bug? Oliver ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: numslots=0
Vladimir Zhbanov: > On Sat, Feb 05, 2011 at 05:07:06AM +0100, Kai-Martin Knaak wrote: ... > > The master attribute list explicitly requires all symbols to contain > > an numslots attribute, even if slotting does not apply at all. IIRC, > > gnetlist does not care about missing numslots=0 since quite some time. > > But gsymcheck does care (at least in 1.6.1 which I'm using yet. And I've > found no changes for the program in the main git repository since that > version). > > > Any objection to change this requirement in favor of: > > If the symbol does not need slotting, then either put numslots=0 > > into the symbol file, or completely omit the numslots attribute. ... > gsymcheck has some issues. For example, it outputs errors or warnings > when some irrelevant attributes, such as numslot, are missing in purely > graphical symbols. ... There is a very simple patch available for the numslots=0 warning, see: http://www.seul.org/pipermail/geda-user/2010-September/049354.html Regards, /Karl Hammar --- Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
