Thermal reliefs for pads in filled areas not supported?

[matthijskooijman]

I tried using a ground plane, using thermal reliefs for the pads inside the plane. However, it seems that pcb2gcode completely ignores these termal reliefs and pads, and just keeps the full ground plane around the pad. I haven't dug into the gerber files to see how these thermal reliefs mare specified exactly, but I'm attaching a small testcase here.

Here's an image of the board (as output by pcb2gcode, so it seems that the thermal reliefs are properly read by pcb2gcode):

The test files are here: https://gist.github.com/matthijskooijman/6ec1c7f5a11d462127bf

noname.kicad_pcb is the original board file made in KiCad. polygons.gbr and segments.gbr are the Gerber files generated by KiCad (with the filled zone set to "polygon" and "segment" fill mode respectively). front.ngc is the G-code generated by pcb2gcode, identical for both Gerber files. The millproject file used is also included.

I'm using pcb2gcode 1.2.2, locally compiled.

If this is indeed not supported, adding support would be great. If I just missed a setting somewhere to make it work, that would be even better :-)

[matthijskooijman]

I also tried with optimise disabled, and with the offset setting to 0.01mm, in case the spots were too small to mill away with my tool, but that didn't change anything.

I just noticed that some area inside a trace (I had a small triangle inside a trace where the trace passed by a pad and connected to it using two angled small traces from both sides) wasn't milled away either. More generally, if you have a trace that forms a loop (I tried a simple rectangle), the milling path only passes on the outside, the inside of the trace isn't milled, resulting in a filled rectangle, instead of only a small trace on the border of the rectangle. This is probably also what happens with the thermal reliefs, I suspect.

[corna]

Unfortunately one of the biggest limitations of pcb2gcode is its inability to handle this kind of situations: a "hole" inside a bigger area. This applies to multiple cases, like this for example

Input:

Output:

As you can see the central part of the pink area has just been ignored. Currently I'm working on the tile feature (issue #16) but after it I'll try to implement this.
Thanks for your bug report

[corna]

I've done some work on this and it mostly works now. Can you test it? Pull the changes from my repo, compile and run it.
Use a small offset value, or the "holes" will be deleted.

[matthijskooijman]

Woah, awesome! I'll try to find some time for a test run this weekend!

[corna]

I've moved it in a new 'dev' branch, here

[matthijskooijman]

I ran your dev branch on my original design, as well as the testcase above, which seems to work nicely (judging from visual inspection of the generated gcode using http://fablabamersfoort.nl/gcodevisualizer/). I'm not sure when I will be able to actually test the gcode on my mill.

I did notice another problem with the outline while testing the above testcase, but that seems unrelated to internal gaps, so I'll open a separate issue for that.

[matthijskooijman]

I just tried milling my design yesterday, which worked well enough. Here's the result:

Some traces are a bit small, probably because I slightly underestimated the offset setting. However, I couldn't increase it above 0.15, since then I got:

$ pcb2gcode --back Grbl-B_Cu.gbr --offset 0.20
Importing front side... not specified.
Importing back side... DONE.
Importing outline... not specified.

Exporting back... Internal Error: Failed repairing @ (2390,417)

Importing drill... not specified.
END.

and no back.ngc would be generated. Here is my full design to reproduce: https://gist.github.com/matthijskooijman/2c0e7fb0c1fe2d4c88f7

I could reproduce this using the simple testcase from my first post as well, but that needs a bigger offset:

$ pcb2gcode --front polygons.gbr --offset 0.50
Importing front side... DONE.
Importing back side... not specified.
Importing outline... not specified.
Exporting front... Internal Error: Failed repairing @ (781,779)

Importing drill... not specified.
END.

Another think I just noticed, is that, with offset=0.15 and when you omit --outline, you get:

$ pcb2gcode --back Grbl-B_Cu.gbr --offset 0.15
Importing front side... not specified.
Importing back side... DONE.
Importing outline... not specified.
Exporting back... 
Warning: 2 internal toolpath cutoffs have been removed.
DONE. (Height: 55.5906mm Width: 67.5256mm)
Importing drill... not specified.
END.

Looking at the resulting gcode, there are indeed two cutoffs missing:

I can't quite figure out what's special about these two. The gaps are just under 0.5mm wide, so offset=0.15 should be small enough to cut them. Their also identical to a few other gaps, differing only in rotation. With --outline specified, the warning disappears and the gaps are milled correctly.

When trying to reproduce this with the simple testcase from the first post, things get a bit weirder.

With offset=0.15, everything works normally:

With offset=0.15, I get no errors, but the gaps are missing a corner, just cutting a straight line instead:

Looking at the gerber file, the gaps are 0.5mm wide, so an offset of 0.2mm (meaning tool width of 0.4mm) should be able to handle that? I couldn't see if adding --outline prevented these warnings (like it does with my full design), due to #25.

If I increase the offset further, to 0.3mm, it starts dropping gaps:

$ pcb2gcode --front polygons.gbr --offset 0.30
Importing front side... DONE.
Importing back side... not specified.
Importing outline... not specified.
Exporting front... 
Warning: 2 internal toolpath cutoffs have been removed.
DONE. (Height: 41.3501mm Width: 41.3416mm)
Importing drill... not specified.
END.

I'm not sure why this drops just 2 of the four, since they should be identical (and, AFAICS, all of them should be too small?).

Further increasing the offset lets pcb2gocde drop all four of them:

$ pcb2gcode --front polygons.gbr --offset 0.40
Importing front side... DONE.
Importing back side... not specified.
Importing outline... not specified.
Exporting front... 
Warning: 4 internal toolpath cutoffs have been removed.
DONE. (Height: 41.5501mm Width: 41.5416mm)
Importing drill... not specified.
END.

I did these last tests with both segments.gbr and polygons.gbr from my testcase, resulting in identical gcode in all cases.

[corna]

Thanks for the complete report. Unfortunately I've noticed that the current implementation of surface.cpp doesn't behaves well with internal cutoffs and I'm afraid this is the best we can do without rewriting the whole core.
I'll try to fix the "Failed repairing ..." and "Outside path reaches image margins at ..." (#25), but I'm afraid that some internal cutoffs will disappear randomly, especially when the cutoff windows become small.
The best solution would be to rewrite the core using a vectorial approach, using the wonderful Boost geometry library (for example, using the buffer function to grow the paths), but the gerber file format specifies a virtual photoplotter, and importing this in a vectorial space is not easy.
I'll see what I can do.

[corna]

With commit 70ba491 I've pushed the experimental algorithm for "internal toolpaths", able to detect and process thermal pads. The new algorithm is disabled by default and can be enabled with --internal-toolpaths
The algorithm works decently when the offset is rather small, at least smaller than the clearance of the circuit, while it randomly freezes when the offset is too large. Anyway, it works well enough when you choose a sane offset.
I think this hit the limit of the current surface.cpp, I can't do any better without rewriting the whole core
I've tested it with some circuit and it works for me, can you test it with a batch of yours?

[corna]

Fixed, see v1.3.0