Right now, KiCad ships with a lot of BOM generator scripts. This is kind of overwhelming to new users, so we’re considering cutting down the list of plugins that are shown by default as much as possible (we’d still distribute all the exisitng plugins, you would just have to hit the “add” button and browse to the ones we don’t show by default to add them to the list)
So, which of these do you use? Do you think we might be able to consolidate down from having bom_csv_grouped_by_value, bom2grouped_csv, bom2csv, bom_csv_grouped_by_value_with_fp, etc to maybe just one of those?
Removing the netlist scripts from that list would be a good start, but hopefully that goes without saying
Doing a quick sample of my projects going back to 4.x, it looks like “bom_csv_grouped_by_value” is the one I always use, but “bom_csv_grouped_by_value_with_fp” seems the same but better and I’ll use that one going forward. If you’re going to keep one, “bom_csv_grouped_by_value_with_fp” would seem to be the superset plugin and I don’t think the others would be missed (by me at least).
For my purposes the HTML ones are obsolete when you can use @qu1ck’s interactive html bom plugin instead, but maybe there’s still a usecase.
The power of the system is that you can customize plugins for your own use, though I don’t know how many people actually do that. But it’s a lot friendlier to customize them when there are a good variety of example plugins that can be used as a basis for a new one.
Is there a way you can slim down the list while still shipping enough plugins to use as a basis for custom BOM plugins? (Nearly-identical plugins don’t provide any extra value as examples)
If kicad ends up shipping plugins that aren’t included in the default plugin list, will the existence of the additional plugins be documented so that users are aware of them? Undiscoverable plugins are as good as nonexistent.
Initially I used the “virgin” XML file generated by KICAD, and played with it in a spreadsheet program.
Now I use KiBom for all my needs (HTML for quick viewing, and CSV with common component grouping [grouping by private database ID], and without grouping [when used to lookup from Pick&place])
Are there ways to advertise that there are more plugins, or make them more discoverable, in addition to the documentation? A GUI note might be overkill, but a “browse for additional plugins” button that reliably opens in the right directory would be good.
Another thought – I’ve never used any of the XSLT plugins but it seems like there are some python plugins that have an equivalent XSLT version, or vice versa. Any plugins that are pretty much identical other than scripting language are redundant. Based on the descriptions, “bom2grouped_csv” seems equivalent to “bom_csv_grouped_by_value_with_fp” for example.
The add plugin button can default to the right directory. The BOM plugin system is kind of on its last legs anyway though, as I expect it to be replaced with the rest of the output upgrades planned for V7 (really, we should not make people write or modify Python scripts just to export a BOM in a certain format) – note before anyone freaks out: of course this doesn’t mean that we would just remove the ability to run scripts with no transition plan. Just saying that we think the entire concept needs rework to be more user-friendly, so spending time on making the process of using scripts to generate BOMs more user friendly might not be the right approach.
We were planning to remove all the XSLT plugins from the list by default.
To improve the user experience for new KiCad users, who right now are faced with a long array of options to choose from when exporting a BOM for the first time.
yeah, I found the eeschema bom plugin situation so confusing I always just used the single pcbnew option (until I needed something different for generating jlc pcba files).
Another vote here for BOM_csv_grouped_by_value_with_fp, I always use that one. I agree that including them all in the list was pretty confusing in the beginning.
[I notice in my version that it is the only one showing in 5.1.x so I might have already removed the unused ones, and when I check my 5.99 version (5.99.0-9233-g881cb3182b), release build, it is also already the only one listed, so I might have done some reconfiguration that carried over from 5.1.x. I use my own templates folder in my home folder tree.]
Edit: On further check I found that I am using a modified version of the BOM_csv_grouped_by_value_with_fp script, where I have included my custom fields Manufacturer, Manufacturer Part No., Vendor and Vendor Part No. that I use in my fully specified parts.
Stripping down the list isn’t the final solution to that problem. The whole idea of list of scripts, short or long, is hostile to non-programmers. What is really needed is a good UI for configuring the BOM output.
The problem with the scripts is easy to see when we look at the names. We have boms for csv, html, none of them… Then boms grouped by something or nothing… Boms sorted by something or nothing… Combine them if you want to get the wanted configuration and you will have dozens of scripts which can’t be configured but each of them does one configuration. And still you may not get what you want. And it’s impossible to tell by name what each script does, and the descriptions don’t necessarily help at all.
Actually only one script would be needed: output csv with all fields. The rest can be done in OpenOffice or similar when the BOM is opened. It’s even easier to do than modifying the scripts.
EDIT: in any case, because the eeschema BOM system has been so hostile to users – to me – I have used only the simple pcbnew BOM which has given what I need. No need to try to decrypt any meanings. That’s why I said that only one script would be needed. It’s easy to sort rows and to delete and reorder columns in office spreadsheet apps.
There is not a full spec written yet, but I expect the future BOM exporter to allow selection of properties to include and their order; use data from either schematic or board (i.e. there will not be two different BOM exporters in pcbnew and eeschema), and include various formatting options, all in a GUI with no Python scripts involved. Of course all this data will also be available via the Python API for people who need more flexibility.
We’re talking “V7” features now, and it would be great if I could use the GUI to define my output. Even greater if we could define different export “Profiles” and switch between these.
Now, as for the V6, I agree with @eelik that there should be one CSV output that exports all the schematic’s data into an organized structure. One part per line, but including all defined fields. Rest (including grouping) can be done in a spreadsheet. Include one row header that splits nicely into columns, with fields’ names and that’s it.
The problem is, if you want to group components you need to give the users the possibility to define how to group.
E.g. for me, grouping just by “value” is useless. I need to group by my databaseID if I want to have different physical parts grouped.
Like having 100nF 0603 capacitors with different voltage rating or ceramics type. I don’t put info like this to the Value field.
So a long list of individual components is more flexible in the way that you can do the grouping in your favourite spreadsheet app (hint: Pivot table). The other way round is much more complicated.
I agree with you on this, however I was just referring to that specific script where you get two outputs on one file “collated components” and “individual components” when the script is supposes to give you only “grouped_by_value” components. I have to remove the individual components list every time (or modify the script) to get what the script is advertising to be doing for me.
EDIT:
As I said, “what most of the people want” of course there is value in getting a big list of individual components, but then you don’t need a “grouped_by” kind of script.
The simplest BOM i know of that can be made from eeschema with kicad version 5 is to use the field editor*, group as needed and then ctrl+a ctrl+c -> open any spreadsheet application -> ctrl+v
Is easy to use, powerful, does not require understanding the complex script system and does work already in v5 so i assume will also work in v6.
So maybe an option for now would be to document this option.
However if i had to choose one of kicads options then i would say the python scripts that create csv are what i would use. Most useful to me would be the one wich groups by value and footprint.
*) This is from memory as i don’t have access to kicad right now. So the name of the tool i used could be different. It was the tool where one can edit all fields of the schematic in a nice spreadsheet like view.
