I spent an hour tracking down an issue, hoping you can point me in the right direction.
TL;DR: A 2900-line job on Shapeoko XL with carbide motion stops every time with no error, always on the same line. Nowhere near limits. Spindle is off. G-Code from Fusion 360 with the carbide3d post-processor, but also happens with the grbl post-processor. Only G0,G1,G2 instructions near where the machine stops. Macbook Pro, does not go to sleep, Carbide Motion 3.0.366 (the latest). GRBL is up-to-date too. Same thing happens with Universal Gcode Sender
I made a set of 128 small pockets in Fusion 360 to put threaded inserts into the Shapeoko XL wasteboard. Post-processed with the carbide3d post-processor. I cut one of these pockets into a scrap piece of MDF, which worked just fine. I then tried a dry run of the entire job an inch above the wasteboard, and saw carbide motion stop at line 309. Tried it again, same thing: line 309. Nothing interesting around - the code is simply repeating the same countersink G0, G1, G2 sequence for the Nth time. A snippet below:
Please change the measurement system to metric and then re-calculate the toolpaths and try the resultant file.
It seems that 3 digits of accuracy isn’t sufficient for Imperial (and perhaps not metric in certain cases) — since Fusion 360 doesn’t offer an option for increasing this, it’s easiest to switch to metric which it calculates with greater precision / more decimal places.
I did finally get around the issue after a combination of things, though there isn’t much to be learned from my experince:
I converted everything in the model from inches to mm
I re-created the CAM operations - re-generating the tool paths after my changes was not enough.
I noticed that my soft limits were incorrect, which is weird because I made sure to set them when I built the machine. It looks like some combination of Carbide Motion and GRBL mangled GRBL’s settings ($22 was also incorrect, despite my setting it up), though I do not have evidence to back this up.
I also dug into the post processor and investigated ways to increase precision of the emitted GCode. If this issue returns, I will write it up and post a fix to the post processor here.