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

I'm replacing M5 with a user defined (Python) M-code, M55, which checks and sets a few parameters before shutting off the spindle. M55 is run the number of times it appears in the g-code before the line from which I fire 'Run from here' in Axis, which causes problems. Is that the trajectory planner parsing the file up to the 'Run from here' line? In Python, is there a way to discriminate a trajectory planner traversal of the code (or whatever it is) from actual running of the g-code so I can trap for it?

Thanks, andypugh.

Is there a compelling reason to do the remap in Python and not G-code?

I'm setting welding power state using M3/M5. Some welding modes require scratch starting, wherein machine motion and welding power are initiated simultaneously with the arc establishing somewhere along the the tool path rather than precisely at the point where M3 was executed. Many welds start and end at the same point, so the delayed arc initiation results in a gap in the weld. I solve this by capturing the location where the arc initiated and create a temporary g-code file containing relevant moves from the start/stop location to that point. M55 looks for that file, executes its lines before executing M5, then deletes the file. So when I 'Run from here' the very first M55 called by the interpreter deletes the file, which is a bummer.

I don't see how changing g-code could solve that problem...

I'm using a robotic welder that sets a pin high when the arc is established - that's not the problem. The problem is the interpreter running M55 at the wrong time. My logic assumes M55 only follows an M3 when halui.mode.is-auto is high. But 'Run from here' violates that logic.

Is there a compelling reason to do the remap in Python and not G-code?

I don't see how changing g-code could solve that problem...
 

I think andys question was referring to weather it may be possible to write the remap in GCode instead of python, not changing the program.

Apologies, I'm not being clear. I'll try again:

The problem is not starting, it's stopping. Assume the tool path is a closed square starting and ending at the same corner. Movement and welding power initiate simultaneously at that corner, but the arc initiates some distance along the move. (This must be done to scratch through a non-conducting coating.) To eliminate the gap that would otherwise exist between the starting corner and the point where the arc initiated, I capture the latter's position and write a temporary g-code file that M55 opens, executes, and deletes. If there's a problem, e.g. torch collision resulting in a e-stop, the subsequent 'Run from here' fires M55 multiple times, deleting the temporary g-code file, leaving the gap in the weld unfilled.