kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #11639
Re: parts-list and BOM
On 11/10/2013 01:11 PM, Cirilo Bernardo wrote:
>
> -------------------------------------------- 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.
No doubt. But I don't want to key on custom fields during the netlist and partslist
relational join. Your specific example can be addressed simply by stating the voltage in
the component's value, such as "0.1uF 16V" if is not the default. The partslist is
local to the project BTW, if you followed what I said.
"0.1uF 16V" and "0.1uF" are different, and easy to understand.
> 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.
Sure, and I am not volunteering for that.
> 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).
In my plan the database is a "partslist spreadsheet", initially generated by the script.
On the second run of the script, with the other command line option, it is relationally
joined to the netlist again on a component by component basis, finally creating the BOM.
> 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.
I suppose it would be possible to isolate the join operation into a separate python
function, and you could later extend my work to work from a parts-list or part database
separate from the spreadsheet partslist that I mentioned. But that is beyond my initial
needs and intentions.
> 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.
In my "/new" eeschema design which was part of the sweet work, since abandoned, the parts
list on one project could be used as a lib_source on another. The parts list was to be a
spreadsheet within the schematic.
>
> - Cirilo
>
Follow ups
References