PCBWay - seeking help/developers for automating KiCAD data parsing/checking


I am a PCBWay manager, we PCBWay is a prototype and assembly manufacturer (maybe someone here has ever used our service). Generally our engineers need to check clients file before they can place order. Now we want to upgrade our service which can help us get the file parameters directly (the size,the Min Track width,the min Spacing, Min Hole Size ,usually gerber format) when our clients upload their files.

I have talked about this with Mr.Wayne Stambaugh (the Project Leader of Kicad), and he said actually it is achievable with Kicad function while the problem is that he is too busy to do this. So I would like to ask if there is anyone available here who can help us with this? Of course we will pay the commission. If you are interested in please send mail to me anson at pcbway.com

[edit, Joan]
changed title and tried to scramble email a bit, so it’s not useable by bots


Please specify exactly what paramaters you are trying to automate. Knowing what constraints fabs look for could help improve the DRC rules to help with this.

I am not an active developer. But clear and well explained requirements are more likely to be implimented soon.


If I understood you correctly, you want to verify uploaded design files automatically.

A python script for that would

  1. load the pcbnew module
  2. open the design file
  3. override the DRC settings
  4. refill the zones (people tend to forget that)
  5. run DRC
  6. override the plot settings (use the same origin point for Gerber and drill files!)
  7. plot and generate drill files

I believe there should be somewhat usable scripts for that already.

The Python API is not in any way stable as it only exposes the internal data structures, so it will definitely make sense to synchronize the kicad and script versions (e.g. by having the script check the kicad version in the beginning and switch into the appropriate implementation depending on that).

It may also make sense to adapt kicad itself so it exposes the entire flow as a high-level function, but this would have to be backported into the 5.0 branch and a stable release would have to happen to make this usable in a production environment.


Do you know how to actually do this. Looking at the documentation I did not find an obvious way of doing this?


@MitjaN: I think, the first line of .kicad_pcd and .sch containing version information.


Thanks for your reminder,here is the parameter we hope to get: the size,the Min Track width,the min Spacing, Min Hole Size. Could you do this?


Yes,we hope to verify uploaded design files automatically (the size,the Min Track width,the min Spacing, Min Hole Size). Could you do this?


A bit of misunderstanding here. There is a file version, which for layout you can also get through BOARD class method GetFileFormatVersionAtLoad. For schematics you have to open the file.

But there is also a KiCad version, which would be nice to have access to in python API as python API is changing as mentioned.


Is it only a quick check for the values, or should it actually check that the manufacturer’s minimum space between copper features (tracks, zones, pads) is obeyed? Each netclass has its own min. clearance, but even when DRC doesn’t find faults it doesn’t mean the board is manufacturable. Each pad can have its own clearance and if it’s smaller than the net clearance, DRC doesn’t give an error. It’s not enough to check just values; each actual distance should be checked.

If I can guess, this is only the first quick check and the generated gerbers will be checked anyways by other means. In that case a simple comparison of couple of values is enough here.


I think ideally the script would override the existing DRC settings, then run DRC.


I didn’t express myself clearly, but what I meant to say was that if the manufacturer wants to make sure that the minimum space between copper features isn’t violated, every pad’s clearance value should be changed, too. I implied using the existing DRC.

At least in 5.0 there doesn’t seem to be a general minimum clearance/space setting, in the DRC dialog there’s unchangeable “Clearance: By Netclass”. And the per-pad clearance setting overrides the net class value when pad-to-pad clearance is concerned.


@GyrosGeier could you make it happen?


I don’t have any experience with the Python interface, sorry. Maybe @eelik?


Has this been floated on the developer’s mailing list?


@GyrosGeier, I’m confused, if you have no experience with the Python interface then why are you telling us it is unstable and exposes internal data structures? How could existing scripts be relied upon if, as you say, the Python API is “unstable”???


@anson You want to do this with software on your website when your customers upload KiCAD files?

You want to extract size, Min Track width, min Spacing and Min Hole Size from the Design rules of your customers uploaded files so that your engineers or software can verify that your customer has specified valid values for your process?

Let me know if I’m understanding you correctly and I will contact you via email. I can do this kind of programming. You might want to consider posting something on the developers list too.


We are working on a tool (since mid last year) that imports a KiCad design (even multiple), checks against various things, and generates extensive reports. It is highly scripting capable. Currently we support KiCad V4. V5 is coming soon depending on the customers need. Please have a look at:

It is being tested against various dummy projects here. So there might be issues with larger real KiCad projects. Your feedback is highly welcome.


I’m confused, if you have no experience with the Python interface then why are you telling us it is unstable and exposes internal data structures?

I’ve never written a script for KiCad, and would definitely take a long time to get started doing so, but I occasionally do changes on the C++ side. The Python interface is generated by parsing the C++ headers and generating Python functions to access and manipulate the data structures in memory.

There are a lot of potential improvements to the codebase that would break existing scripts if they were implemented, for example the Via class is a descendent of the Track class, and a KiCad-specific reimplementation of the dynamic_cast<> C++ operator then pretends they aren’t. This has historical reasons, I’d like to get rid of this code, but doing so would break all scripts that generate copper traces.

It would be really nice to have a well-designed and stable API that wraps the internal implementation so whenever we change something internally, the wrapper can be adapted and the change made transparent to scripts (possibly with a deprecation warning, but not simply breaking things).

How could existing scripts be relied upon if, as you say, the Python API is “unstable”???

This is a massive problem. When v6 development opens up after the 5.1 release, I expect lots of scripts to break as new features are integrated.

The way out would be to sit down, design an easy API, write small wrapper classes and generate the Python API from that. It’s on my list, but that is the same list that includes a writable pin table that should be ready in time for the 4.0 release.


I assume the python interface will not change for bugfix releases of version 5. I doubt pcbway intents to support the nightly releases of kicad.
This would mean that your outlined problem should not affect the topic discussed here.

@pointhi started something in this direction. Building a proposal for an (official) high level python API


There is one PCB fab and assembly house that I use regularly that quotes directly (i.e. fully automated) from only the Kicad .kicad_pcb and .sch files. I have used the V4 and V5 RCxx labeled nightlies with them, without issue. (Note I haven’t yet moved to the post-5.0 release nightlies yet) It checks the PCB, pulls the BOM, IC position and IC pin 1 locations or rotations auto-magically, then quotes instantly. So it’s already being done by at least one group.