Fusion 360 post processor file for Plamac

Have to correct myself after reading through the QtPlasmaC documentation.
Centerpunch uses the spotter tool, which is the torch firing short enough to only make an indentation. Very clever. Has its own setting on the Parameter page, firing time most notably. So let the M3 $2 S1 stay.

Actually, when I think of it. I think its a bug/feature of PlasmaC that M3 won't allow a line above with only coordinates, but must include also the move command.
Not ok

Ok

I've been trying to figure out this post processor with F360 as well. Thanks Hakan for your help, I think I also found that there should be an "if centerpunch" statement in the onRapid function around line 407.
if (centerPunch) {
writeBlock(String("G0"), x, y);
}
else {
writeBlock(gMotionModal.format(0), x, y);
}
After adding this, for the one part I was testing it seemed to issue all the G0 commands prior to the M3 commands. However, when I tested a part with more holes, on the last one it failed to issue the M3 start command and was not going through small hole section at all in the post processor.

I found that the difference evaluated by this line 502: "if (Vector.diff(circleBuffer.start, circleBuffer.end).length < toPreciseUnit(0.01, MM)) { " was 0.22 something which was greater than the allowed tolerance, but I am unclear as to why. All the other holes of same size were showing 0 for this difference. If I raise the threshold to 0.25, the centerpunch command gets executed, but I'm not sure what the ramifications are on doing that. If I don't change that, the else gets evaluated on line 577, causing the centerpunch to get skipped: writeBlock(gMotionModal.format(circleData.clockwise ? 2 : 3), xOutput.format(circleData.end.x), yOutput.format(circleData.end.y), iOutput.format(circleData.center.x - circleData.start.x, 0), jOutput.format(circleData.center.y - circleData.start.y, 0));

N375 M5 $-1
N380 G0 X12.92307 Y10.51936
N385 G0 X37.03129 Y123.7121
(36.1442, 124.511, 0)
(37.0313, 123.712, 0)
(37.0313, 123.712, 0)
(0)
(0)
(TRUE)
(TRUE)
(CENTER PUNCH THE HOLE ONLY)
N390 G0 X36.1442 Y124.511
N395 M3 $2 S1
N400 G91
N405 G1 X0.00001
N410 G90
N415 M5 $-1
N420 G0 X37.03129 Y123.7121
N425 G0 X82.04218 Y124.49036
(83.2358, 124.511, 0) //Circle buffer center
(82.0422, 124.49, 0) // Circle buffer start
(82.042, 124.511, 0) // Circle buffer end
(0.020638258210129726) // Difference
(0) // Plane
(TRUE) // Small hole section
(TRUE) // Centerpunch
N430 G3 X82.042 Y124.511 I1.19363 J0.02064
N435 G1 X82.04218 Y124.49036
N440 M5 $-1
(END CENTERPUNCH)

It has worked for me although I only have done some 10s of holes and center punches.
I looked in the cps, the circle data seems to come directly from Fusion. Can you see that the tool path circle has a gap in fusion?

How would I check this? Toolpath looks complete when zooming in and the "show toolpath data" looked similar for all the circles. I also tried a different part and it came out fine. The selected contours are all closed chain, so not sure what is missing with this part.

Tried to follow how this works in the onCircular function.
Three lines down there is a test with 0.2 mm line 452. That fails for this circle.
Then ends up doing a new circle line 476, which is the one that isn't really right.
I don't understand this with merging circles but I guess it has something to do with that.
Edit: In the fusion simulation of the tool path it is clear that a circle is made up of several circle segments, which is then supposed to be assembled to a full circle in the post-processor. Guess something went wrong with the assembly.

Interesting, thanks for looking into that. Everything I've cut so far is with merge circles off, but perhaps I should check it and see what happens. What is odd is that there are three other holes in the bolt pattern of identical size without this issue. What does the check in this if statement actually do? Line 502: if (Vector.diff(circleBuffer.start, circleBuffer.end).length < toPreciseUnit(0.01, MM))

What would happen 0.01 MM was increased?

You should try checking the Merge Circles box.
The test checks for a full, closed circle. If he distance between start point  and end point is < 0.01 mm it is a full circle.
Have to allow something for numerical precision but 0.2 mm seems a lot when it should be 0.

I see what happened. After the almost full circle, you got in a very short segment that should have been merged with the circle.
But instead of merging, it ended up as an own short segment. See line N430 in the G-code you attached. There is the small segment.
 

Thanks, I tried the Merge circles, with the same outcome as before. I also found a test in the manual “isFullCircle()”, which returns False for this hole and true for all of the others. Should I try redrawing the hole or is the issue more so with the CAM processing? Maybe I should just keep testing different files and see how often this issue actually happens. Not a big deal to hand mark and drill this part, but more so just want to understand how to potentially resolve it he underlying issue and improve the robustness of the post processor.

I misunderstood that. N430 G3 is the full but incomplete circle. It  ends at 9 o'clock and finishes the gap with a straight line N435 G1.
I wonder why fusion chose a line between S2 and E2 instead of a circle segment. Do you have the Tolerance in the Passes tab tightened down?

That's quite interesting, but also odd. I have the tolerance set to 0.0004 in, which may have just been the default.  If I raise this above 0.021 should it join the circle?  I also have smoothing checked, which may be another thing to try removing.