Hi,
I have tried to download and install saxon but got struck in the middle(there was no .exe file to install saxon).
Can you post a more Straight forward method to generate BOM?
Thanks in Advance.
The exe file is (and always was?) there, I’ve just checked
Yeah it was there. Sorry… and it worked thank you so much for your help Dolganoff.
Using Lazarus/Pascal, I developed a simple Windows program to generate BOM (csv file) out of KiCAD netlist. It works for me, but it does not have all the bells a wistles. If anybody interested, I can share the program and add features.
I’ve been working on this too, last week. My intent was to use the Octopart API to fetch component prices. My Qt/QML tool reads a schematic file and does a lot of really nasty regex matching to slice it up into a table (as shown). Multiple schematic files in differing quantities can be added and sorted to a master list (I batch order my project parts to save on shipping).
I just wish there was a universal way to include the manufacturer part number in KiCad, preferably with some kind of parametric selection dialog. That would make fetching parts much much less convoluted. This then would allow one to do live cost price estimations during design, which is a feature I’d really like to have!
Hi Stephan. I thought about it too, but I do not have enough courage to make such a program. It is a nice idea to deal directly with the schematic file. I was thinking about a local database where components in stock are listed.
I guess a starting point might be to propose some standard fields for components. For me the most crucial fields are “manufacturer” and “order”.
Hi Akouz, I completely agree we should have some neutral (JSON?) model/schema for part classification. What should be in the order field you mentioned?
JSON looks OK for me. “Order” is a manufacturer’s ordering code. I hate typing, this is why I use field “brand” instead of more appropriate “manufacturer”.
I put my BOM extractor to GitHub, https://github.com/akouz/KiCadBOM. You need Lazarus to compile it into exe. It produces two BOMs in form of CSV files. One file lists all components separately, another file lists the same components in groups.
I am new to KiCAD, i followed the steps provided in this page. I am getting an error as follows.
Saxon-HE 9.5.1.9N from Saxonica
.NET 2.0.50727.5485 on Microsoft Windows NT 6.1.7601 Service Pack 1
URIResolver.resolve href=“file:/D:/Program%20Files/KiCad/bin/scripting/plugins/bom2csv.xsl” base=“null”
Using parser org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser
Warning: at xsl:stylesheet on line 35 column 80 of bom2csv.xsl:
Running an XSLT 1 stylesheet with an XSLT 2 processor
Stylesheet compilation time: 2028 milliseconds
Kindly suggest some solutions to rectify this problem and get BOM files
Thanks in advance
Sriniketh Ravindran
I got that “error” too, but check again. Right above that message, mine said “Success” and the CSV file was placed in my project directory. I didn’t see the “Success” message at first.
Anyway, thanks for the info, Dolganoff! It helped a lot.
For version 4.0.2-stable on Windows 7, here is how I used the already-installed xsltproc.exe and bom2csv.xsl: http://www.firstpr.com.au/kicad/#bomw
My command line is:
"C:\Program Files\KiCad\bin\xsltproc.exe" -o "%O.csv" "C:\Program Files\KiCad\bin\scripting\plugins\bom2csv.xsl" "%I"
I am completely new for KiCAD and just downloaded and installed yesterday! For BOM export, the existed menu is good but limited. Therefore I like to work on the original native data as a .net developer. I found the schematic diagram data is in text format instead of common xml file. So, I write a code to generate Bill of Materials (BOM) from .sch file where I can add my own filters inside. it works well even for hierarchy design. But I do hope the file format (schema) keeps unchanged when new version comes.
Did you check the various BOM generators mentioned on here ?
If you installed this yesterday, and already coded and tested a BOM, that is impressive
What is this BOM generator written in ?
Chance of no changes is zero.
I would expect the SCH format to change to be similar to PCB, but that is easier to parse than SCH.
It would be easy to check for two formats, and support both eventually.
In my opinion it makes no sense to parse the schematic file, a format that can/will change. The schematic file contains a lot of information that is not relevant to a BOM so parsing it to obtain BOM data is not very efficient. Eeschema will happily write the relevant data to an XML file for you. Even if you prefer to write your own application instead of using a plugin I don’t understand why you wouldn’t use the XML file.
I think there is a place for all approaches.
Sure, use XML, if that will do what you need, but sometimes that is either not enough, or requires an additional step that a user may wish to avoid.
KiCad will always use ASCII files, so the OP can modify the parser, when the next major upgrade of SCH side is done.
I disagree completely, pursuing “all approaches” usually does not end well. That is why standards are developed in the first place.
How can it not be enough? It would appear your could rebuild the schematic from the XML file. It is also extensible after all. Often all you need to manipulate the data is a stylesheet but it is also easily read by other applications, due to the fact that it is a standard. And surely using externals tools would require more steps beyond the simple click of a button.
Yes, I have tools like that. Often when the toolchain is updated the third party tools break and you have to wait for them to be updated, assuming they are still being maintained. Let’s not take KiCad down that road.
I’m not sure where you get this ‘standard’ from, XML is merely a format, and has nothing to do with what is actually contained in the file.
I can see 4 BOMs already, in kiCad - seems there are at least 4 ‘standards’ !
( & more are posted on here…)
This requires that someone to find and choose the correct and matching BOM script, (already there are 4, but those may need modification, making 5 or 6…) in order to ensure the BOM file is in phase, and then their external software must be run, to do the post-processing.
So there is another step, which is hard to guarantee has happened.
To me, it can be simpler to parse the Schematic file directly, less steps and less variables. One master.
Users are free to choose the flow that suits them best.
Precisely. it is a standard format, parsable by any XML parser regardless of content. Tools already exist, most of us already have them, to manipulate the content of an XML file using stylesheets. If that’s not good enough for you then by all means write an application to use the contents of the XML file as you see fit. Changes to the XML file are unlikely to break any stylesheets or applications that use it, unless they decide to rename/remove existing elements which would not be a good idea but still manageable.
Parsing the schematic is not only not a good idea it’s simply not necessary. Using an external app to parse a schematic file requires that you remember to save the schematic first. Generating the XML from within KiCad does not.
Those “BOM scripts” you refer to are the stylesheets I am referring to. It wouldn’t matter to me if there were 40 of them. Once I find the one that works for me I stick with it. One button click and I get both files guaranteed to be in sync with my schematic. If there isn’t a stylesheet that does what I want I find the closest one and modify it, now there are 41 so what?
Anyway, I’m not here to argue for the sake of arguing, I have stated my opinion as to why I believe it is both silly and unnecessary to reinvent the wheel. You are of course free to do what you like.
?? That seems quite a strange ‘plus’ point. What sane person would not save changes, when running a BOM ?
I can edit a SCH and when I save that SCH, the change is saved, just as common sense would expect.
I can email that saved SCH to someone else. They have all the information.
However, the XML file I have, does not update, until I manually run something else. This requirement you select and run something else, is a significant weakness.
Even within KiCad, the means to refresh that XML is not explicit. There is no Export XML button.