There have been a couple questions lately that have made me curious about an instant pause.
One common approach to pausing is via the controller, which unfortunately can have a long lag since it requires the movement queue to be depleted. Depending on the job, there can be a very long delay.
The other approach is not really a pause but a stop function, which can be achieved with an E-stop button or the kill button or M112 which can jump the queue if EMERGENCY_PARSER is enabled. These are difficult to resume.
I looked into seeing if there was a low-level ISR mechanism that I could hijack to “freeze time” within the step generation, and I found something that appears to work. This is only a few lines of code so it is pretty clean, although it does bend the rules and might not be completely safe. I’ll post the code a bit later.
Also instead of implementing my own button interface, I’ve repurposed the kill button so it does pause instead of kill.
It does not respect acceleration, it freezes step generation instantly. So there is some risk that if a high-speed movement is frozen it could skip steps from the sudden stop. When resuming it also does not accelerate, so there is a chance of missed steps on the resume too. Either would create problems for the job.
In my (limited) experience I usually find myself wanting the instant-stop because of something I forgot to do – I dunno, let’s just say, perhaps, maybe I’ve forgot to turn on the spindle (not that I’ve ever done that ). Actually, now that I think about it, it’s more often that I’ve left the Z-block in place (which I use to keep the spindle from falling too far down when power is off). In both these instances I usually notice it just after I’ve kicked off the job. Having an ability to just pause everything right where it is, do whatever I forgot, then resume (assume what I forgot wasn’t already detrimental to the job) - would be awesome!
I’m thinking that if this were tied into the e-stop button on the display so that:
initial push puts you into the pause mode
display a prompt on the display to either continue or abort
select which via the rotary encoder
press encoder button button to action (either resume or continue as if e-stop was pressed)
Do you think the implementation would be something the Marlin guys would ever go for? I think either way I’d accept the risk of Accel/decel. issues to have this as an option.
I was thinking about faking a filament runout sensor. You can run an arbitrary list of gcodes or even let a host take control when a filament runout is triggered. Marlin is smart enough to continue where it left off afterwards. What I don’t know is how quickly Marlin reacts to a runout event (ie. will it finish one or more moves in the queue or not).
One possible scenario is if you had an emergency stop function where you wanted to immediately freeze the motion and cut power to the spindle, but if the Z axis were to fall then you would plunge into your workpiece before the spindle fully stops, so you don’t want to cut power to the motors or do a hard reset of the Rambo.
Another possibility is if you wanted an “oops” button where you can fix something like removing a clamp that is in the way, without having to race as fast as possible with your fingers in the path of the tool.
I think the only real use is for unplanned pauses because anything intentional like a tool change should be accomplished with M00 or something similar.
). Actually, now that I think about it, it’s more often that I’ve left the Z-block in place (which I use to keep the spindle from falling too far down when power is off). In both these instances I usually notice it just after I’ve kicked off the job. Having an ability to just pause everything right where it is, do whatever I forgot, then resume (assume what I forgot wasn’t already detrimental to the job) - would be awesome!