Re: gEDA-user: Light vs heavy gschem symbols?

[John Luciani <jluciani@xxxxxxxxx>]

My preference would be a multi-weight system that is normally light
but experiences an occasionally weight gain. 

One of the major advantages of the gEDA/PCB tools over other tools is
the open file formats.  The open formats allow for the easy creation
of a variety of post-processing tools. Rather than filling in all of
the attributes during schematic creation I have found it easier to run
the schematic through an annotation script that annotates based on a
common configuration file.  A dozen pull-down menus to insert a
resistor is more manual steps and more manual errors.

With a light system you would run an annotation utility that uses a
configuration file that contains rules to update various fields based
on your "released" components.  The annotation utility would go out to
a relational database (through a server) to retrieve values for the
various fields.  The server could be used by gschem, PCB and other
utility programs. The server (and database) could be local or remote.
Using a common configuration file keeps the parts choices the same
across projects.

Pseudo code for an example rule ---

if (refdes is a resistor 
        && value == 10 
        && manufacturer is not defined
        && manufacturer_part_number is not defined) 
{
    manufacturer='Yageo'
    manufacturer_part_number='9C08052A10R0FKHFT'
    footprint='0805'
}

The manufacturer, manufacturer_part_number and footprint are all
retrieved from a database but could be hardcoded in a configuration
file. Using another table in the database you would relate the
manufacturer, manufacturer_part_number to vendor,
vendor_part_number. Using your inventory table you could generate your
order list.

A little more flexible rule that chooses Yageo 9C0805 series resistors
for any VALUE --- 

if (refdes is a resistor 
     && manufacturer is not defined
     && manufacturer_part_number is not defined) 
{
   select manufacturer, manufacturer_part_number, package as footprint
     from   resistor 
     where resistance = VALUE
         and manufacturer = 'Yageo America'
        and manufacturer_part_number like '9C0805%'
}

The fields in the returned tuple would be used to fill in component
attributes.

The weight gain comes in when a component is packaged using different
pinouts. If you want to see correct pin numbers for this part in your
schematic you have to choose a footprint prior to placing the
part. For example: the LM326-2.5 reference has two packages --- DIP8
and TO-92.

           TO-92  DIP8
Anode      1        4
Cathode   2        8
Adj            3       5


Future Ideas

  * Place all of the annotation rules in a table. The structure could be

    project_name  char
    rule_ordinal     integer
    rule                  char
    action              char

    Each rule would be parsed and the appropriate action performed.

  * Add a datasheet link to the component database. Upon receipt of a 
    "datasheet?" message the component-server would return the URL
    for the sheet. 
    
    (* jcl *)





On 6/1/05, nat <nbentall@xxxxxxxxxxxx> wrote:
> 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: owner-geda-user@xxxxxxxx [mailto:owner-geda-user@xxxxxxxx] On Behalf
> Of John Doty
> Sent: 01 June 2005 21:30
> To: geda-user@xxxxxxxx
> 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.
> 
>