[gerber] Error in large filled regions

[Boris Popov]

Attached please find a gerber file which doesn't import propery. The unfilled areas (I've highlighted them in red) at [6mm,19mm] and [24mm,19mm] should be fiilled just like all surrounding copper. The cam350 displays them correctly as well as gerbv (see attached screenshots).

FlatCAM version 8.1 on Ubuntu 14.04. The gerber file created in Pulsonix 8.0.

[Juan Pablo Caram]

Please edit the description and include screenshots from FlatCAM and from your original CAD program. Indicate CAD program name and version.

A good reference Gerber viewer is gerbv. Please try to check the file with it and post a screenshot as well.

[Juan Pablo Caram]

Are the regions marked in orange the one that are missing?

[Juan Pablo Caram]

The Gerber is extremely large (~5000) lines for the geometry it generates.

Could you try to isolate the problem in the smallest possible Gerber that shows the problem? Just delete parts of the Gerber until only the problematic region is left, then compare again with Gerbv.

[Boris Popov]

Yes, I've highlighted offending areas. Frankly, gerber's data are mostly Greek to me, I'll try to play with it, but no promises at all... As for the size, this could be the way how Pulsonix does things, but manufactures never complained about it.

[Boris Popov]

After some twiddling with output options, it became clear, that disabling 'Hardware Arcs (G74, G75)' option solves the problem. Hope this helps.

[Juan Pablo Caram]

Arcs should be fully supported.

You can locate areas starting and finishing with G36 and G37 respectively. Those are polygons. You can safely delete those whole sections including those commands.

[Christian Halter]

missing Traces in Flatcam 8.4 on Windows 7

[Christian Halter]

correct Traces

[Christian Halter]

Gerber-File from Multisim 14

[Thomas Duffin]

I have also experienced this issue, I managed to get around it by modifying the guard spacing of my copper pour (which I think just simplified the geometry slightly).

It did seem to be down to the number of polygons being generated, but I have no real evidence of this yet.

A bit more information that may be useful.

• Working gerber file has 2816 lines.
• Broken gerber file has 2521 lines.

So it isn't purely down to the length of the file.

• Broken gerber outputs "joining 284 polygons" when opened.
• Working gerber outputs "joining 263 polygons" when opened.

The only modification I made is the guard spacing of the copper pour, so I did not add or remove any 'complex' shapes.

I use Easy-PC for my PCB design so it is not CAD package dependent.

I will look into this further.

[Juan Pablo Caram]

Does anyone have a small file for which this happens?

[Juan Pablo Caram]

Attaching a reduced version of bv.gbr. I removed everything except the single polygon that causes the problem. In FlatCAM there are no polygons generated for this file at all. Other gerber viewers do show something.

I don't have time to debug this now, but this file should be much more manageable for debugging.

[Juan Pablo Caram]

Here's what's happening: The missing polygon in bv_reduced_7.gbr is parsed by FlatCAM and then converted to a Shapely Polygon, but it's "invalid":

>> poly = Polygon(path)
>> poly.is_valid
False

And then FlatCAM attempts the easiest fix: poly = poly.buffer(0), which doesn't really fix it and results in an empty polygon.

The polygon is invalid in the first place because the 1st and last points don't exactly match and the last segment intersects with the first. This is not a problem in the Gerber, but in the approximation FlatCAM does for arcs (it discretizes the arc into straight line segments.) I suspect that the real bug is that FlatCAM does not use the exact last point of the arc but whatever comes out of the formula for the arc, which involves calculating the angle for the last point and the re-computing the last point using the formula and the angle. Then numerical error causes the difference.

These are the 1st and last points in the polygon:

[1.2, 21.775000000000002]
[1.2, 21.77497830976977]

which look very much like just numerical error.

So we could try to fix the code for making an arc, or determine if the last point is needed. If it's not, just removing that last point would solve the problem.

[Thomas Duffin]

If it is just down to floating point errors, then there is probably little you can do to 'fix' the arc generation code without making some big changes.

If it is a closed polygon then the last point should always be the same as the first point, correct? Therefore, if the last segment of a polygon is a curve, simply replace the last point's coordinates with the polygon's first point's coordinates.

You could always do some tolerance checks, but surely that assumption would be a valid solution?

I've been looking for the bug on and off today, clearly you've beaten me to it!

[Juan Pablo Caram]

Replace exact last point of arc. Fixes #110.

→ <<cset 616237ea93ae>>

[Juan Pablo Caram]

For the curious, the last point in an arc is provided in the arc command in the Gerber. So I replaced the last "computed" point with the exact "provided" one.