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?