gEDA-user: Check for attribute conflict does not play nice with multi part symbols
With gnetlist 1.7.0 (g9b9080e) a new check for attribute sanity seems to be in place. Unfortunately, it does not play nice with multi part symbols. For each of my opamps, that have a separate power symbol I get: / Possible attribute conflict for refdes: U7 name: value values: (LMH6609 #f) Possible attribute conflict for refdes: U7 name: footprint values: (SO8 #f) \ However, the power symbol does not contain a value attribute, or a footprint attribute at all. I guess, this is what the #f is trying to tell. It would be nice, if the sanity check would recognize that this is not a possible conflict but perfectly acceptable. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New Column: From the CAD Library
Hi all, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Peter Clifton Sent: Saturday, February 05, 2011 3:49 PM To: gEDA user mailing list Subject: Re: gEDA-user: New Column: From the CAD Library On Fri, 2011-02-04 at 08:17 -0500, Bob Paddock wrote: New Column: From the CAD Library When creating a CAD library, there are dozens of things to consider that are often overlooked or not even considered that will directly affect the quality of part placement, via fanout, trace routing, post processing, fabrication, and assembly processes. This article, Part 1 of a series, introduces aspects that should be considered when creating CAD library parts. http://www.pcbdesign007.com/pages/zone.cgi?a=74214 Has tips worth considering. Note that the series continues on his blog. It is VERY good, and contains a lot of details I was looking for recently. http://blogs.mentor.com/tom-hausherr/ -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) +1 I've been following Tom Hausherr's achievements (the formerly PCB-Libaries, now Mentor Graphics) for a couple of years now, and I think that this blog is mandatory reading before Getting Started with pcb design. I would like to see some, if not all, of these standards reflected in the pcb-lib some day _and_ these recommendations end up in the (gEDA) pcb documentation, just to prevent error 404 from happening. Of course, there are others sources of information to read before putting the first trace on a pcb, like app notes and part datasheets from vendors. One of Tom's issues that is to be kept in pcb are most of the mil grids because of the bazillion perf board and mil based parts on the market, to be bought for cheap by hobby-ists, or for Quick-and-Neat proto boards (we don't play or do dirty ;-). Just my opinion on the subject. Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New Column: From the CAD Library
Bert Timmerman wrote: I would like to see some, if not all, of these standards reflected in the pcb-lib some day _and_ these recommendations end up in the (gEDA) pcb documentation, just to prevent error 404 from happening. copy-paste would require that he releases the text under GPL, or compatible. One of Tom's issues that is to be kept in pcb are most of the mil grids because of the bazillion perf board and mil based parts on the market, to be bought for cheap by hobby-ists, or for Quick-and-Neat proto boards. ack. But the role of mil and mm should be exchanged. The file format should be metric at the bottom. Imperial measures should be derived on the fly. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: default dir for gpcb-menu.res
Just found out, that the pcb binary I compiled from git and installed to /usr/local uses /usr/share/pcb/gpcb-menu.res Is this intentional? I'd have expected it to use /usr/local/share/pcb/gpcb-menu.res After all, this is where the gpcb-menu.res went on make install ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: locknames - ignorenames ?
Hi. While teaching students howto use geda/pcb, I found myself explain that lock-names does not really a lock but an ignore flag. Because, this is how it operates under the hood. In addition, the lock meme does not quite fit to the behavior. You'd expect locked text to stay in place whatever you do. But of course the names of components do move if a component is moved. Proposal: Rename Lock_Names to Ignore_Names (in the menu and in the source) Any objection? ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: locknames - ignorenames ?
Hi Kai-Martin, -Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of Kai-Martin Knaak Sent: Sunday, February 06, 2011 2:17 PM To: geda-u...@seul.org Subject: gEDA-user: locknames - ignorenames ? Hi. While teaching students howto use geda/pcb, I found myself explain that lock-names does not really a lock but an ignore flag. Because, this is how it operates under the hood. In addition, the lock meme does not quite fit to the behavior. You'd expect locked text to stay in place whatever you do. But of course the names of components do move if a component is moved. Proposal: Rename Lock_Names to Ignore_Names (in the menu and in the source) Any objection? ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user If the lock mechanism is not broken, please do not try to fix it ;-) This is a great opportunity to create all sorts of Heissenbugs for not so often used code paths. If it's just semantics then please let this issue remain as it is, that is: in a locked in place state. Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: locknames - ignorenames ?
Bert Timmerman wrote: If the lock mechanism is not broken, please do not try to fix it ;-) Currently, we have two kinds of lock mechanisms in pcb. One is mediated by the lock tool. Objects locked by this tool are pinned down at their current place. There is no way to select them or generally do anything about them except for unlock. The other lock applies to text only and is mediated by the setting called Lock Names. Unlike locked objects locked names can be moved, rotated or even be deleted. It is just insensitive to a selected group of interactions with the mouse. I consider this broken by design. It is a deviation from the principle of least surprise. And it gets into the way when communicating. What would you do if I asked you to make sure, some text is unlocked? This is a great opportunity to create all sorts of Heissenbugs for not so often used code paths. I find it hard top believe that pcb code is so brittle that a mere renaming of variables is considered too risky. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New Column: From the CAD Library
On Sun, 2011-02-06 at 10:55 +0100, Bert Timmerman wrote: One of Tom's issues that is to be kept in pcb are most of the mil grids because of the bazillion perf board and mil based parts on the market, to be bought for cheap by hobby-ists, or for Quick-and-Neat proto boards (we don't play or do dirty ;-). Just my opinion on the subject. Imperial parts are not a problem for a sufficiently fine metric grid. I don't think we should remove the option of working on a Mil grid though. I do it most of the time, even though I realise it is a habit best got out of. Way forward: Metric nm grid internally, parts defined in whatever units the vendor's controlling dimensions are in. This might require relative origins to be used between the part design coordinate and the board's snap-grid, but that seems to be mandated by various IPC standards anyway. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: locknames - ignorenames ?
On Sun, 2011-02-06 at 14:16 +0100, Kai-Martin Knaak wrote: Proposal: Rename Lock_Names to Ignore_Names (in the menu and in the source) Any objection? File a bug on LP please. I don't oppose, and what you suggest does may sense. The only down-side is the need to update documentation, and to think twice about what you tell some new user... what version are you using? -- Lock_Names or Ignore_Names, when you are helping them find the option. I would probably consider moving the mechanism to a more general one where you could ignore polygons, components, tracks, vias, Each would probably be a toggle item. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: vertical toolbox in gschem
What do you do with vertical_toolbar.patch? Is there something you can do to the gschemrc file? On Sat, Feb 5, 2011 at 8:30 PM, Mark Rages [1]markra...@gmail.com wrote: Hi, I switched my gschem to have a vertical toolbox on the left, rather than a horizontal toolbox on the top of the screen. With wide aspect-ratio screens, this is a better use of display real estate. Patch attached. Regards, Mark markrages@gmail -- Mark Rages, Engineer Midwest Telecine LLC [2]markra...@midwesttelecine.com ___ geda-user mailing list [3]geda-user@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:markra...@gmail.com 2. mailto:markra...@midwesttelecine.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
Re: gEDA-user: New Column: From the CAD Library
On 02/06/2011 09:24 AM, Peter Clifton wrote: Imperial parts are not a problem for a sufficiently fine metric grid. +1 I heard Tom Hausherr talk last year about grids, land pattern generators. For his suggestion to just go metric, it works with old inch spaced protoboard layouts just fine if enough resolution is used. It's always going to be valuable to combine the old with the new, where you might have very fine line spacings in the new on a metric grid, the base drawing being a metric grid, and placing the inch stuff on a calculated-from-metric semi inch grid only means some holes are off by 0.025mm or less if using a 0.05mm grid. Meanwhile, any scripted tool we can write to help make parameterized footprints from datasheets will be one of the biggest aids to pcb layout. Much of our discussion about ways to vote on or log successful uses of footprints in production of boards seems invalidated by the industry adoption of most nominal and least density styles of footprints where the IPC specifies extension of pad area beyond a part lead in mm. The manufacturer's suggested footprint is pretty much ignored by such a standard, yet deriving footprints from lead shapes for 2 terminal chips and gull wing leaded parts is what the usual commercial tools (and thus the usual commercial layout folks) do. When it comes to chip scale packages I didn't see any suggestion to change the MFRs land pattern. Hausherr does suggest BGAs get the three density levels, but the denser ones are only used on throw away products. IPC recommendations seem to take BGA shapes as published by MFRs and make them a little larger for robustness. The writeup on http://blogs.mentor.com/tom-hausherr goes over the same material I heard in person last year about fairways between microvias put in BGA ball lands planned for many tracks in inner layers of 8 and up layer boards used for dense products these days. Figure 20 and 21 are for board layouts, but look like chip layouts of the 1990's! Blind buried microvias here we come? John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New Column: From the CAD Library
On 2/6/2011 10:24 AM, Peter Clifton wrote: On Sun, 2011-02-06 at 10:55 +0100, Bert Timmerman wrote: One of Tom's issues that is to be kept in pcb are most of the mil grids because of the bazillion perf board and mil based parts on the market, to be bought for cheap by hobby-ists, or for Quick-and-Neat proto boards (we don't play or do dirty ;-). Just my opinion on the subject. Imperial parts are not a problem for a sufficiently fine metric grid. I don't think we should remove the option of working on a Mil grid though. I do it most of the time, even though I realise it is a habit best got out of. I don't think you understand the intent. I don't think anyone is suggesting any changes to what a user sees. The issue is what base units are used internally and in libraries. By using metric values, imperial (is that really the right term?) measures (aka inches and mils) can be represented and calculated with no loss of precision. However, when inch type units are used as the fundamental measurement, it can be harder to get adequate precision to represent metric units. 1 inch = 25.4 mm... exactly 100 mm = 3.937007874016... sort of. In reality if you use enough precision in the base units you can always get close enough which is what engineering is about. But some folks have an issue with not working in the best possible manner. I'm not sure this is really an issue. There would be significant pain making the change now. If the change is to be made at a later time, will it really be any more painful? So if there is no significant reason to switch and the pain does not increase if delayed... why bother with it now...? Way forward: Metric nm grid internally, parts defined in whatever units the vendor's controlling dimensions are in. This might require relative origins to be used between the part design coordinate and the board's snap-grid, but that seems to be mandated by various IPC standards anyway. Parts should match the rest of a system I think. The dimensions of a part can be stored in the units that best suit the system. It seems silly to store a part as metric and let the system round it off to inches on the fly rather than to do the round off when the part is created. But that's just my opinion. Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: numslots=0
On Sat, Feb 05, 2011 at 05:07:06AM +0100, Kai-Martin Knaak wrote: Another cite from the master attribute list: /-- numslots=# should exist somewhere in the symbol and be made invisible. This is a free standing or floating attribute. If the symbol does not need slotting, then put numslots=0 into the symbol file. \-- Why is the numslots attribute required to be invisible? IMHO, this is a matter of style that should be up to the user. 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. This affects also the 'Symbol Creation Howto' and the gsymcheck symbol checker itself. Would you like to change gsymcheck behaviour (that is code)? 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 also 'gsymfix' which should be used to fix some attributes issues. And in that case it also should be fixed. (It should be fixed anyway because it wrongly sets the XXX value for missed attributes that violates requirements of the 'Master Attributes List' document e.g. to set footprint=unknown for symbols without known footprint and so on.) -- VZh ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New Column: From the CAD Library
On Sun, 2011-02-06 at 12:27 -0500, rickman wrote: Parts should match the rest of a system I think. The dimensions of a part can be stored in the units that best suit the system. It seems silly to store a part as metric and let the system round it off to inches on the fly rather than to do the round off when the part is created. But that's just my opinion. Conversely, to me it seems silly to deliberately loose information on the part's original specification. If the manufacturer specifies some dimension as 1mm, that is how it should stay represented in our source design files, not 39.3700787 mils (or however one chooses to round it). PCB already supports reading units like 1mm in its input files, but it always saves out the rounded imperial representation. Sure - it probably doesn't matter if you round everything based on true position when creating the file, but if the user were to copy+paste part of that new (rounded) footprint using an imperial grid, to make a longer part - rounding errors could easily be compounded. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: vertical toolbox in gschem
On Sun, 2011-02-06 at 10:29 -0500, Rob Butts wrote: What do you do with vertical_toolbar.patch? Is there something you can do to the gschemrc file? It was a patch against the source-code, so you would have to apply it to a checked out version of the gEDA sources and rebuild / install from source. Do you install gEDA from RPMs? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: numslots=0
On Sun, Feb 06, 2011 at 08:47:05PM +0300, Vladimir Zhbanov wrote: 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). ... There is also 'gsymfix' which should be used to fix some attributes issues. And in that case it also should be fixed. (It should be fixed anyway because it wrongly sets the XXX value for missed attributes that violates requirements of the 'Master Attributes List' document e.g. to set footprint=unknown for symbols without known footprint and so on.) Please file a bug so these findings are not lost. https://bugs.launchpad.net/geda/+filebug -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ 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 wrote: This affects also the 'Symbol Creation Howto' and the gsymcheck symbol checker itself. ack. These are supposed to track the contents of the master attributes list. So yes, gsymcheck needs to be changed in unison. Would you like to change gsymcheck behaviour (that is code)? Unlikt the master atributes list suggests, gsymcheck treats missing numslot=0 as a warning, not as an error. Make gsymcheck accept this condition silently is no big deal. gsymcheck has some issues. Indeed. So many of them that I gave up on gsymcheck long time ago. For example, it outputs errors or warnings when some irrelevant attributes, such as numslot, are missing in purely graphical symbols. There is also 'gsymfix' which should be used to fix some attributes issues. And in that case it also should be fixed. good catch. (It should be fixed anyway because it wrongly sets the XXX value for missed attributes that violates requirements of the 'Master Attributes List' document e.g. to set footprint=unknown for symbols without known footprint and so on.) BTW, digging into the scripts dir I found gsymupdate. This pearl utility seems to be a convenience script to update symbols from the time before the current slotting mechanism. Cite from the source: # Right now this program should only be run against symbols which are # either version 20020527 or earlier. Did anybody bother to test whether this script still runs correctly with current versions of perl? Maybe it is about time to phase the script out. ---)kaiamrtin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: vertical toolbox in gschem
No Peter, I've never installed gEDA from rpm. I installed Fedora 14 and then through the software manager installed the gEDA software. I take it a vertical menu bar is not possible to configure in the gschemrc file? At some point I'd like to figure out the whole cvs gEDA thing. On Sun, Feb 6, 2011 at 3:09 PM, Peter Clifton [1]pc...@cam.ac.uk wrote: On Sun, 2011-02-06 at 10:29 -0500, Rob Butts wrote: What do Celine Tschida with vertical_toolbar.patch? Is there something you can do to the gschemrc file? It was a patch against the source-code, so you would have to apply it to a checked out version of the gEDA sources and rebuild / install from source. Do you install gEDA from RPMs? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list [2]geda-user@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:pc...@cam.ac.uk 2. mailto:geda-user@moria.seul.org 3. 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: New Column: From the CAD Library
Am 06.02.2011 um 16:24 schrieb Peter Clifton: Imperial parts are not a problem for a sufficiently fine metric grid. I don't think we should remove the option of working on a Mil grid though. I'm wondering what's the advantage of having an internal grid at all. Why not just use doubles, describing a position in meter or millimeter? About all mechanical CAD and picture drawing applications do it that way. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
