Add KiCad IPC API backend (KiCad 9+, incl. v11 nightlies)#555
Conversation
KiCad removed the SWIG `pcbnew` Python module in development builds (v11/nightly), so the existing ActionPlugin no longer loads there. This adds an alternative backend that talks to KiCad over the IPC API via kicad-python (kipy), running as a separate process. - ecad/kicad_ipc.py: IpcApiParser(EcadParser) producing the same pcbdata structure as PcbnewParser, so the HTML renderer is unchanged. Output was diffed against the SWIG parser on KiCad 10 and matches to <0.01mm for edges, footprints, pads, tracks, zones, nets and BOM components. - plugin.json / requirements.txt / ipc_entrypoint.py: IPC plugin manifest, per-plugin venv deps, and the separate-process entry point. Puts the toolbar button back on v11 where SWIG plugins are unavailable. - ecad/__init__.py: get_kicad_ipc_parser() factory (kipy imported lazily, so nothing changes for SWIG installs / CI). - ecad/kicad_extra/__init__.py: make `import pcbnew` optional so the package imports under the IPC runtime where pcbnew is absent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Thanks for taking this on, it looks promising. Several major things before I go into details and craft a full feature test board to compare the new and old parsers.
|
|
Hi there glad you like it, I member talking about it with you and the guy who had that yellow orange pic about official IPC support for kicad a few years ago and thanks to claude we can port those changes and enchanse this projects several times faster than big guys like altium Dassault etc... so basically it was a quick sinlge / 2 prompt patch which seem to work with the lastest yesterdays nightly build so far. Let me know if something is wrong and I'm looking forward for recommandations for porting other useful plugins with that same "SKILL" maybe even in batches so I'm open for suggestions. |
|
I already posted 3 major things to change above. Start there. |
- Move legacy SWIG parser (PcbnewParser + the ActionPlugin) to ecad/kicad_swig.py and promote the IPC API parser into ecad/kicad.py so the IPC backend is the default going forward. - generate_interactive_bom.py: route .kicad_pcb through the IPC parser when an API server context is present (KICAD_API_SOCKET), otherwise fall back to the SWIG parser which loads the board file from disk. - Skip registering the legacy SWIG ActionPlugin on KiCad 9+ (where the IPC plugin manifest provides the iBOM action) to avoid a duplicate toolbar button. I hate work, and may the Claude be with you. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
I will need to put together a test suite of boards to validate new parser, I dont think eyeballing it with a couple of boards will cut it. Give me a few days. |
Sure thing no hurry, for me this seem to work but still haven't tested it on more than a couple of boards as well. |
|
Just an update to show I havent forgotten about this, I have a whole bunch of test cases prepared already but need more for full coverage. |
|
Testing shmesting... enough with the buerocracy people are waiting push it already, it's already proven to do the job and back then that was the only solution, just integrate it in a way kicad expects for package downloads through the UI. for the cases that won't work you'll get people feedbacking you doing the work for free(like a bug report -> patch exchange)... |
|
Yeah, that'll be a hard pass from me. |
|
but it's significantly better than the nothing that is being offered right now for that version and it basically generates the iboms for 2 projects tested so far so what's the deal? kicad and freecad are shitty softwares with tons of bugs and things that don't work or are expected to work but cause the app to crash all to this day. that's not something that goes to run your Bank I think community feedback and testing of other people even those who don't understand the codebase is one of the easiest fastest and in some cases most practical way to test software (not completely advocate those but most of big tech companies work that way sometimes releasing things that are too broken to be practical...) Claude got quite good and accurate from the last 3 years, give it a try, don't be a Boomer. |
|
I use llms, I'm not averse to them. But "I ran it on two projects, it didnt throw an error and it generated something that looks right" means it has basically 0 testing. Over the years there were a lot of bug reports for corner cases to get the rendering right, I'm not about to push some half-baked ai slop out on users and go through same issues again. Especially since I already have a good working code, it's output can be used as reference to check new implementation, which is exactly what I'm doing now. Or trying to find time to finish doing, to be exact. KiCad 11 will not be released until 2027, it's ok if ibom doesnt work on nightly. |
|
sounds harsh, that's an OS repo who the heck pays you to do that? whatever let me know if you find anything critical I'll solve it with some swearing :D |
2 participants
Summary
KiCad removed the SWIG
pcbnewPython module in development builds (v11 / nightly), so iBOM'sActionPluginno longer loads there and the toolbar button is gone. This PR adds an alternative backend that talks to KiCad over the IPC API via kicad-python (kipy), running as a separate process. SWIG installs are unaffected.What's included
InteractiveHtmlBom/ecad/kicad_ipc.pyIpcApiParser(EcadParser)producing the samepcbdatastructure asPcbnewParser, so the HTML renderer is unchanged.plugin.jsonruntime.type: python, onepcb-scoped action) — restores the toolbar button on v11.ipc_entrypoint.pyrequirements.txtkicad-pythonfor the per-plugin venv KiCad creates.ecad/__init__.pyget_kicad_ipc_parser()factory;kipyimported lazily so nothing changes for SWIG installs or CI.ecad/kicad_extra/__init__.pyimport pcbnewoptional so the package imports under the IPC runtime wherepcbnewis absent.Validation
Output was diffed against the existing SWIG parser on KiCad 10 using the same board: edges, footprints, pads, tracks, zones, nets and BOM components match to <0.01 mm, byte-identical in most cases. Smoke-tested on a KiCad 11 nightly (10.99) build where SWIG no longer exists — the venv is auto-created with kipy+wx, the toolbar button appears, and generation produces a correct
ibom.html.Notes
kipyis only imported when the IPC parser is actually requested, soimport InteractiveHtmlBom(and the test suite on KiCad 8/9) never pulls it in.requirements.txt(no reliable Linux wheels) and is instead inherited from system site-packages via KiCad's--system-site-packagesvenv. Without it the plugin still generates headlessly with saved settings.Caveats for review
This is a substantial addition (~1k lines, mostly the new parser) and I'd welcome guidance on whether you'd prefer the IPC backend to live behind a smaller shared abstraction. Happy to adjust.