Picking up KiCAD after a break of a year or two. It looks like my install upgraded to v8 at some point and this has added a new BOM output generator, but, while it makes a nice CSV I’d like to play with the script generator. I figured that out but have a question about the %I and %O arguments. Where are those coming from? It appears that %I maps to .xml and %O maps to with no extension. It took me a little while to figure that out (I have zero programming background).
Also, and not so critical, when is the xml of the schematic generated? Is that only on BOM generation or is that something continuously updated?
You may find this whole section useful for making a customized BOM script.
Do note though that in v8 these BOM scripts are considered the legacy method of generating a BOM. The GUI BOM generator in the Symbol Fields Table is the preferred way for most users. See this section of the manual for an overview of both ways: Schematic Editor | 8.0 | English | Documentation | KiCad
I’ve been on a kick to automate things a bit lately, and have always hated manual modifications to my BOM’s. I updated my Altium template to import project name, number, revision and author; in getting back into KiCAD, it was important to me to have the same thing in my csv’s. I haven’t checked with the CM’s that I work with as to how critical this is–but the company I have worked at, sees this title block as important. At least for the time being. Maybe with time I can drop this title area, as I’m becoming convinced that title block info on files buried in a zip file is legacy stuff, stuff that we do “because we have always done it that way”.
After spending a few days fighting with the legacy BOM generator, I’ve yet to figure out how it is group by value, footprint and reference. It’s somehow buried in there, and I can’t pull it out. Bummer. I had it pulling the text variables from the *.kicad_pro file so as to get project name, number, revision, author out of that and putting into a quasi-header.
The new BOM generator tool has nothing for a header section. I can add to every row the above info, but obviously that’s not useful. I do like this generator tool, it’s nice and easy, it’s just the lack of a header section that is a bummer (or a way to pull in a template of some sort).
Oh well. Gave it the college try, tried to figure out KiPython, but it’s all flying over my head. Maybe when I get some time to learn Python properly it’ll make sense. For now I think I can just leave out the header info and not have issues, since everything gets zipped up together, and this header business is coming from the bad old days of everything only existing on paper.
and have them in use on the schematic and layout. Thus I wanted them to kick out on the BOM also, in a title area. So I played with the python scripts to make the above, but ran into some issues, between a grouping/sorting problem and the idea that this is “legacy”, which means it might get dropped some day.
I do not understand how “groupComponents” sorts by value, library and part identifier, by just looking at components in the netlist. [I use a different key by which I want to sort by, not by first letter of the designator, that’s the sortby argument that I snuck in. It works–but this section of code somehow groups by whatever is in the component it and I haven’t figured out how to “see” what is in each component. There’s a lot going on in this kicad_netlist_reader.py] Somehow each component has all the information of each component, yet when doing this compare it only uses 3 keys, the value, library and part identifier? Clearly I’m over my head.
And of course, this isn’t the preferred method–the new BOM generator is. Which does work nicely with its sorting and grouping options. I like it–it’s just that I’m not after a pure csv file, I guess.
Answering the specific question of how they are grouped - the magic happens in line 786 in your screenshot, in the comparison ci == c.
ci and c are both comp objects, and the comp class defines its own __eq__() method for checking equality, so this comparison invokes comp.__eq__() to determine if the two comps are equal. If you look at comp.__eq__() on line 331 in the same file, you’ll see there that it’s saying two comps are equal if they have the same value, footprint, refdes prefix, and DNP setting (as expected).
Note that you can redefine comp.__eq__() in your script if you want different grouping behavior.
The comp class is probably worth looking at - that’s where you’ll see what each component “contains”. In particular there is a pair of getFieldNames() and getField() methods that are likely useful for a custom BOM script.
Thanks! I did not know that it was somehow invoking eq() and was not following how it works its magic. That gives me something to look at and to play with next.
Wow, inserted like one line and voila! does what I wanted all along. I literally spend like 3 days going around and around on this one, figuring out how to insert those text variables, but then failing on the sorting.
[“comp_code” is a sorting code that I came up with years ago. I wanted company parts first on a BOM, followed by R’s, C’s, D’s, Q’s, U’s, misc hardware and with the PCB last. Our internal purchasing dept found this a nice feature, as they might be parsing the BOM into several different purchases. I have a database of R’s and C’s with codes assigned; anything else, I basically remember where I want it on the BOM, and assign a sorting code as needed. OCD? well the wife has CDO so it explains a lot.]
