Valid 'task_mode' state transitions?

With reference to linuxcnc Python API, does the following command call sequence represent valid task state transitions during Gcode execution?

1. linuxcnc.AUTO_PAUSE
2. linuxcnc.MODE_MANUAL
3. linuxcnc.MODE_AUTO
4. linuxcnc.AUTO_RESUME

Does AUTO_PAUSE lock the Gcode file in use through the above state transitions, avoiding the user loading different Gcode while in MODE_MANUAL?

If both the above are true, are there other risks inherent in script which might achieve these transitions?

This enquiry aims at robust manual tool change, with the objective to avoid use of 'abort', but allow jogging and touch-off.

Thank you for performing the exercise to confirm the anticipated LCNC response; my post was to stimulate thinking about the possibility of such feature.

Accepted it's a very sophisticated software system, but manual jogging and touch-off using the legacy 'hal_manualtoolchange' (inelegant as it may be aborting and then restarting, at next line of Gcode) may be in wide use, despite motion planner queuing and regardless of where the user chooses to effect tool change and touch-off.

The motion planning queue itself may stall (in event of buffer full, or other cause) while Gcode execution is stalled. But by good LCNC design, regardless of tool change delay, Gcode execution continues as expected, whatever move may be required to reach the point of next activity - assuming the user does not foolishly perform tool change in such a position that LCNC will destroy it, or the work in process (or spindle bearings) to get there!

That assumption supports the motivation for the current 'hal_manualtoolchange' preventing manual head movement relative to workpiece during tool change - but with trajectory control made possible by 'moveoff', further study and experimentation may follow.

Much appreciated, these pointers are informative.

Let me be clear that I have not proposed manual intervention to pause Gcode while in execution - I need no convincing that is a beast, and (with ample real-time systems experience) superficial examination of the challenges presented immediately rule out any such consideration.

Reflecting on John Kasunich's explanation, it is clear that the real-time software design of LCNC addresses very well the optimisation of machine control in the context of automated tool change. Accepting that any manual tool change machine does not fully exploit the power of LCNC, the sophistication of the software nevertheless allows for high-quality, robust manual tool change machines also.

John's good explanations are understood, but it is expected the interpreter is not able to perform meaningful look-ahead beyond Gcode instruction to change tool, in the case of a tool table without offset parameters - this being consistent with manual tool change. It is apparent that blending is not a factor during the execution immediately preceding ('exit' Gcode sequence), and immediately after ('entry' Gcode sequence) tool change, since it has no meaning at that time. Similarly, motion blending is meaningless until touch-off is performed, whether manual or probe-automated.

Expecting interpreter and motion control look-ahead to be stalled (or of no value, and accordingly flushed) beyond Gcode manual tool change (for probe touch-off with table offsets, or manual touch-off) this is insignificant vs. manual tool change delay - and LCNC proceeds to rebuild the queues, blending motion to optimise activity until the next tool change.

The proposition to enhance the 'task_mode' state machine design to enable robust jogging and touch-off while 'paused' (by appropriate new state definition, inhibiting MDI commands) may - with application of 'moveoff' - hold merit for solution robustness and versatility, without compromising the broader design of LCNC.

It is accepted that your recommendation for probe automation of touch-off after manual tool change represents an easily achievable, robust solution, and that this exercise may not warrant further investigation.

Nevertheless, I regret not being in the earlier loop (below), and would value the perspective of the LCNC design team / core software developers. Being on the users' (but not developers') mailing list, how is it best brought to their consideration, not necessarily for short-term candidate features?

Thanks - I suspect Machinekit uses legacy 'abort & restart' hal_manualtoolchange.

Keeping the topic for further investigation, while the gantry operates very well with Master joint-axes implementation.