kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/14/2010 12:42 PM, Werner Almesberger wrote:
> Dick Hollenbeck wrote:
>   
>> You seem to be especially concerned about a manufacturer field within
>> the symbol becoming obsolete.
>>     
> Yes, or the field having an almost arbitrary value from a vast
> set, e.g., in the "any 100 k resistor" case.
>
>   
>> But for the mean time WRT template fieldnames, you are not required to
>> add a "Manufacturer" field to your template fieldnames.
>>     
> Yes, I understand. Seeing all those "manufacturer" examples was
> just a big red warning light popping up. Sorry for diverting the
> thread.
>
>   
>> One idea is that the BOM generator could maybe take a CSV file as INPUT,
>> and the CSV file would map symbol value to manufacturer, vendor, and
>> maybe price.
>>     
> I think CSV files would make a nice interface, particularly if
> combined with some editing facilities in the BOM generator that
> help to maintain referential integrity.
>   


One idea is to have the BOM generator generate a CSV file that the user
is to edit.   The output of this file is edited with today's best
Manufacturer, etc., then fed back into the BOM generator on a more
elaborate 2nd run.  The rows in this first table are a set of unique
part numbers, similar in nature to my collated rows in my example BOM
with additional fields for information the user should provide on a per
part number basis rather than on a per part instance basis.

Then this CSV file becomes a secondary input on a second more elaborate
BOM pass, grabbing the Manufacturer and Vendor from the user edited CSV
file.



> This would also allow the BOM generator to be developed apart
> from the main KiCad codebase, which is probably a good thing in
> the long run. (And it might give me a chance to play, too :-)
>   

Yes, but this means duplicating all the schematic file loading code.  I
don't view that strategy favorably since file loading code is going to
be changing as the file format changes.  Putting BOM generation into the
core means you don't work with files, you work with the schematic data
tree, somebody else maintains the file loading code *in a single place*.


> The tables that further describe parts and distributors could
> be maintained outside the KiCad core. Since they're not
> project-specific, they could be shared among projects and even
> among users.
>
>   
>> Attached is a sample output from my Java based BOM generator.  The trick
>> I used here is to only define the Manufacturer/Vendor once *per
>> schematic* (the library is not involved).  The collating pass merges all
>> components sharing the same value.
>>     
> Looks very nice. How does your system know that C1 is a
> TAIYO YUDEN TMK105BJ104KV-F ?
>   

First, my "Manufacturer" field holds both manufacture and the
manufacturer's part number, by definition.  Same for vendor.  I simply
wanted two less columns.

I entered that *one time* into the *schematic* symbol property editor
for a user defined field called "Manufacturer" for *any one (1)* part
matching C1.  The collation pass then propagates this entry, but realize
this is simply a matter of combining spreadsheet rows and incrementing
its usage counter, so no actual propagation actually needs to occur.  A
collision on a matching part with a different Manufacturer would give me
grief, and maybe the last guy wins, don't recall.  So this is an area
that can be improved upon. 

See above for a two pass solution.  Gnumeric works pretty well, I seem
to prefer it over OpenOffice but either works fine.  You thinking we
should make Kicad into a spreadsheet?   What about passing stuff through
the clipboard, this is also easier than CSV files on the user, and
easier on us developers.


Dick