After finishing my project I used ViewMate to verify the gerber files and upon opening the files it complains about self-intersecting polygons. For example, with BLDC_controller-F.Cu.gtl it points to the location illustrated below:
Observer that the figure above is made using “show outlines of filled areas only in zones” but those extra intersections disappear if I choose “Do not show filled areas in zones”:
I also decoded the kicad generated gerber files BLDC_controller-F.Cu.gtl (197.2 KB)
with speadsheet program and it seems that the kicad is indeed generating self-intersecting polygons or at least polygons that are adjacent to each other sharing the edge points with six digit after the decimal separator.
This is too confusing, don’t make people jump through hoops trying to figure out what you have done. Most people will not have ViewMate installed. None of your git files correspond to the first picture.
Can you delete everything and create a report based on a SINGLE set of reproducible data.
Your zones look a little more complex than they need to be, and they are probably self-intersecting from the start. Try drawing simpler zones and let KiCad take care of the clearances.
Sorry for the confusion. I changed the pad connection back to solid and updated the github repo. Now they should be in sync. They produce the same gerber files (only with different time stamp).
Ok, I have reproduced the problem, with an error reported in Viewmate.
As far as I can see, the Gerber file produced by KiCad is correct, and follows the rules for “cut-ins” in polygons. Coincident points are allowed for the cut-in, but they must not produce overlaps, and KiCad seems to follow that rule.
There does not seem to be anything wrong or inadvisable in the way you have drawn your zones.
Therefore, I think this is probably a glitch in Viewmate. I notice that Viewmate reports coordinates with 5 digits after the point, whereas the file has 6 digits, but that may be irrelevant.
G36/G37. The whole section is now much more specific. An example was added to illustrate how to use of polarities to make holes in areas, a method superior to cut-ins. See 4.14. We urge all providers of Gerber software to review their handling of G36/G37 and to use layers to create holes in areas rather than using cut-ins.
and more interesting stuff on page 27:
Processing Gerber files is inevitably subject to rounding errors. Contours must be constructed robustly so that allowed perturbations due to this rounding do not turn an otherwise valid contour in a self-intersecting one. See 4.20.2.
and on page 136:
The cut-ins are rather complex to create on output; on input in CAM the cut-ins must be removed and the original clearances restored, again rather complex. Use this more complex construction only if there is a good reason not to use the anti-pad method.
Does anyone know if it is possible to select between cut-in and anti-pad methods in KiCad?
I had a look at the source, I didn’t see any option for anti-pad method. There is only the option for zone fill mode : polygon or segment.
Changing KiCad to use the anti-pad method would require some changes to the code framework. There are six different output file formats, and KiCad generates a top level polygon which is then passed to a plotter class specific to the file output type. It would need to change to have a data structure specific to Gerber output. It’s doable, but I don’t think there would be any appetite to change it.
I was confused about the same warning showing up in Viewmate checking my gerber files with another Gerber Viewer than GerbView in KiCad. I found an interesting article that pointed to some problems with interpretations of the Gerber file standard, that leads to different outputs with different tools.
The article is irritating what is right and what is wrong because the customer wanted the shape that ViewMate shows. I focused on the conclusion at the end which clearly said “The image shall match the CAM Program A view of the data”.
I think the testfile is a good way to test that your programs give the same result for that kind of error and i am a bit puzzled too because i don’t have deep knowledge of gerber file specifications and errors at the moment (just at the beginning with that kind of errors and format problems).
I just wanted to inform other developers that there seems to be more problems for file usage with KiCad in combination with ViewMate
As far as I understood the problem with my file had nothing to do with rotation of primitive shapes but this is also really interesting. I find this proposition “The image shall match the CAM Program A view of the data” a bit strange because how do you know that the CAM program A views it correctly?
The latest version of the gerber specification defines the conformance for the writer as following:
A conforming Gerber file writer must write files according to this specification. A current conforming Gerber file writer cannot use deprecated constructs. A writer is not required to take into account limitations or errors in particular readers. The writer may assume that a valid file will be processed correctly.
For the reader:
A Gerber file reader must render a valid Gerber file according to this specification. A current reader may support some or all deprecated format elements as they can be present in legacy files. To prepare for future extensions of the format, a Gerber file reader must give a warning when encountering an unknown command or macro primitive; it must then continue processing ignoring the unknown construct. Otherwise there is no mandatory behavior on reading an invalid Gerber file. It is not mandatory to report any other errors – this would impose an unreasonable burden on readers and may result in useless messages in some applications. It allowed to generate an image on an invalid file, e.g. as a diagnostic help or in an attempt to reverse engineer the intended image by ‘reading between the lines’; however, as an invalid Gerber file is meaningless, it cannot be stated interpretation of the file is valid and another invalid. A reader must also give a warning when it processes a file exceeding its implementation limits.
It even had need to make the following clarification:
The responsibilities are obvious and plain. Writers must write valid and numerically robust files and readers must process such files correctly. Writers are not responsible to navigate around problems in the readers, nor are readers responsible to solve problems in the writers. Keep in mind Postel’s rule: “Be conservative in what you send, be liberal in what you accept.”
The articles concludes that the supplied gerber file did not comply with the gerber specification and therefore there will be no obligation for the reader to read it correctly even after the specification was clarified.
That’s a fair question. The author of the article does a step by step manual implementation of the primitives following the spec, and his manual result matches CAM program A.
I think the problem is not that the file is invalid, but that the interpretation differs from the writer to the reader. The jumble of shapes could be what was wanted, the gerber reader cannot really tell. It requires some human noodle to look at it and think “oh, that looks wrong”.
The file supplied by the customer was supplied with an improper interpretation of the rotation factor applied to the primitive shape within the macro code. The customer’s data had the rotation applied to the primitive shape centroids. The rotation factor applied to the primitive shape should have been about the macro origin (X=0, Y=0) as required by the RS-274X (Gerber) specification.
The undesired shape is the result of an error supplied by the customer since their data was not 100% compliant to the Gerber specification.
And I agree with you about the human factor. But my point is that it is unreasonable to demand that the PCB must be manufactured to match the representation of any particular reader implementation which may or may not accurately represent the gerber files.
