Remapping M1 to include movement

04 Jan 2023 02:17 - 04 Jan 2023 02:25 #260889 by DauntlessA
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:
REMAP= M1 modalgroup=1 ngc=m1remap
(This is the same as line 68 in

And I added a file called m1remap.ngc to my subroutines folder:
G53 Z0
G53 Y565



(The equivalent is

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

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

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.
Last edit: 04 Jan 2023 02:25 by DauntlessA. Reason: Attempt to fix formatting

Please Log in or Create an account to join the conversation.

04 Jan 2023 16:40 #260937 by andypugh
QTPyVCP is not an official part of LinuxCNC, you might get more help from that specific part of the puzzle by asking there.

But, there are a few "std" files that are part of LinuxCNC, but I don't see M1 mode being checked in any of them.

I think that you would either need to check the optional stop mode in your own Python prolog, or possibly directly in the G-code routine.
I am not clear what "program.optional-stop.toggle" is in your description above, but if it is a HAL pin it _might_ be possible to read it from G-code:

Please Log in or Create an account to join the conversation.

07 Jan 2023 17:12 #261182 by DauntlessA
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.

Please Log in or Create an account to join the conversation.

22 Jul 2023 15:28 #275997 by DauntlessA
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 ''. 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.

Please Log in or Create an account to join the conversation.

Time to create page: 0.126 seconds
Powered by Kunena Forum