'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?

I think this is an attempt by the interpreter to be in same state at that point as it would be as if it had got there by running up to that point.

It's one of the problems with "run from here" that it isn't clear what the best thing to do with "stateful" elements of the system. (like, should it turn the spindle on if the spindle would have been on at that point, and in what mode)
(The reason that it isn't clear what to do is that pehaps the operator stopped the code specifically because they wanted to alter the state)

G-code has the #<_task> parmeter
linuxcnc.org/docs/stable/html/gcode/over...ub:system-parameters

Which doesn't look like it maps exactly to either exec_state or task_state in the Python interface.
But I would start by looking at those to see if they do what you want,

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

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...

A simple reed switch will do for sensing the current when welding starts, wire it to an input and in hal wire it to motion.inhibit.
That will nit let the machine move till it gets that signal that the welder is actually welding.
We use that for plasma cutting.

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.

Maybe a failure in communication, but from what you explain at length, you do not need any remap, you only need the machine not to move till the arc is on.

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.

"Solving hardware issues in software never works"

chowderhead wrote:

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.)

That is a very big "no no" in welding. For a single part it might be ok, but serial production, never.
Parts must be clean before welding, and from anyone that i talked to regarding welding, that is not a subject open to discussion. I came to the same conclusion from several machines in serial production.

chowderhead wrote:

To eliminate the gap that would otherwise exist between the starting corner and the point where the arc initiated,

Still, you can just add an adjustable delay to switching off the welder.
What is the bearable tolerance? 1-2mm or more?