kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/19/2012 07:13 AM, Joseph Baker wrote:
> Hi,
>
> I've been working on a dedicated bill of materials management tool to augment Eagle's
> quite basic BOM script (see https://github.com/jbaker0428/Eagle-BOM-Manager/). That
> being said, I've hit the limits of the free version of Eagle and am working on switching
> to Kicad permanently. Kicad appears to have equally limited functionality in this area,
> so I want to make my tool compatible with both programs. However, I don't think I can
> properly support component attributes given how Kicad currently exports them to CSV (the
> same applies to other output formats, but CSV is what I happen to be using). The problem
> is this:
>
> The column names in the outputted CSV file are always named Field1 - Field8. Each the
> field columns of each component row contain the value of the fields in question.
> However, there does not appear to be a way to output the actual names of the fields in
> question for each component. I can't do anything useful without those field names. In
> addition, there appears to be no way to output the "Chip name" component attribute.
>
> Fortunately, I think this can be fixed without fundamentally altering how component
> fields work. Here's what I would like to do:
> -Add a checkbox to output "Chip Name" under System Components.
>
> -Either:
> Split the current Field columns into 2 columns per field (name and value). The problem I
> see with this solution (and the current implementation) is this: What happens if a
> component has more than 8 fields, or is that not possible? As it appears that I can in
> fact add more than 8 fields to a component, I have to wonder why the current BOM
> implementation can only output the first 8.
> -OR-
> Replace the "FieldX" columns with a column for each attribute name present in the
> schematic, with blank entries for components that do not have an attribute by that name
> (this is what Eagle does). This could cause erroneous behavior in my tool if multiple
> components use a default field name for different things, but that is an error condition
> I can handle.
>
>
> A few questions:
> I see a similar blueprint
> here: https://blueprints.launchpad.net/kicad/+spec/bill-of-materials. Should I modify
> this, or post my own?
>
> Should I be working off the stable branch, or testing?
>
> As a longer-term goal, would there be interest in an building an adaptation of my BOM
> management tool directly into Kicad (outside of Eeschema)? This would allow for much
> more powerful project-level BOM/component sourcing management (kind of like
> this: http://wiki.altium.com/display/ADOH/Live+Links+to+Supplier+Data) without needing
> to manually update an intermediary CSV file like my current version requires.
>
>
> Regards,
> Joe



The BOM code will never be adequate for everyone.  This is why I have argued for 3 years
now that we should remove it and simply use Brian's python scripts which are in the
scripts directory, which run on the generic netlist export format XML.  This way you can
change what's there in seconds, rather than having to suffer a code review, grapple with
internal C++ data structures, etc.


The best enhancement you can make to the C++ BOM code is to delete it.  The best thing you
can do for BOM support within KiCad is to learn to use the python scripts, document them,
and take a maintenance role in that.


Thanks

Dick