Marlin: is there a way to have an emergency stop button ?

[jfpion]

it could be useful when something goes wrong to have an emergency stop button which stop immediatly the moves and go up a few mm

could save some bed

if by the same occasion an resume button could be added to restart at the stop point it would be great

thank you

[henrikbrixandersen]

Emergency stop buttons should kill the mains power; they should not rely on software.

[jfpion]

there is 2 kind of emergency stop:
the software one who alow to resume after correcting a small problem (dirt, small broken part, blob, ......)
the abort everything one by killing the main power

the second is already done, the first I Imagine could work with an interrupt to stop the move at the end of the last movement and move up a few mm to clear the part with the memorisation of where the work stop to resume nicely

the pause button in pronterface do that but after the buffer is empty and some time it is too late

thank you

[smartroad]

To abort I have the RESET line pulled out onto the LCD panel. If the printer starts to go wrong I can press that and the machine stops dead. I don't like the idea of turning off the power as my hot end is activly cooled so stopping power would stop the fan causing the residual heat to go up the hot end and cause jams (already happened to me!!)

[emente]

I use a emergency button that cuts main power. I dont want to trust the integrity of my limbs to software or reset-lines, as i have very beefy steppers on my machine.

For all other purposes i use pronterface with a custom button that takes care of pause, position memorisation and safe hotend positioning. Has the small drawback that the printbuffer needs to run down first.

[jfpion]

Has the small drawback that the printbuffer needs to run down first.

yes that's the point, it couldn't be an "emergency stop" button with the buffer to empty first !

[dronus]

Maybe a simple pause / resume toggler on the printer itself would be cool. It can be used as emergency stop, and doesn't need to have the buffer latency.

[jfpion]

Le 14/08/2012 20:25, dronus a écrit :

Maybe a simple pause / resume toggler on the printer itself would be
cool. It can be used as emergency stop, and doesn't need to have the
buffer latency.

my thought too

[dronus]

Does such a button need to circumvent the usual internal communication? All UI operations seem to issue gcodes, so the a pause/resume button would suffer from the buffer as well if implemented like the other buttons I think. So it would need lower level methods.

[jfpion]

that's the pb and why this stop buttton must be in marlin. the usual pause order need to empty the buffer before to stop, this one will stop immediatly where it is, memorise the position and where it was going and up z 10 mm for exemple.

when hitting again the button (or switch it back) marlin will go down and resume from where it stopped

could be some pb with stopping in a bridge (bad idea) or accelération (but could finish the vector with a reduced speed to avoid to loose steps

[buddhafragt]

I solve this problem for me with the command: DISABLE_STEPPER_DRIVER_INTERRUPT();
The steppers stop immediately.

Then lift the Z axis with code like this:

WRITE(Z_DIR_PIN, LOW);
WRITE(Z_ENABLE_PIN, HIGH);
enable_z();
for (int i=0; i <= z_high; i++){ // z_high = how many steps to move....
SET_OUTPUT(Z_STEP_PIN);
WRITE(Z_STEP_PIN,INVERT_Z_STEP_PIN);
WRITE(Z_STEP_PIN,!INVERT_Z_STEP_PIN);
delay(1);

(Remove some dirt from the Tool......)
and backwards:

WRITE(Z_DIR_PIN,HIGH);
WRITE(Z_ENABLE_PIN,HIGH);
enable_z();
for (int i=0; i <= z_high; i++){
SET_OUTPUT(Z_STEP_PIN);
WRITE(Z_STEP_PIN,INVERT_Z_STEP_PIN);
WRITE(Z_STEP_PIN,!INVERT_Z_STEP_PIN);
delay(1);

now ENABLE_STEPPER_DRIVER_INTERRUPT(); again.........

works perfectly ;-)

[daid]

I agree with henrikbrixandersen here. Emergency stop buttons should be "kill all power". It's the only way to be sure.

But, FYI, I've been working hard on the LCD code, which I will be merging soon. And one of the things I've fixed is that if you press "stop" on the SD print, it stops. It doesn't wait to finished 16 moves, it stops, right there where you pressed stop.

[jfpion]

great !

and is there a possibility it work the same whis usb connected print task ?

thank you

[daid]

No. With USB you will have the 16 commands in the planner buffer. But also a few commands in the USB serial buffer. So an instant stop cannot be achieved there. There could be an M command added to stop as fast as possible, but it will never be instant.

[jjg]

Hey guys, not sure where this left off but I have an idea that would benefit from the ability to have a switch on a pin that would immediately stop the printer, but allow for resume at the exact same place it left off as @jfplon describes.

Since this thread is pretty old I wanted to check to see if anything like this been implemented in Marlin already?

[thecrazy]

You may want to check out Repetier Host, if you hit the pause button it
stops, then you can move the axis and when you resume it restarts exactly
at the right place. Awesome.

There is a delay though after pressing pause, probably the buffer emptying.
A firmware based solution could probably pause the printer instantaneously.

If this gets implemented please have a place in firmware were we can put
custom gcode of what to do once the print is paused. I find that if i dont
move the nozzle up from the print right after a pause it melts the print.

On Thu, Feb 7, 2013 at 12:38 PM, Jason Gullickson
[email protected]:

Hey guys, not sure where this left off but I have an idea that would
benefit from the ability to have a switch on a pin that would immediately
stop the printer, but allow for resume at the exact same place it left off
as @jfplon describes.

Since this thread is pretty old I wanted to check to see if anything like
this been implemented in Marlin already?

—
Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/190#issuecomment-13248945.

[jjg]

Thanks @thecrazy, yes I considered host-level solutions but that delay of emptying the buffer is a kind of a dealbreaker for me (unless it can be limited only to movements, not extrusion). Also I need to interface hardware to trigger the pause so going direct into the firmware is preferred.

[daid]

An "emergency" button should kill power as said already (big red kill switch). A pause button with resume is implemented, and Bernard worked out an better version which also parks the head.

Stopping the stepper/planning routine mid-track is a guarantee for problems, we do acceleration for a reason and pausing just somewhere random in between planned moves will cause problems with the acceleration planning.

[jjg]

Thanks @daid ; can you point me to where I can learn more about the pause button implementation? That might meet my needs but I need to know more about it :)

Thanks!

[thecrazy]

Thanks for mentioning this daid, ill have to pay more attention to what happens when pausing with repetier host, didn't seem to cause any issues in the prints but Ill keep an eye open.

[jjg]

Found it, looks like the pull request is still open yet tho - https://github.com/ErikZalm/Marlin/pull/378

[beebenutz]

If your firmware has Watchdog, you could wire a momentary switch in parallel with one of your thermistors. A press of this button would result in the thermistor being shorted, resulting in a halt of all functions and processes until manually reset. A resume wouldn't be possible with this method.

[thinkyhead]

@beebenutz — Did you sign up to Github today just to post on this 5-year-old issue? _Thanks!_

That is a very roundabout way to call kill(), when you could just wire a switch to an endstop plug and add code to call kill() directly in response to a press.

[beebenutz]

I did sign up to post on this 5 y.o. thread. I didn't think knowledge had an expiration date!

I wouldn't describe a direct method for completing a task as "very roundabout". The code for calling kill is already implemented within the thermistor watchdog which acts directly from a press.

[thinkyhead]

You'll have to forgive us. We have been experiencing a lot of troll activity, and we are thus highly suspicious of shiny new accounts doing unusual things.

Anyway, since we're here I'll elaborate on my opinion that this is "roundabout."

While certainly this method would work, it presupposes that:

• The firmware is not easily changed (it is).
• Wiring a switch in series with a thermistor is a good idea (it would be better not to).

The result of this modification would be:

• With recent Marlin the switch is ignored unless heating is started (maybe desirable).
• Resistance may be increased and noise introduced, altering the reported temperature.
• On press the machine would report MINTEMP ERR (hackish).

As a software person I tend to favor the software change that implements the desired feature formally, and in full. It would be my advice to anyone seeking to add such a switch –and who stumbles onto this page– to follow the methods outlined in more recent topics. Namely, connect a switch to an unused digital pin and add code to call kill(PSTR("USER HALT")) in response to the switch.

[beebenutz]

I forgive you. I am not a troll.

Upon reading your last response I feel as though the presupposes have been preassumed.

• I had not presupposed that the firmware was difficult to change. I supposed that the firmware already had code which would enable the task at hand, and it does.

• I had not presupposed that adding a switch in series would be a good idea, for it would have obvious potential to cause incorrect resistance which would certainly cause incorrect temperature readings. I, instead stated as well as provided an accurate hand drawn wiring diagram that the proposition was to wire a switch in parallel with the thermistor, which would cause no inaccuracies. I supposed the only part I presupposed was that a software person could interpret a wiring diagram.

• It is correct that Marlin monitors temperatures while heating functions are or have been activated within a set amount of time, however the recommended MINTEMP and MAXTEMP functions are constant. In the latest Marlin dummy thermistors have also been implemented to allow testing.

• On press the machine would report MAXTEMP triggered kill () called. The end game is a kill command being sent, which stops the machine as requested by the thread originator.

• I feel that instead of monitoring for trolls on this forum, you have seemingly become one yourself. I have not had someone try to discredit me so much without actually understanding the concept of what was being proposed. It is very unfortunate.

• If anyone stumbles across this thread, look out for trolls, and keep a big stick!