← Back to team overview

kicad-developers team mailing list archive

Re: parts-list and BOM

 

Here was implemented native generator of the BOM in *.ods format:

http://bazaar.launchpad.net/~kicad-gost-committers/kicad/kicad/files/head:/eeschema/GOST-doc-gen/ <http://bazaar.launchpad.net/%7Ekicad-gost-committers/kicad/kicad/files/head:/eeschema/GOST-doc-gen/>

07.11.2013 21:23, Dick Hollenbeck пишет:
After finishing a board today, I still feel like our BOM support is lacking, so I have
some thoughts to share, get some feedback, and maybe figure out how to get it coded in python.


My Definitions, so you can follow:
=======================================================
part = something from the eeschema library.

component = something from one of the schematic sheets, an instantiation of a part.
========================================================

The problem is basically this in a nutshell:


     lack of "parts-list" support in eeschema.


To me a parts-list is a table of unique parts used, duplicates are coalesced into one row
by collating.  That is, if I have quantity (30) of 0.1uF caps, I'd expect them to show up
on one row in the parts list.

Yes its nice to have "properties" for every component in the schematic, but it is simply
not practical to put component information into each instantiation, especially a
duplication of purchasing information.

So I propose the following solution.  This is a python parts-list and BOM generator, and
requires no changes to eeschema.   Let me call it *bom_or_partslist.py* for the sake of
discussion.  It includes a python *.ods library of some kind, meaning it can read and
write to "open document format" spreadsheets, supported by OpenOffice, Libre, and
gnumeric.  These are files with extension *.ods.

When invoked like this:

bom_or_partslist.py --partslist <netlist>.xml

it creates a parts list spreadsheet

   <netlist>.PARTSLIST.ods.

The parts list spreadsheet includes unique parts, one per row.  What constitutes unique?
Subject to discussion, but I am thinking the combination of "libpart + value", as if it
was a concatenated key.

So the number of columns is minimal.  I guess to handle the whole work flow, the script
has to first check if the target *.ods exists already, and if so, is allowed only to
modify the left most column.

User may add additional columns to the spreadsheet.  In mine, I would add Manufacturer and
Vendor and Price@1000, manually by editing the partslist spreadsheet.

Note that I put the Manufacturer's part number into the same field with the manufacturer,
same with Vendor.  Note that this is a person choice, not actually part of this design,
since these are columns beyond the first one.

e.g. Vendor:
"Digikey AE10968-ND"

Same for Manufacturer, it actually holds *two* pieces of information, manufacturer and the
part number.

-----------------

When invoked like this:

bom_or_partslist.py --bom <netlist>.xml


It generates a BOM file:

	<netlist>.BOM.ods

by merging the <netlist>.BOM.ods file with the <netlist>.xml file.

This means as you make purchasing choices, you do edits on only one place, once each for
each part.

There would be two entries in the BOM dialog, both referencing the same script, but with
different names and parameters, one to generate or refresh the partslist and one to
generate the BOM.

The hardest part of this is the regeneration of the partslist.  I may start by overwriting
what's there and work in the regeneration support as time permits.

Can anyone suggest improvements?  The one's I will consider (if I code this myself) will
be easily implemented with good value.


Thanks,

Dick









_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



References