On 17 May 2010 09:12, Ian W. Wright <watchma...@talktalk.net> wrote: > As my initial suggestions - I can't see why the program would have to > return to exactly the same place in the script as it was when it was > paused before the jog.... surely it could return to the start of the > 'block' or line it was cutting at the pause..
This would be simpler (I think). You basically throw away the queue when pause is pressed and "run from line" but if you imagine needing to unclog a cutter near the end of a very long slot, you could have been in that same G-code line for 20 minutes. Assuming that the trajectory planner works in machine coordinates; my initial idea of "dry running" through the code until you reach the coordinates where pause was pressed then going "live" is a non-starter as a change in work or tool offsets means that you won't reach the same machine coordinates. it seems that the reason that jog-on-tool-change is possible is that the motion controller stops there anyway (and expects to stop there). I guess this means that jog-on-tool-change is relatively easy, though perhaps it needs to refuse to restart unless it is at it's "safe retract" position to save the risk of wiping out clamps and work on the way back from the touch-off fixture. How does the Axis Preview work? Does that use the same command interpreter or a cut-down version? I can't seem to get away from needing to do a "dry run" of the G-code up to the point where the relative coordinates and G-code program line match and then start loading the motion queue. -- atp ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
