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.
Agreed, but it may catch some errors in Gerber output generated by KiCad-nightly V5.99.
Maybe you can get still a bit closer to the real thing by asking your manufacturer to do any post processing on your gerbers and then send the result back to you for inspection. (But I’m not sure the files are still in Gerber format then).
And there is also the common practice of ordering a prototype and inspect the actual PCB. It’s also the area of previous experience with a PCB manufacturer and the trust you have in them.
Thanks for that, very interesting.
At least I could get confidence that a 5.99 generated Gerber was very similar to the 5.1.x original.
This would also be useful in reverse engineering old Gerbers into KiCad
Fairly off topic resoponse to davidrsb
Just recently I reverse-engineerd a PCB for fun (& to gain some experiene).
I had a set of Gerber files, made in an old protel program and a .pdf of the schematic.
I created a KiCad project, re-did the schematic in Eeschema, and back imported the gerbers into Pcbnew.
That old Protel program generated Zones by painting them with thin tracks, and it even painted pads as overlapping tracks. There was a 100 pin or so (Wiznet 5100 Ethernet controller) and each pad was 3 long tracks and two shorter tracks on the ends. Th manufacturer in this thread would surely have complained about that!
I just deleted all that painted stuff, imported netlist & New footprints from KiCad’s libraries, and put them on the end of the tracks that got back imported from the Gerbers.
This worked quite nice. The existing tracks automatically adopted to the netlist when real footprints were put on top of them. I made a few errors in re-creating the schematic from .pdf -> Eeschema. and these got caught by DRC because netlist and physical copper did not agree.
yeah, it is a good idea to check. for the record, I have experienced gerber-breaking changes going to 5.99 (not bugs though per se, just changes that affected my zone fills).
A local way to compare to images
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
