Hi,
I have a PCB that fail manufacturer process because pads and aperture are defined as CON (polygons) and not object.
The images attached was sent by my manufacturer. He said that yellow ones have the problem.
So not all pads have this problem! Can you help me to solve this?
Moreover, is there a way to see on kicad gerber viewer the definition CON or CIR as the table on the images of manufacturer?
Thank you!
Note: I’m using last version (kicad 5.1.9-1)
Thank you for your answer but I tried to generate the gerber with or without “x2 format” and the problem is still present.
In GerberView with funcion “flash element filled” or “flash element contour” I see the problem pads that don’t became “FILLED” (yellow color). Other correct pads became filled (green color).
It’s possible that “rounded contours” give this kind of problem?
How can I solve?
Thank you.
Yes. They are exported with different strategy compared to round or square pads.
See Apologies from atommann (an engineer from JLCPCB), about Gerber X2 files at JLCPCB to see how complicated this can be. Note: it’s about version 5.99. You can try to open a copy of your design with 5.99 and try different plotting options there.
There are several issues on gitlab about the definitions of flashed pads in gerber files, for example this one:
The issue was reported for V5.1.6 almost half a year ago (2020-09-22) and closed with a “fix-committed” on 2020-11-05. It’s also got a milestone for V6, so apparently it has been decided to not put the fix in V5.1.x
I opened a random gerber made with KiCad V5.99 and zoomed in on a rounded rectangle:
In the status area in the lower left corner you can see it is of “type” “apt_macro RoundRect” and has D code 21.
Searching for D21 in the gerber with a text editor gets these sections:
%TD*%
%TA.AperFunction,SMDPad,CuDef*%
%ADD21RoundRect,0.250000X-0.362500X-1.425000X0.362500X-1.425000X0.362500X1.425000X-0.362500X1.425000X0*%
and a bit further:
%TD*%
D21*
%TO.P,R1,1*%
%TO.N,+24V*%
X206352854Y-112770000D03*
%TO.P,R1,2*%
%TO.N,Net-(D1-Pad2)*%
X212277854Y-112770000D03*
A bit of more digging reveals that an aperture macro for a rounded rectangle is defined as:
%AMRoundRect*
0 Rectangle with rounded corners*
0 $1 Rounding radius*
0 $2 $3 $4 $5 $6 $7 $8 $9 X,Y pos of 4 corners*
0 Add a 4 corners polygon primitive as box body*
4,1,4,$2,$3,$4,$5,$6,$7,$8,$9,$2,$3,0*
0 Add four circle primitives for the rounded corners*
1,1,$1+$1,$2,$3*
1,1,$1+$1,$4,$5*
1,1,$1+$1,$6,$7*
1,1,$1+$1,$8,$9*
0 Add four rect primitives between the rounded corners*
20,1,$1+$1,$2,$3,$4,$5,0*
20,1,$1+$1,$4,$5,$6,$7,0*
20,1,$1+$1,$6,$7,$8,$9,0*
20,1,$1+$1,$8,$9,$2,$3,0*%
I also did a search for the way your gerber viewer presents data, but there is no “CON” nor “CIR” in the gerber file. I do not know where those names come from.
Is the way the data is presented in here compatible with your manufacturer?
Gerbview in V5.99 can list D codes in a table: Gerbview / Tools / List D Codes
I also opened an older version in V5.1.9 and there the rounded rectangle does not have a D Code, but is defined as as a Polygon instead (on several layers), so the previous post from V5.99 looks like it is really fixed there.
Addition:
There should be a selection method for highlighting specific D-Codes in Gerbview, but apparently this is currently broken (Both n V5.1.x and V5.99)
I have made an issue out of this at:
With the drop down boxes to highlight different sorts of objects you probably have similar functionality then with your spreadsheet overview, although I do not really know what the columns in your spreadsheet represent.
Thank you, I’m going to try with 5.99.
Where is the correct link to download it? it’s the nightly version
https://kicad-downloads.s3.cern.ch/index.html?prefix=windows/nightly/ ?
Anyway I don’t know how the program of the manufacturer (first topic image) load the definition of CIR or CON. I only know that CON means build with polygons and for the manufacturer is a problem to create PCB with this kind of shape.
I’ll let you know if 5.99 solve this.
Thanks
Indeed. I checked this in KiCad-nightly V5.99, from a few days ago.
I do not have windows, so can not help there, but the link you show is on:
The latest nightly unfortunately has an annoying bug where all icons disappear, so you may want to wait a day (or two).
So are we saying that 5.1.9 is still generating invalid Gerber files or is this a bad fab
I would not go as far as to state that gerber files from KiCad V5.1.x are “invalid”. lots of PCB’s have been made with it, and not many complaints.
I would not say the “fab is bad”.
There is some discussion about this in #5756 I linked earlier. There are very valid reasons for wanting to have pads defined as D-codes instead of just some random polygon. An important reason is for generating test vectors for connectivity tests. To do that you want to know all pad locations, and to know that, you first have to know it is a pad.
As a side effect it also reduces file size, because the shape of such a pad is defined only once.
I do find it curious though why it was only marked for V6.
I confirm that problem of manufacturer was only about setup of connectivity test if the shape is a polygon.
I tried version 5.99 and pads in gerber are absolutely different than version 5.1.9. Here an image with “flash element filled enabled”. As you can see the pad are now filled (respect the old one in my previos answers)!
Let’s see if is ok for manufacturer! …and hope V6 will arrive as soon as possible!
Thank you all.
You can (mostly) check it yourself.
Are the previously offending pads now defined in a similar way then the pads that already got accepted by your manufacturer?
Nightlies are nightlies for good reasons And therefore not released as stable versions. New bugs get introduced daily 
but hopefully each day also more bugs are fixed then added.
The utmost mayor issue with the nightlies is that once you save a project in it, it can no longer be opened with KiCad V5.1.x Especially the whole file format for Eeschema has been changed.
I remember also some manufacturers having problems with Gerbers generated with KiCad’s nighties (See Eeliks remark earlier for example)
On the other side, help with finding and reporting issues is always welcome.
There have been a few forgotten cherry picks into 5.1.x
Policy is that 5.1.x gets no new features, but crashes and errors get fixed. If there are problems getting a good PCB from the file, then this smells of error.
Using 5.99 in alpha status to get a PCB made is not an acceptable choice for a professional user, then you have to pick a “blessed” Nightly that does not contain bugs that affect your project
An intermediate workaround could be to keep on using V5.1.x for now, and only use the “blessed nightly” for creating gerbers, so there is not much area for bugs to affect you.
JP Charras is pretty competent in this area and is actually in close contact with Ucamco. I would say that KiCad definitely doesn’t export invalid gerbers (except for unintended bugs). He explained in the above linked issue that the previous strategy is valid gerber. But there were also good reasons to change it for v5.99. By policy no new features are added to the stable versions, and changing gerber generation would have been way too radical.
In general if someone can’t interpret the gerbers made by KiCad it’s extremely likely that the interpreter isn’t right. It may be too much said that it’s “buggy”, but as far as I have observed and tried to get familiar with gerber it looks like there are several reasons for these problems:
Etc.
The standard and the format aren’t problematic themselves, but the historical development has caused practical problems in form of various defective or just differently behaving software which are very difficult to fix.
[What I say next is even less a fact than what I said above, just my personal opinion.] In the thread about JLCPCB problems we can see how ridiculous situation we can get into with these problems: they use two different applications which have different problems. KiCad has produced valid gerbers all the time but they can’t read them. As far as I have understood they will workaround the problems not by updating or fixing the applications but by manipulating the gerbers so that they can be interpreted. I don’t blame them if they need to continue using defective software, but this shows that we can’t expect the situation will get any better soon. It’s quite frustrating to see features like gerber X3 added into KiCad when we can be almost 100% sure that most of the users can’t use it because the manufacturers won’t understand or accept it anyway within 10 years or so.
That’s actually what I suggested (working on a copy), but I wasn’t explicit enough. Thanks to davidsrsb and paulvdh for warning about the unstable 5.99.
The JLCPCB issue had a safe work around of not using X2.
Using a 5.99 step is not a safe work around as nobody is going to say that any 5.99 build is going to do a bug free conversion for my project. We are using KiCad for commercial designs, where a bad board can end up costing a lot of money by the time it has been assembled and delivered back for test.
Even worse, we may have got lucky with the vendor of the test boards and when buying in volume hit this issue. The OP was lucky that the fab rejected the board and did not just go ahead with errors.
Yes, of course. But who’s gonna say that the same thing can’t happen with 5.1? Nobody can guarantee that gerber export is bugfree there, either, or that the final product is OK if the test board has passed the test. The only thing we got with 5.1 is longer history of known issues (and these issues aren’t bugs in KiCad).
It should go without saying that if the development version is used, the user must be extra careful and do extra checks for the gerbers. But gerbers should be checked anyway, no matter what software.
In the end each user, individual or company, must decide what risks they are willing to take and how careful they need to be and how much they need to communicate with the manufacturer.
Yes, the output from version 5.99 is more risky because we don’t have enough data to tell how different manufacturers interpret the gerbers. Whether the files are bug free as far as the file format goes can easily be checked with the Ucamco reference viewer and some other viewers. The files must be inspected closely to see if they are what is expected. After that the only problem is if the manufacturer can interpret it. In this case they couldn’t interpret the output from 5.1, so it’s logical to try 5.99.
Euhm,
The manufacturer would have been able to make the PCB’s from the gerbers generated by KiCad V5.1.x
The way I read it, the manufacturer got into the problem while preparing files for the connectivity tests.
I applaud the Manufacturer for bouncing this back. For reasons Eelik summarized, a lot of manufacturers just do some weird things behind your back with your gerber files, then produce something that you have not ordered and charge you extra for the time they put into it.
Just the fact that the Manufacturer rejected it says a lot about the quality they want to make.
But I also agree with davidrsb. Problems with large production runs can cost a lot of money very quickly.
And I agree with eelik: There is no guarantee that V5.1.x is bug free. There is also no guarantee that “altium” “eagle” or any of the other PCB programs is bug free.
If you like the braces & suspenders approach, then you can generate a set of gerber files both in KiCad V5.1.x and in V5.99 and then use a graphics comparison program to visually compare the differences. There are several of these programs, mostly geared toward version control such as used with git.
This:
https://html.duckduckgo.com/html?q=visual+diff+of+KiCad+PCB
Brings up for example:
https://cadlab.io/blog/visual-version-control-kicad-officially-released
Or even simpler:
You can directly load F.Cu_V5.1.x and F.Cu_V5.99 into gerbview to compare them.
Managing those files can be confusing, and it is easy to (for example) send the wrong set of gerber files to your manufacturer after you’ve carefully compared them. Humans also are not flawless.
Unfortunately, that doesn’t actually address the core issue here, because you don’t have the CAM software your particular manufacturer is going to use to rasterize the gerbers.
