Remapping M1 to include movement

I've modified my post-processor to lift Z and move back in Y before M1, so that if I do use the optional stop, it doesn't stop over the part (so I can inspect it, etc).
The issue is that since the machine then comes forward for the semi-automatic toolchange, it's wasting time moving to the back and then moving straight to the front if I don't want the optional stop. If M1 was remapped to only make the move to the back if the optional stop was on, that would prevent this.

To remap M1, I added this to the ini in the [RS274NGC] section:(This is the same as line 68 in github.com/LinuxCNC/linuxcnc/blob/611ee3.../extend-builtins.ini)

And I added a file called m1remap.ngc to my subroutines folder:
o<m1remap>sub
G53 Z0
G53 Y565
M1

o<m1remap>endsub

M2

(The equivalent is github.com/LinuxCNC/linuxcnc/blob/2e75b0...utines/extend_m1.ngc)

The issue I'm having is that when M1 is encountered in the main part program, it will always execute m1remap.ngc.

Within that, in the m1remap subroutine, the M1 called is the original implementation of the M code. (This behaviour is expected, see linuxcnc.org/docs/html/remap/remap.html#...cluding_code_m6_code)

The issue is that the remapped M1 in the main part program is no longer optional (which defeats the point).I need to redefine the original behaviour, but it's not very clear how that is done in the implementation above. In the example, the only line is REMAP= M1 modalgroup=4 ngc=extend_m1, so no python code or argspec (I’m passing no arguments) is called , only an ngc file.

linuxcnc.org/docs/html/remap/remap.html#...nfigs/sim/axis/remap states that there should be a folder called ‘python-stdglue’(one of the links is also dead).

I believe this stdglue has been moved to github.com/LinuxCNC/linuxcnc/blob/master...n-stdglue/stdglue.py

So, in theory I just need to figure out how to call this file, and it will work. However, it doesn’t seem to contain any code for remapping M1 (but I may be wrong).At this point I’m stuck. In Probe Basic/QtPyVCP, pressing the ‘M01 Break’ action button sends the action ‘program.optional-stop.toggle’. It may be possible to redefine the implementation of M1 by monitoring where the state of class qtpyvcp.actions.program_actions.optional_stop is either on or off, and behave accordingly. Ultimately if there is no python implementation of M1, I’ll need to create it, but the documentation suggest that there is. I’m just not sure exactly where it is, or how to reference it.

Hi Andy,

Thanks so much, I'll have a look into the HAL pins from G-Code! I can think of a few other things that might also be useful for.

I had another look at this and found a solution. I remapped M1 to a subroutine that uses M66 to set the value of #5399 from the Halui pin 'halui.program.optional-stop.is-on'. The subroutine uses the value of #5399 with an if conditional to decide whether to execute arbitrary G-Code (to lift the spindle and move the gantry to the back) and then M1, or to do nothing.