kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/19/2012 09:59 AM, Dick Hollenbeck wrote:
> 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


Like any opinion, not everyone is going to agree with mine.  None-the-less I find that
supporting multiple ways of doing things is a nuisance relative to the joy of having one
solution work well, so my guidance would be limited to the python path.


Good luck Joe.


Dick



>
> 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
>
>
>