Why would it be perjorative? It’s Legacy, not Bad, Deprecated or Obsolete. There’s nothing to gain from removing the code; it’s probably not a lot of lines of code, and a lot of people to upset by doing so. So I don’t think you should worry.
Then I’m not sure if it’s the right wording used.
To me Legacy sounds like past, and Legacy parts of the software are not maintained well down the road. Eg. legacy display modes in Kicad, which disappeared once the accelerated canvas have matured.
So I’d prefer something like “Scripted BOM tool” (in opposite to GUI driven BOM tool).
We want to eventually remove it if we can do so without taking away a feature someone needs.
The intention is to give people a chance to try the new BOM methods and report any issues or request missing features. The new BOM tool (which is scriptable using kicad-cli) should be able to replace anyone’s custom Python BOM exporter. For cases that it cannot, please open issues for us to discuss.
It’s more lines than one might think, and so we are somewhat motivated to be able to remove it to cut down on maintenance / to avoid bugs creeping in.
1 Like
That’s exaclty my thoughts when I read Legacy.
As probably many of us include tools like KiBom in their toolchain, is there any idea on keeping these alive, eg. feeding these tools with data output from the Built-in BOM tool?
Or the built-in BOM tool is supposed to completely replace the need for using an external toolchain?
Looking briefly at the configuration, I can easily output CSVs (both Grouped and Non-Grouped).
What I’m missing without digging much deeper is some Filtering for variant BOM generation (KiBom provides these friendly +VARIANTx, -VARIANTx tags), and generating nice HTML output (I use that for quick verification of my BOMs).
Well, that’s up to the author of plugins like KiBom, but I see no reason why not. KiCad usually aims to have the 80% most common use cases supported, and leave the 20% to external tools (plus or minus)
I would say if there is a filtering feature from KiBom that could be useful built-in to KiCad please open a feature request for it. However, I doubt KiCad will ever generate HTML directly – that is best left for external tools.
FYI…
The BOM scripts can be coded in any programming language and can be Stand-Alone App’s and can be called from the BOM icon. Code amounts to nothing more than reading the schematic file and looking for items of interest and doing something with them.
There’s a Read-Me.txt file you can learn from (screenshot)
A few months ago a user wanted custom Fields and Database and that got me thinking… it resulted in making a GUI/BOM script for the Schematic.
In the end, for my own needs, I decided to just use the “Bulk Edit” tool in Eeschema because it has a Button, “Export As CSV” that is perfect for me because I created symbol Fields that reflect what I want in my BOM’s.
I further enhanced this by creating a ‘NULL’ symbol that contains those Fields and I created a Template with the NULL part already placed in Schematic. I manually add the NULL symbol to existing schematics as needed. And, I can also do that by running an additional Code to do it for individual schematics or in ‘Bulk’ to all of them.
So, now, I don’t even need to use my cute “GUI Bom’s Away” tool, I just click the “Export To CSV”
Screenshot of the Fields that get place by NULL-symbol (once placed, all other parts retain the fields after deleting the NULL part from schematic.
I further enhanced this by creating a Macro in Libre…
Video shows this - sorry about quality…
This is the part that is going away in the future, ideally. The new BOM system doesn’t use scripts.
Perfect! That underscores my assessment of having my BOM’s Away code as a Stand-Alone App. It does not rely on Kicad as it’s a Code to look at any Text file and search for items of interest (specifically, stuff related to things a user would want in a BOM such as, Vendor, Cost, PartNumber… etc).
You could build a Dog-House and use the BOM’s-Away code to look for Nails/Screws…
Just not sure what’s the future indended way of outputting data to external tools.
As far as I understand, these tools today are based on the XML netlist output from KiCad. But it the support for that path is to be dropped with subsequent releases, these tools will probably need to be adjusted for other data formats. Or the XML netlist output is there to stay, and only GUI to invoke filters will be dumped some time in the future?
I think we will probably always have the XML netlist, but ideally other tools will move to better systems than that once we have them available.
I didn’t had time yet to look into 8.0 but I struggle to see how exactly this should be possible without losing features? we developed a quite extensive script which interacts with several different services and APIs to fill the BOM and import the data to databases. From what you described it sounds like this won’t be possible anymore.
I am not sure what your script is doing, but in general the XML system should eventually (not in V8) be replaced by two other systems:
-
The new BOM exporter (the CSV exporter), which can be driven from scripts using
kicad-cli -
The future schematic editor API
At some point it would be good to investigate the new CSV exporter in V8 and see if it has all the features you need or not.
Ok it sounds like we then have to switch to the API based method to get the data exchanges between kicad and other plattforms working in the future. I will check once 8.0 has released.
The new/wished/proposed API is not included in v8, only the new csv-style BOM-system.
My guess is that first the new API is introduced and only then the XML-system is retired.
1 Like
The API method probably won’t be available until 9.0.
I can’t say for sure because you have only given a vague description of what your existing solution does. If your system takes an XML as input today, why can’t it take a CSV as input in the future?
It is not the XML vs the CSV thing which is the problem here. What our BOM script is doing right now is pulling data from other services, based on the schematic data and combines this data with the schematic data into a csv-file. it also takes the information from the schematic to pull current prices from different distributors, updates our internal price database, creates a separate BOM object in our parts database and some other stuff. it is basically a one click does everything process and this would not be possible directly with the new CSV exporter as far as I can tell from what you described here. because it needs very specific changes to the CSV-generator and a fully integrated one will only generate a CSV with the data from the schematic. but as said, I have to see that myself as well.
I see why this is done and it is good to know just to be prepared to adjust our internal tools there for when the script BOM support is dropped. The schematic API would definitely help then but isn’t mandatory. It probably will end up being a plugin similar to the iBOM.
I don’t see why not. It would be helpful if you could, at some point, test out V8 and open an issue explaining what data you need in the XML export that you can’t get from the CSV export.
it is not a data problem. the “problem” is, with the current, script based approach I directly control the process on how the CSV is generated. If this process is now internal to kicad I can’t do that anymore, so it adds another step, not executable in kicad directly, which takes the generated CSV (or the schematic data directly via API) and processes it further. But it is not really a problem, we just have to adjust the workflow to this change at some point.
With the current process, you have a script that converts XML to CSV
With the proposed new process, you have a script that converts CSV to different CSV, right?
Keep in mind that with kicad-cli you can already control some aspects of how the CSV is formatted.