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.
Everything you described above seemed to indicate you want this piece of software to run on kicad data.
Your last response would contradict that. Now it seems like you want a full gerber checker. (Makes me wonder if you even have well defined specifications in mind or if you just wing it.)
I doubt that kicad is really the right tool to do full on gerber checks. (Gerber import is quite limited) Maybe an interface to your currently used toolset might be better. (Use the same tool for both production and billing as otherwise you might get contradictions.)
I would allow a little leeway for translation issues I think he probably meant that most/all customers currently submit gerbers, but they would like to add support for KiCad files.
I guess OSHPark developed scripts to import KiCad files, but I also guess manufacturers are unlikely to shared their code (competitive advantage).
@ bobc @ Rene_Poschl I am sorry for my poor English to make misunderstanding. For Chinese PCB manufacturer,the engineers need to check gerber file and then arrange production.
So we want to get parameters from gerber file. Mr.Wayne Stambaugh said it can be achieved by Kicad function.
What do you mean with “parameters from gerber file”?
If you want to check on the gerber level then you need to use a gerber checker. There are no file parameters that you can read out that will guarantee that clearances and min width settings are met. I am not aware that KiCad can run a DRC on gerbers directly. (I might be wrong about that part.)
The need to run checks also applies with a KiCad project. Nobody can guarantee that the user did not set “ignore DRC violations” for the project at some time. Copper zones might not have been updated before submitting the board file to you.
This means that reading out the users DRC settings does not give you any information about the state of the PCB. You really need to run the full DRC with your specifications on the project to get a result on it. Meaning the workflow for user supplied KiCad projects would be:
- Open the KiCad pcb_new file
- Setup DRC settings of pcb_new according to your specifications
- Run the DRC and report any errors to the user.
- If no error is found: Generate gerbers with the settings used for your chinese fab. (Start the plot dialog)
I’m a little puzzled here, by exactly how you want this to operate ?
" 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.
That is not a KiCad data parser problem, but a Gerber/Excellon problem.
It seems a simple and worthwhile report set, to add to GerbView ?
Min Track width and Min Hole size should pop out in a few lines of code, during the files-load.
Size seems to be known, as it Auto-Centres already, so just needs to report those.
That leaves Extract Min Spacing as a more difficult GerbView general problem, as well as how to manage file-type split.
The ideal Web-Vendor Automated-Website would do something like
- grab users (KiCad created, Gerber set ) Zip file, save to path/quote1746372
- run (imaginary) command gerbview.exe -dir path/quote1746372 -r Reportname.xml/xls/csv
- read generated report
- apply min.max checks and calculate quote, include report in quote to customer
GerbView does big chunks of that now, it seems to quite nicely swallow whole sets of Drill/gerber & autoscale.
I see it also correctly loads/renders KiCad slots, so can report those too.
Finer details like file sorting (eg split silk-screen-set from copper-set, cannot guarantee by name ) might be nice if get false errors from Silkscreen of tracewidth & certainly clearance pass ? )’
Maybe a silk in filename is enough ?
Looks like the only listed item of min Spacing, is special software, but that’s a tough ask from scattered Gerber data, and maybe a Clearance == MinWidth ‘rough rule’ is enough to assume from scanned data ?
Worthwhile, sure. But simple?
All that can be checked reliably from gerbers is minimum width of copper and minimum spacing between isolated copper areas. Gerber doesn’t have knowledge of pads, tracks, zones or nets. It has graphical features which can be interpreted in different ways as far as pcb design goes. It doesn’t even have knowledge of continuing copper from one layer to another; it has to be calculated by using drilling information. Also it can’t know when manufacturer’s minimum spacing or width doesn’t matter, for example with copper text inside copper fill. So manual checking is necessary anyways.
This task needs much better and exact requirement list for functionality. Whoever implements it probably needs knowledge of gerber format. I don’t think this is a simple task unless all which is needed is checking for minimum spacing between isolated copper areas and minimum width of copper. Everything which involves pads, tracks, nets etc. is either more difficult or impossible. And I don’t have any idea about whether KiCad already have functions for calculating minimum spacing or width for gerbers, and even less idea about how they could be implemented if they don’t exist. Maybe the real KiCad developers have some idea about that.
See my last paragraph qualifier.
I’m less sure about your ‘checked reliably from gerbers is minimum spacing between isolated copper areas’, claim, hence my qualifier already above.
Seems the quality resulting / code effort ratio is not worth it, hence my related question.
eg A very short trace segment is graphically legal, but could trigger a false virtex-virtex (Minimum above 0) check.
Yes Gerber limits Size, the Min Track width, Min Hole Size ( I’d add Max Hole Size too)
can be extracted in one pass, and Gerbview already has all the numbers flying past.
That type of scan-for-limits, is not complex code and is fairly common.
There is no ‘calculating’, more a simple if compare
if MinVal > ThisNewVal then
MinVal = ThisNewValM
MinVal starts at some (silly) BIG value, and hops down to the smallest new value
Routed edge slot length quoting (if done?) is not going to be easy to any-file-set-automate, but if GerbView also reported a simple table of the minW-maxW-SigmaL for each file, the user could specify a FileName containing their routing cuts, and the 3 numbers minW-maxW-SigmaL may be enough for a pricing calculator ?
When do you mean this check is done ?
During web quote ? or as they load PCB files for manufacture ?
What tools do you use now to create/merge the filmworks/drills, and panelize ?
Is this just a sweep over tracks (reading their width setting and finding the minimum of it) or does this also take zones (polygons) into account? (For zones one would need geometric calculations to find the minimum width. This could get quite involved.) If it does not take zones into account then this result will give you a false sense of security.
This is what I meant. If the purpose is to load and check any gerbers, not only those produced by KiCad, there’s no guarantee that a track or a zone or a pad is made with certain gerber graphical feature. If KiCad doesn’t already have geometric functions for all possible gerber shapes and/or features it will really be quite involved, to find minimum widths and spaces. Naturally I wasn’t speaking about finding minimum value amongst group of existing values.
Good question, there was a thread about someone worried about curved notches in touching zones.
It seems dropping the Zone MinW is a quick way to shrink that, with minimal other impact.
It seems KiCad ->GerbView manages as a distinct polygon, so a .01mm polygon might be able to avoid a false-error. This was a rare case, but it is a real reason to have a somewhat mathematical polygon width.
Well, yes, even being able to reliably load other-flows file sets I’d taken as a can of worms, and this was taken as being a Quote KiCad Design(WEB) or Report KiCad Design(FAB) type macro-button
Maybe PcbNew can drop in as a Gerber comment, the smallest clearance, & clearance list, to pass that missing piece over. So the default gerber info is a few lines larger.
That’s a pcbnew change, but when doing that, it might also sweep for the layers Min/Maxes and report those too. Then it’s all there for a text editor or script bot to peek at.
Expanding on this (would become a feature request for pcbnew File Limits info as comments in Gerbers)
The above is natural for all coppers, … but leaves a little blindspot for Drill info.
Turns out that is almost already covered, as default Excellon is used by most PCB FABs and there is an Drill optional File Format Gerber, and that loads/renders identically in GerbView.
- but this really needs an option to generate both choices, to avoids users forgetting to update one.
Quote KiCad Design(WEB) would use Gerber drill info, and the
PCB FAB would load the Excellon, and check the Gerber, ie both are used by fab.
GerbView would logically get some spreadsheet like pane, that shows these file limits comment lines.