We now have a restart function that works in case of a disconnect or failure. That’s wonderful. I’d like to take it to the next level and allow that same type of restart functionality in the event of a deliberate interruption (one that I cause).
There are times when I’m running a job - perhaps a long running job, and I see something I’d like to change. Maybe I’d like to lower my “Z” (or raise it), maybe I’ve tiled and I can see that I’m slightly off and would like to adjust my zero. Or, maybe a clamp has come loose but the clamp screw is under the gantry and it’s difficult to get to - and I’d like to move the gantry temporarily out of the way.
In today’s CM (correct me, if I’m wrong), I can PAUSE the job - but I can’t move my gantry or change any settings. If I need to either of those, my only recourse is to stop the job, make my change, and then restart the job - perhaps modified to bypass stuff that’s already been executed.
What I’d like is to be able to effectively SUSPEND the job - but have the ability to move the gantry…and PERHAPS, if I want to, modify my zero - then press a button that will restart the machine by automatically moving back to the point of the suspension (absolute coordinates) and then restart at the step of the pause.
This would require the SUSPEND mechanism to remember the absolute coordinates of the suspension point and then move back to it on RESUME.
To avoid confusion (and help desk calls), SUSPEND could be a different function than the current PAUSE function. (I’m not sure which would be attached to the hardwired interrupt button - but I would prefer more function; hence SUSPEND, if possible).
Do you agree this would be a usable feature? Is it a doable feature?
The problem may be in how it works. The current Pause issues a Feed-Hold signal to the controller, which essentially halts the machine where it is. Since there are blocks in the buffer, it doesn’t allow doing anything else. Jogging would send a block, but it would be at the end of the buffer so it would continue cutting it’s current path until that part of the buffer runs out.
If a Suspend command stopped sending to the buffer, it would still need to continue movement until the buffer is empty. (I think around 15 blocks??).
Previous versions of GRBL for Shapeoko did support a pause function that stopped, raised & stopped the spindle. Recent versions now support independent Y axes, so the pause functionality went away.
So, it’s not just a change in CM that would be necessary, you would also have to reconfigure & recompile & reinstall GRBL.
“Of course, that’s just my opinion. I could be wrong!”
There’d be no way to “remember” the buffer, clear it, and then reinstate it?
[EDIT] Sorry for the edit, but we have a restart function that starts from any line number…so wouldn’t this just be remembering the line number at the time of Suspend, and then clearing the buffer let me do my thing and “restarting” at that line number?
Getting out of my wheelhouse now. Maybe Rob will chime in.
Sounds like using the Stop and Restart functions we have now, just in a more automated fashion.
If it knows the point you stopped, and the buffer size, it would probably have to back up at least that far, so you may cut ~15 blocks over again, which is usually going to be pretty small, unless it’s on a simple facing cut that would be 8 passes & 7 stepovers.
I don’t think CM can get the contents of the buffer. It can predict what’s in it, which would likely be ‘good enough’.
