Been having a lot of fun with my Lowrider but I keep running into the problem of how to properly stop a job that isn’t going well.
I’d like to implement a physical button connected to the controller or even a menu item to “stop print job” that:
Immediately stops executing the current program (and clears the command buffer)
Lifts Z back up to 0 (so router doesn’t keep spinning inside the workpiece)
Keeps power to stepper motors on
Remembers the currently set 0,0,0 coordinates so I can easily restart the program without rehoming.
I already have a true Estop wired to the mains power going to the controller and router for safety, but this causes the router to immediately plunge down to the workpiece (Z steppers can’t stay up without power) and for all coordinates to be lost.
Pressing Stop Print on the LCD controller is even worst because Marlin will happily keep executing commands (I think it’s running out some sort of command buffer).
If anyone can point me in the right direction on how to accomplish this that would be awesome. Thanks in advance.
There are commands in your gcode in the buffer. Those are gonna be lost.
I am not sure this exists exactly. There is an “emergency parser” you can enable in the firmware. I think that might enable some gcode to stop immediately.
Jamie wrote a branch of code to hold a button that would immediately stop the motion. But it stops without any acceleration and it leaves everything in the planner. You also can’t jog while in this mode, IIRC.
I’m not sure how to do this, actually. But I would love to have it, especially if I didn’t actually lose any of the command buffer, and I could resume later. My toaster does this. It has a “lift and look” button. It doesn’t run Marlin
Either the functionally you outline or the functionality that Jeff outlines would be great to have. From poking around in Marlin, I don’t see a way to make it happen without modifying Marlin. Breaking things up, you might get part of the way there. As Jeff mentions, there is an emergency parser that will handle a few of the g-codes. It is disabled by default in the versions of the firmware that Jeff/V1 maintains. This is the section in Configuration_Adv.h related to the emergency parser:
/**
* Emergency Command Parser
*
* Add a low-level parser to intercept certain commands as they
* enter the serial receive buffer, so they cannot be blocked.
* Currently handles M108, M112, M410, M876
* NOTE: Not yet implemented for all platforms.
*/
//#define EMERGENCY_PARSER
I’m not sure what state you will be in after executing an M112 or an M410. I run headless and have a pendant. When I send an M108 from the pendant, I must cycle the power to continue from the stopped state.
So the other half of your problem is returning to the original (0,0,0). If an M112 and/or an M410 leaves you in a state where you can issue new commands, that is easy. But I suspect that will not be the case. So as an alternate, some method of saving a position across a power cycle would be helpful. Looking through the g-code reference I see workspaces as one possibility (I’ve not tried it). According to the reference, “All workspaces default to 0,0,0 at start, or with EEPROM support they may be restored from a previous session.”
This is sort of a tangent, but the way I keep my coordinates is by always starting at the hard stops (you could use endstops) and then jog to the 0,0,0, and write down what coordinates it reports before sending G92. If I need to power off and walk away, I can just jog to the position I recorded.
I used to out the origin off of the workpiece and make a small dimple with the bit before starting. Then I could at least get a reliable XY from starting at the dimple. That worked ok too.
It is my understanding that the initial Marlin developers used grbl as a starting point. I don’t know whether Marlin carried it over when it borrowed initial functionality from grbl, but grbl supports a “pause” button which can be programmed to behave as you describe. Firmware allows it to be a momentary push button or connected to enclosure doors so if the doors are opened during a job the machine pauses and moves to a set location. I have no way of knowing how deep in Marlin such capability might be buried, if it didn’t get stripped out completely.
The short answer is that with Marlin this isn’t possible.
Marlin does not natively support pausing; so while you can certainly pause in OctoPrint or however you are feeding data to the board, it will still run all commands that have made their way to the buffer. That could take one or two seconds if you’re lucky (like if it is plotting an arc and you don’t have arcs enabled so there are lots of tiny line segments) to minutes (if you have send several long line segments). I have seen gcode post-processors that effectively break every line into hundreds of tiny segments specifically to make it easier to pause almost instantaneously.
All of the EMERGENCY_PARSER related stuff in Marlin have the effect of resetting the board, so the steppers lose power.
There are ways to emergency stop without driving your endmill into your workpiece, but I’m not aware of any that make it easy to continue.
Thanks for the input everyone. @jeffeb3 writing down the coordinates is brilliant (duh!). I’ll make sure to do that from now on. Of course that doesn’t really fix the whole problem because you now have to rehome the machine and move back to those coordinates and zero them, so still a lot of setup, but much better than losing the piece entirely.
Regarding the comments on whether pause/stop is possible or not without resetting the machine, I can’t speak for stock Marlin but my Prusa MK3 certainly seems capable of both pausing a print and stopping immediately without rebooting itself. So there’s hope!
Has anyone figured out how to do this yet? I am used to the FABMO controller in my Handibot: if you hit the “emergency stop” button, it cuts power to the router and lifts it up a few cm. Steppers and everything remain powered up (except the router motor). Hitting resume in Fabmo resumes any job exactly where it left off. I have used it many times for a variety of reasons, usually having to do with improper workholding. It seems like our desired behavior is similar to a “filament out” error that requires a hotend to be parked and some waste extruded for a filament change, then resume print in the place it left off. I don’t know if the Handibot’s Fabmo implementation is smart enough to decelerate and accelerate so steps are not missed at the stopping and starting moments, but that would certainly be desirable if not crucial.
If you know about such things, please update us on how to implement it for the MPCNC. Thanks!
