Hi all, I won't be able to make the meeting since I live in the UK, but here's my thoughts on requirements regarding some of the recent discussions. I don't mean to tell anyone how it must be done, but rather how I would like it if it were my call, so please forgive any confrontational tone.
When I place a part in a schematic, in my mind it represents a real physical part which I can buy (as John suggests). My main beef is with passives. Active parts are usually so different, there is no alternative but to draw a new symbol for each part. However, there are often sub-choices, e.g. lead free or leaded, which have different part numbers which I would to choose at the time of placement and later have that info transferred through to BOM etc. I do not want to remember the part numbers or add them manually each time I place a symbol, rather I should be allowed to choose them from my library once they have been entered. Regarding passives, I want to have a very small number of symbols which map somehow to a very large number of purchasable parts. I do not want to create a heavy symbol for each the 10000 capacitors in my library as life is too short. I do not want to have to remember or look up in a table myself the footprint or exact value etc for each of my 10000 parts when I place it on the schematic (of course I have to do this once when I am making the library) - rather, I would like to be presented with a list of what is in the library with any additional information I added when I made the library. To place a capacitor, I would choose a part called 'c_non_pol' or similar - If in 'physical part mode' then I would be presented with a list of what's in my capacitor library as purchasable parts. I can sort and filter this list to help my selection. I choose one and place it. Attributes such as value are automatically added to the part I placed. The footprint should be linked in later at netlist compile time. I don't want to have all the properties I specified during library creation added to the symbol in the schematic - in particular, the footprint property should not be added to the schematic in such a way as to require editing of the schematic in order to change it, as I may wish to retarget with a different footprint library, instead, it should be linked at netlist compile time. When I generate a bom and because I have entered sufficient info in my parts library, I expect to be able to hand it directly to a kitter and never speak to them again until all the parts arrive. (actually, this has never happened to me despite my best efforts, but that's my goal!) That's my hapenny- all rather cadence-esque - personally, I think Cadence have it just right with the use of physical part tables. It's very straight forward and FAST to maintain the database (well, text list) of purchasable parts and it works well. In fact, the computer aspect of physical library maintenance in cadence is a doddle. It gets trickier if part approvals and mrp systems are involved, but that's true of the rest too. gEDA could do a whole lot worse than simply lifting the cadence physical part table idea *including the key and injected property thing) - from my limited experience with gEDA, it seems that it would be quite straightforward to do this given current state, but then I'm a hardware engineer so whado I know ;) Question for John > What I now do in gEDA (and used to do in Viewlogic) > is to create a library of symbols that corresponds to > the parts stock that is to be procured and How do you deal with Rs and Cs in gEDA? Are you saying you create a heavy symbol for each value? If the value is added manually, how would you, for example, link in a company part number or order code so the BOM generator could spit it out? Thanks and best regards, Nat -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Doty Sent: 01 June 2005 21:30 To: [email protected] Subject: Re: gEDA-user: Light vs heavy gschem symbols? John Dozsa wrote: > It seems to me that the concept of a "release library" and a > "development library" could support both the newbies and the more > experience user that wants more freedom. The newbie would be directed > to use "release library" symbols with specific footprint attributes and > the experienced user could do his own with "development library" parts. The problem is that this doesn't scale to multiple organizations working on wildly different *kinds* of projects. A standard "heavy" library would need billions of symbols to be useful. There are too many options. What I now do in gEDA (and used to do in Viewlogic) is to create a library of symbols that corresponds to the parts stock that is to be procured and used for a project or a related set of projects. A "heavy" symbol library is thus an abstract representation of a stockroom. I'll start with the standard "light" library symbols, copy them as needed to the project library, and then add the required attributes. Often I'll include a .txt file with a brief description of how requirements led to the part specification (useful when a substitute must be found). The only other practical solution I can see is inheritance. Something like: TL07X-1.sym inherits graphics and pinorder from opamp-1.sym, adds a SPICE model. TL072-1.sym inherits the above from TL07X-1.sym and inherits slotting from 8_pin_dual_opamp.sym (which has no graphic). TL072CP-1.sym inherits from TL072-1.sym, adds a footprint. etc. John Doty Noqsi Aerospace Ltd.
