'Run from here' calls remapped M-code multiple times

My user name is hardly ironic; I apologize for being thick and I greatly appreciate your insight and help! The application at hand isn't conventional - rule breaking is kind of the point. Consider the coating a tenacious flux; it's not so much a hardware problem as a process reality.

And to complicate things more, the tool path is not simple. A change in direction is likely to occur before arc initiation, which I think means the intervening g-code must be repeated, but with a stable arc. As for tolerance, I would prefer if the path over-ran the arc initiation point.

Everything works to plan if the tool path runs to completion without upset. The problem occurs when recovering from upsets and invoking 'Run from here.'

Yep. It's counterproductive as it deletes the temporary g-code file same as what the interpreter does...

I've come up with a workaround, but it it seems kludgy: Rename the temporary g-code file if it exists at the time the arc extinguishes. At initiation of the arc, check if the renamed file exists and rename back to the original name.

I was hoping there existed a flag of some sort to indicate the g-code wasn't actually being executed, just parsed to reestablish state. It seems something like a halui.mode.parsing (or whatever would be the logical pin name) would be useful.

Thanks for the help!