kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

--------------------------------------------
On Fri, 11/8/13, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

 Subject: [Kicad-developers] parts-list and BOM
 To: "KiCad Developers" <kicad-developers@xxxxxxxxxxxxxxxxxxx>
 Date: Friday, November 8, 2013, 3:23 AM
 
 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
 
 
 
 


Hi Dick,

 Something that immediately comes to mind is that not all 0.1uF capacitors are equal and this is true of most components.  One method to uniquely identify a component is for the user to create a unique internal part number, so one part number can represent a 0.1uF 5V SMT tantalum of some sort while another represents a 0.1uF 16V SMT multilayer ceramic, etc.  The problem with such an approach is that it requires a substantial amount of software working with a database. Some of the good things include the fact that the database can contain other information (suppliers, external part #, URL for a supplier's pricing API, etc).  I'm happy to work on a simple DB framework for storing an internal partnumber and any metadata so long as we have a pretty good idea of what we want and how it might be used in the future. Creating internal part numbers is another challenge; some people create a part number for each project (which I think is best) while others try to
 maintain one monster database for use in their shop and across all projects.

- Cirilo