[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Managing parts multiple parts - physical part table feature request?
I like and prefer the 'soft' attributes version. In my world, I'd have only enough attributes on the symbol such that a post-process can extract the correct part from a data base (or pause for user selection when multiple parts match). Capacitors and resistors are good examples, just put the R or C value, tolerance, voltage, footprint, etc., into the symbol and let the post-process run.
Years ago I had such a program working for Viewlogic schematics. Sadly, nobody else in the company cared to use it - even though it made annotating schematics MUCH simpler and faster. Oh well. GSCHEm uses a similar file format to viewlogic in that it's all ascii so parsing the files is not difficult.
*********** REPLY SEPARATOR ***********
On 5/31/2005 at 3:21 AM natbuk wrote:
>Hi,
>
>Just been looking at the whole gEDA thing for the first time. Serious
>congratulations on the state of the tools. Kudos to all the contributors.
>
>I am a long-time Cadence user (professionally) - I also have my own
>projects
>for which a cheap (free!) tool that'd do the job would be bonza.
>
>So, I'll cut to the chase - I'm really missing a way to manage passive
>parts
>like Rs and Cs in a sensible way. Perhaps someone has some suggestions on a
>suitable method other than my suggestion below?
>
>Some background:
>
>As a designer, I like to have quite a lot of specific component information
>at placement time - this might include parameters such as price, mfr part
>number, ripple current, height, dielectric, a hyperlink to a data sheet
>etc.
>For good designs, this kind of information is important as sometimes two
>cheap parts will better one more expensive one, does the part contain lead
>etc. I also like to have a rich database of parts to choose from with many
>values.
>
>As a librarian, I require a simple (minimal typing) method for entering
>zillions of parts that often look identical on the schematic except for
>some
>attributes (e.g. capacitors).
>
>As a manufacturer (or sub-contractor thereof) I like to supply purchasing
>information as part of the bill of materials. At least the mfr part number,
>usually a price ea, order code, distributor etc. This information may
>change
>from time to time, but I still need my designs to compile, and preferably
>it
>the up-to-date info I have entered. Bad or minimal data to kitters means
>lots of hassle.
>
>Cadence Concept achieves all this very simply and looking at the front end
>side of gEDA, it looks like it's almost there, which leads me to my feature
>request (or some pointers to how to achieve with the existing system).
>Please forgive the long post -
>
>The c(C)oncept:
>
>* for each library part (symbol), a text file (optionally) exists with
>property headings such as value, type, voltage, footprint etc.
>* when I place a part from the library, I can choose either the current
>gEDA
>method or the 'part from a text file' method
>* each single physical part (one that can be ordered from a mfr) is
>represented by a single line in the text file
>* there are two types of properties - I'll call them 'hard' and 'soft'
>(can't think of better words right now)
>* each physical part is represented by a unique set of hard properties -
>(unique so the netlist compiler can identify)
>* when a part is placed in the schematic, an additional dialogue box is
>presented which lists the contents of the text file
>* by selecting one of the 'lines' in the text file, hard properties are
>added to the symbol body at placement time as if they had been added
>manually or from the symbol
>* soft properties are used to provide the designer with additional info and
>used by the compiler/bom generator for things like price, order code,
>footprint
>* The dialogue box should recognise hyperlinks and spawn a viewer if the
>hyperlink is clicked - this makes data sheets easily available at placement
>time
>* if no text file exists, the existing method can be used (for backwards
>compatibility)
>* The dialogue box which displays the text file has basic searching and
>sorting capability (e.g. sort by value, show only parts with *0603* in
>footprint).
>* on the symbols, a property may be added with no value specified (as
>currently) and this value is populated (or overwritten) if the part is
>placed using the text file.
>
>Notes:
>When the cadence netlist compiler runs, it cross references the hard
>properties which uniquely identify each physical part and can use
>additional
>(soft) properties for items such as the PCB footprint. When the BOM
>generator runs, it also uses these files to extract any parameters (user
>defined), just like gEDA does, but as I understand it, gEDA requires the
>property to either have been added to the symbol during library creation or
>manually added on the symbol during schematic capture. Keeping things like
>PCB footprint 'soft' (e.g. could specify a different heading to be used as
>footprint to the netlist compiler) allows the use of multiple PCB design
>packages and existing footprints easily.
>The main distinction between hard and soft properties is that because hard
>properties effectively become part of the schematic (or library), if you go
>and edit them and then try to compile an old design, the whole thing breaks
>- so one must be careful with the hard properties - but, the soft
>properties, because they are effectively linked during a netlist compile,
>can be changed at will and old designs remain good.
>
>As an example, here is a snippet from a concept ppt (physical part table):
>(apologies for the formatting as I'm sure it will go awry! Each of the
>lines
>representing a part begins with a value in this example - in the complete
>file, there were more fields including digikey order codes, but I truncated
>it for brevity - the original file contained 490 capacitors - most of the
>Panasonic ECJ series stocked by Digikey)
>
>PART'CAP_CER'
>
>
>
>{===========================================================================
>===========}
>:VALUE | TYPE | DIELECTRIC | VOLTAGE | TOL = JEDEC_TYPE |
>ALT_JEDEC_TYPE | LEAD_FREE | GENERIC | MFR
>{===========================================================================
>==}
>'0.5pF' | PANA_0402_ECJ | NPO | 50V |'.25pF' = 0402C | 0402C
>| LEAD_FREE | NO | PANASONIC |
>'1.0pF' | PANA_0402_ECJ | NPO | 50V |'.25pF' = 0402C | 0402C
>| LEAD_FREE | NO | PANASONIC |
>'1.5pF' | PANA_0402_ECJ | NPO | 50V |'.25pF' = 0402C | 0402C
>| LEAD_FREE | NO | PANASONIC |
>'2.0pF' | PANA_0402_ECJ | NPO | 50V |'.25pF' = 0402C | 0402C
>| LEAD_FREE | NO | PANASONIC |
>'3.0pF' | PANA_0402_ECJ | NPO | 50V |'.25pF' = 0402C | 0402C
>| LEAD_FREE | NO | PANASONIC |
>
>Although this might seem cumbersome at first, the text file is very
>powerful. If you want, they can be edited in excel or similar, but I use a
>text editor with column support. Obviously, scripting is quite
>straightforward for some tasks. I recently entered over 1200 capacitors
>into the database in 2 hours including mfr part numbers, order codes,
>prices, footprints and about a dozen other parameters using largely cut and
>paste from .pdf catalogues and column editing - very speedy! In the above
>snippet, the parameters to the left of the equals sign are hard and the
>ones
>on the right of the equals sign are soft so the set to the left of the =
>must be unique. Stuff the right of the = can be anything and is only
>examined by the netlister/bom generator if specifically instructed.
>
>Anyway, that's my ha'penny. Judging by the front end, I guess the
>developers
>have concept (or SCALD) experience, so this is probably not new, but at
>least to me, would turn this package into a baby Concept.
>
>And for my next suggestions, shall we talk about a constraints editor? OK,
>I'll shut up now!
>
>Seriously high regards to the developers,
>
>Nat
>
>
>
>--
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.322 / Virus Database: 267.3.0 - Release Date: 5/30/2005