[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
RE: gEDA-user: Light vs heavy gschem symbols?
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
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,
From: owner-geda-user@xxxxxxxx [mailto:owner-geda-user@xxxxxxxx] On Behalf
Of John Doty
Sent: 01 June 2005 21:30
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
TL07X-1.sym inherits graphics and pinorder from opamp-1.sym, adds a SPICE
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.
John Doty Noqsi Aerospace Ltd.