I just wrote a small tool to process bills of materials from KiCAD. If the part information is in the schematic,
KiCAD BOM to CSV converter
This is a Python 3 program to convert KiCAD Bills of Materials to a CSV format suitable
for uploading to major part distributors including Digi-Key and Mouser.
Usage
To use this program, each item in a KiCAD schematic needs some additional information for ordering.
The suggested information is:
Mfgr Manufacturer (TI, etc.)
Part Manufacturer part number
Vendor Vendor name (Mouser, etc.)
Vendorpart Vendor's part number
You can use any names; they just have to be consistent.
Use the BOM icon button in KiCADās schematic editor to generate a BOM file with
an XML suffix. No filters are required.
This will generate one .csv file for each different value of āVendorā. The files are
generated in the same directory as the XML input file.
The output .csv files contain column headers and one line for each part. Multiple
instances of the same part are combined into one line, with the quantity column updated
appropriately. The āREFā column will contain all the schematic instances using that
part number.
These files are acceptable to the BOM uploaders for both DigiKey and Mouser.
Once uploaded, the parts can be ordered.
I look forward to the day when itās decided upon a specific BOM tool thatās integrated into KiCad. Preferrably I would like to see something where you manipulate rows, columns and specific rev/author/company/fields in a live viewer before you export it to your preferred format. Hopefully this tool can also let you remove or edit details for parts, and you can save a āBOM configā file for each project to remember which order you want your columns and fields, which parts to exclude and so on.
Eeschema should probably have standard fields for parts like āManufacturerā, āManufacturer part numberā, āVendorā and āVendor part numberā. Those are the four data items you need to order parts.
Just adding those four fields as built-in names would help. This would standardize the field names used for components. Then BOM output programs would have standard data fields to work from. Right now, thereās only a standard āDatasheetā field.
Open EEschemaā¦ and add the fields you want - Thank [deity of you choice] they didnāt push anything onto the users and weāre free to do what we want - not all people want those field definitions how you might find them useful.
ProTip: make the Default Value ā_ā or somethingā¦ NOT nothing, as otherwise they wonāt make it into the libraries and also not into the schematic.
Any NEW symbol you create from here on will have those fields (if Default is NOT empty).
Any symbol you edit will have those fields (if Default is NOT empty).
This will not (95% certain, too lazy to test right now) ācreateā those fields on-the-fly for existing schematics and/or symbol libraries.
You would expect any symbol that doesnāt come with these fields getās them when it is loaded into a schematic with these settingsā¦ but that is not a given, as different people might have set up their symbol libs with different pre-defined fields (symbols from different libs with clashing field definitions) into one schematic.
KiCAD keeps those fields separate afaik, but no idea what the BOM tools make out of this reallyā¦
To make a long story shortā¦ as soon as you get to this point itās better to use your own local libraries and run them atomic with symbols/footprints pre-linked and all fields filled in, so you essentially have 1 symbol for 1 part you do use in your schematic/layout.
Just search āatomic partā on this forum and you find enough examples to hook onto for how to do this.
Thatās such an open-source answer - donāt standardize, dump the problem on the user.
The electronics parts industry runs on four fields. If those have standardized names, tools can use them, and parts libraries can be set up to use them in a standard way.
KiCAD and the Open Parts Library should be consistent about this.
Are you sure you know what youāre asking there John?
So far KiCAD consists off a collection of symbols for a LOT of components and leaves it to the user to link them up with footprints of his/her choice.
You can mix and match where you see fit.
Any partnumber/datasheet/etc that would be defined by the symbol would also necessitate that the KiCAD librarians would need to create libraries for a lot more parts (some symbols stay for 10 or more packaging variants/part numbers) and would also need to pre-link the footprints.
I and a lot of others do this with our OWN private libs - defining atomic parts. Itās a lot of work and I wouldnāt want to lay the necessary quality control onto anyone else. YMMV.
Thatās why I said, KiCAD gives you a choice - itās serving the beginner/hobbyist as well as the more advanced/professional user.
But KiCAD wonāt be able to do the necessary legwork to convert all current libraries that are into what you want - atomic parts.
If at all, KiCAD, at some point in the future will provide better tools to manage atomic part libraries, but thatās it.
For example this thread deals with it (there are others too, but canāt find them right now).
