← Back to team overview

kicad-developers team mailing list archive

EEschema, cvpcb fileformats and BOM enhancement proposal

 

--- In kicad-devel@xxxxxxxxxxxxxxx, Dick Hollenbeck <dick@...> wrote:
>
> Frank,
> > cvpcb has a GUI and is focused on footprint assignments. Reference
> > designators and footprints need to be assigned in the schematic editor
> > then show up in the netlist. I would propose that instead of having
> > cvpcb produce an updated netlist, it update the schematic file
instead.
> > This would eliminate the need to write a back annotation tool to
> > update the schematic for board turnon or manufacturing reference.
> > There already is a placeholder (F2) of the component for the foot
> > print in the sch file and the footprint currently can be assigned in
> > EEschema by editing each component instance and it will show up in
> > the netlist. It also would be handy while creating a schematic to
> > include the footprint in the add component cache along side the name.
> >   
> 
> Seems like a reasonable idea. I see no problems with it, but I not an 
> eeschema or cvpcb expert. 

Well, me neither but the proposal below doesn't seem like
a horrific change.

> 
> > Adding a vendor part number (VPN) field (F3?) would enable an improved
> > BOM listing. This field would be optional and would show up in the
> > BOM if present. The advantage of a VPN nails down a symbol and
> > footprint. Selection of a VPN defines a specific footprint while the
> > schematic symbol could look like anything the schematic designer likes
> > as long as the pinout is consistant. A VPN enables future creation of
> > a project (or board) only BOM (or library) and could reference a
> > larger company wide parts library (or database). Without this each
> > designer potentially re-invents a symbol/footprint library for each
> > project.
> >   
> The fields are present already. I did exactly this on my last 
> project. I added a Vendor field, and a Manufacturer field. In the 
> Vendor field you would see something like "Digikey 12345" and in the 
> Manufacturer field you would see something like: "AMP 1234".
> 
> (Then I wrote a java program to extract the BOM from the *.sch file and 
> put it out to CSV format, where after it was loaded into a 
> spreadsheet. This is a very slick bom, it even collates like 
> components for a second table, and then lists all ref designators in a 
> common cell. So you have a single component table, and a collated
table 
> both, that way you know how many you need to order from the collated
table.)
> 

Exactly, so in EEschema I would propose that instead of selecting
a symbol, we have the capability of selecting a part listed in a 
parts file. This file contains a unique part number, symbol and
footprint that get stuffed into the component instance fields. Note 
that each manufacture already maintains a unique part numbering scheme
for their parts. Multisource cross reference, AVL, inventory, 
distributor, distributor#, unit price, etc is a separate database
problem. The parts file could be project specific or subset of a
company wide comma separated list that could be imported/exported
into/outof a spreadsheet, here let me start one:

F3 F1 F2
National:DM74LS00N, 7400, DIP14, "quad nand"
National:DM74LS00M, 7400, SMP14,
Vishay:FC0603E50R0BTBST1, R, 0603, "RES 50 OHM 125MW .1%", 

where the first 3 fields are sufficient for now. The BOM output
from EEschema could reference the unique part number for
better communication with the person that needs to procure the
parts. The current BOM output references the symbol which doesn't
detail which vendor's part or footprint.

Frank

> 
> Without picking field names, I mean hard coding them, we could
provide a 
> "project specific" set of field names, and save these desired field 
> names in a config file. That way they would show up each time the
"Edit 
> Component" popup came up. Again, without actually being hard coded.
> 
> 
> > Example:
> > part # symbol sect footprint ref manufacture description
> > --------- ------ -- -------- --- ----------- -----------
> > DM74LS00N 7400 A DIP14 (or N14A) U1
> > DM74LS00M 7400 B SMP14 (or M14A0 U2
> > 54LS00W 7400 A W14B (or CFP14) U3
> > Note: this is 3 separate parts and need separate ref designators
> > (Using similiar but different parts can happen)
> > Parts with multiple sections only count as one part in the BOM with
> > a shared footprint, the section letter would not be listed. The
> > manufacture, description, inventory could be added to a future,
> > separate parts database, selector, navigator....
> >
> > The bottom line is the schematic should be the master controlling
> > document...need to swap parts, pins or change footprint? - update
> > the schematic and re-generate the netlist.
> >
> > A more complicated parametric example:
> >
> > Digi-Key Part Number FC0603-50BFTR-ND
> > Manufacturer Part Number FC0603E50R0BTBST1
> > Symbol: R
> > Description RES 50 OHM 125MW .1% 0603 SMD
> > Manufacturer Vishay/Thin FIlm
> > Resistance In Ohms 50.0
> > Power (Watts) 0.125W
> > Tolerance 1/8W ±0.1%
> > Lead Style Surface Mount (SMD - SMT)
> > Case 0603 (1608 metric)
> > Packaging Tape & Reel (TR)
> > Composition Thin Film
> > Voltage - Working *
> > Temperature Coefficient *
> > Quantity Available 1
> > Minimum Quantity 1
> > Unit Price USD 0.91000
> > Datasheets
> > here there are many resistors with a common shared symbol and
footprint
> >   
> 
> I am lost now. You should say where this information is more clearly 

I was just trying to illustrate that selecting discrete components
such as resistors, capitors, transistors involves more parameters
and complicates the part selection/navigation of a parts library 
browser....a separate discussion.

> in your proposal. The name of the file, where it is, etc. When
it is 
> read in, how it is read in, etc.
> 
> 
> Dick
> 
> > As a designer why do I want to deal with all this?
> > Ans: To make sure the correct parts are ordered, your board is
> > built right, it will work properly and save the company money
> > by ordering common parts in quantity from a qualified vendor.
> >
> > Frank Bennett
> >
>







References