Re: gEDA-user: BOM of a hierarchal schematic (solved)
kai-martin knaak wrote: Looks like there is something foul with the configs at work... Ok, I just spotted the cause: It was a matter of paths. gnetlist accepts and finds a schematic with a valid path othere than the current working directory. This processes just fine with a flat project. But gnetlist assumes sub sheet symbols relative to the current working directory rather than relative to the path of the main schematic. Consequently, the gnetlist front end fails to find the bits and pieces of the hierarchy if the main schematic was given with a path. IMHO, gnetlist should extract the base path of the hierarchy from the schematics argument rather than just assuming the current working directory. Any objections? ---)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+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: BOM of a hierarchal schematic
On Wed, 2010-09-22 at 21:31 +0200, Kai-Martin Knaak wrote: The same happens with partslist2. How come? When producing a netlist, gnetlist obviously can descend to sub sheets and extract the involved symbols. What would it take to make BOM creation aware of hierarchy, too? I don't know if it's the same problem you're having, but I've already submitted a patch to fix the partslist backends[1] but it seems no one has had a look at it yet. Richard [1]http://sourceforge.net/tracker/?func=detailaid=3044478group_id=161080atid=818428 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: BOM of a hierarchal schematic
On Sep 22, 2010, at 1:31 PM, Kai-Martin Knaak wrote: Hi. I just (re-) discovered, that my favorite gnetlist BOM backend, bom2, can't deal with hierarchy. It just issues a warning. E.g: WARNING: Found a placeholder/missing component, are you missing a symbol file? [shutterdriver-relais.sym] The same happens with partslist2. How come? When producing a netlist, gnetlist obviously can descend to sub sheets and extract the involved symbols. What would it take to make BOM creation aware of hierarchy, too? Hmm, works fine for me. You may grab a fairly large project of mine that uses hierarchy from github: git clone g...@github.com:noqsi/SXI.git Then: cd SXI/SXI-EM-DriverBoard/ make DriverBoard.bom.txt It uses bom, not bom2, but I just tried bom2 and it's OK. Have you perhaps disabled hierarchy in some rc file? 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: BOM of a hierarchal schematic
John Doty wrote: Hmm, works fine for me. (...) It uses bom, not bom2, but I just tried bom2 and it's OK. Have you perhaps disabled hierarchy in some rc file? I don't think so. Actually, I'd have to search the docs to see how it could be disabled, in the first place. The netlist successfully contained the multiple instances of the sub-circuit. But I'll double check tomorrow when I am back in the office. Just checked with a different hierarchical project here at home: BOM creation was fine in this case. Looks like there is something foul with the configs at work... ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: BOM of a hierarchal schematic
Richard Barlow wrote: I don't know if it's the same problem you're having, A different project on a different computer just processed fine with the bom2 backend. Seems like this backend does the hierarchical refdeses right and does not need a fix :-) but I've already submitted a patch to fix the partslist backends[1] but it seems no one has had a look at it yet. This is a major problem with the geda/pcb project. Patches by users are neither applied nor rejected, or commented on, but simply ignored. IMHO this is puts the future of the project at risk. Potential developers need to be encouraged and fostered rather than have their patches rotting in the BTS. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: BOM of a hierarchal schematic
On Sep 22, 2010, at 5:46 PM, kai-martin knaak wrote: A different project on a different computer just processed fine with the bom2 backend. Seems like this backend does the hierarchical refdeses right and does not need a fix :-) Actually, hierarchy gets flattened before the backend sees the data, so it's difficult for a bug in a backend to cause a special problem with hierarchy. 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: BOM of a hierarchal schematic
John Doty wrote: Actually, hierarchy gets flattened before the backend sees the data, Sure. Remember, I did a bug fix that sorted the internal representation of list of components. ;-) so it's difficult for a bug in a backend to cause a special problem with hierarchy. Well, this particular partlist bugger overcame the difficulty. See Richards patch comment: http://sourceforge.net/tracker/?func=detailaid=3044478group_id=161080atid=818428 ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: BOM of a hierarchal schematic
On Sep 22, 2010, at 6:26 PM, kai-martin knaak wrote: so it's difficult for a bug in a backend to cause a special problem with hierarchy. Well, this particular partlist bugger overcame the difficulty. See Richards patch comment: http://sourceforge.net/tracker/?func=detailaid=3044478group_id=161080atid=818428 Ah, yes. (gnetlist:get-package-attribute package refdes) is a rather strange thing to do. Given the expanded refdes, retrieve the original refdes. 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
