Valid 'task_mode' state transitions?
26 May 2017 17:24 #93678
by hwylie
Valid 'task_mode' state transitions? was created by hwylie
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.
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.
Please Log in or Create an account to join the conversation.
29 May 2017 18:19 #93804
by andypugh
Replied by andypugh on topic Valid 'task_mode' state transitions?
I just tried it by opening LinuxCNC and running the splash G-code then opening python
python
import linuxcnc
c = linuxcnc.command()
c.mode(linuxcnc.AUTO_PAUSE)
And I got the error message:
"Can't switch mode while mode is AUTO and interpreter is not IDLE"
There are things about how LinuxCNC works that make this harder than it might seem, not least of which is that typically the entire program is already queued up in the motion planner.
python
import linuxcnc
c = linuxcnc.command()
c.mode(linuxcnc.AUTO_PAUSE)
And I got the error message:
"Can't switch mode while mode is AUTO and interpreter is not IDLE"
There are things about how LinuxCNC works that make this harder than it might seem, not least of which is that typically the entire program is already queued up in the motion planner.
Please Log in or Create an account to join the conversation.
29 May 2017 20:08 #93818
by hwylie
Replied by hwylie on topic Valid 'task_mode' state transitions?
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.
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.
Please Log in or Create an account to join the conversation.
30 May 2017 15:41 #93845
by andypugh
Replied by andypugh on topic Valid 'task_mode' state transitions?
There has been much discussion of this in the past, and I have a feeling that there might be a solution in machinekit.
sourceforge.net/p/emc/mailman/search/?q=..._list=emc-developers
Look particularly for emails from Michael Haberler.
sourceforge.net/p/emc/mailman/search/?q=..._list=emc-developers
Look particularly for emails from Michael Haberler.
Please Log in or Create an account to join the conversation.
01 Jun 2017 09:56 #93919
by hwylie
Replied by hwylie on topic Valid 'task_mode' state transitions?
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?
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?
Please Log in or Create an account to join the conversation.
01 Jun 2017 17:26 #93969
by andypugh
Replied by andypugh on topic Valid 'task_mode' state transitions?
I am fairly sure that jog-while-paused is already part of Machinekit. You _could_ try using that instead.
The downside of that is that they haven't made the joints-axes switch.
The downside of that is that they haven't made the joints-axes switch.
Please Log in or Create an account to join the conversation.
02 Jun 2017 04:34 #93991
by hwylie
Replied by hwylie on topic Valid 'task_mode' state transitions?
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.
Keeping the topic for further investigation, while the gantry operates very well with Master joint-axes implementation.
Please Log in or Create an account to join the conversation.
02 Jun 2017 09:45 #93993
by andypugh
No, I have definitely used (a few years ago) experimental jog-while-paused branches.
Here is more evidence:
github.com/machinekit/machinekit/pull/109
Replied by andypugh on topic Valid 'task_mode' state transitions?
Thanks - I suspect Machinekit uses legacy 'abort & restart' hal_manualtoolchange..
No, I have definitely used (a few years ago) experimental jog-while-paused branches.
Here is more evidence:
github.com/machinekit/machinekit/pull/109
The following user(s) said Thank You: hwylie
Please Log in or Create an account to join the conversation.
Time to create page: 0.231 seconds