I ran the file and did not find a runaway, but I'm not 100% sure of that. There were a few challenges to overcome.
I do not have a table with an X dimension of 24". I'm testing on a Shapeoko2 with an effective X dimension of 11.5 inches (after you take the size of the X carriage into account). So I turned the X motor power way down, disabled limit switches, and let it crash in X. This may mask a runaway in X if the runaway did, in fact, return in short order.
I did not find a runaway move in 3 runs (Coolterm) against different builds (master, edge (444.16), and my current experimental branch). I might have missed a move error due to the X dimension problem as it could have happened when X was crashed.
Would you mind dry running the file again, and perhaps generate a file with 10" wingspan I can run? If it fails again can you record the approximate line number and some description of the failure. It may be a Chilipeppr line number but that's close enough.
I just added a screenshot of the failure area of the code. I ran the file four times, twice in 440.18 and twice in 442.04 with the exact result. I have noticed in the past that if i change the dimensions of the file or change bit size it can alter or remove the outcome of errors. Ive cut full run test pieces with no issues, changed my settings to a smaller bit for accuracy and resulted in a runaway or a circle cut. Ive also added the full original code file as i was running on my machine. That one is WWlogogcode. Would I be any more stable with an arduino/grbl set up?
What happens to that line? Does it continue or return?
As for more stable with another system, I don't know. The problems seem to be localized to PartKam files, which generate some pretty crazy moves. Perhaps you might have better luck with the follow on - Makercam.
I use makercam for everything as theres not many options for mac users in the cam world. Im not sure ive had to force stop the machine as it runs until it hits the machines Y rails. All the runaway cuts ive had just keep going until it runs out of machine room so im assuming none of them return like the circles do.
Thanks for your help in locating the errant line. The fix is in the tinyg github and updater as master-candidate-440.19. Please let me know how this works for you. It passed all the tests for the files you gave me.