MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.19k stars 19.22k forks source link

Change Kill Button Behavior? #3045

Closed sarf2k4 closed 8 years ago

sarf2k4 commented 8 years ago

Is it possible to change the kill button to just as "KILLED" in the lcd display into "kill then reset" or act as a reset switch like the ramps 1.4 reset switch?

Blue-Marlin commented 8 years ago

Changing the "KILLED. " message is as easy as changing the text in language.en

#ifndef MSG_KILLED
  #define MSG_KILLED                          "What ever you want"
#endif

If you are not using language en, do it in your languages file.

There is no 'perfect' software replacement for a hardware reset.(https://tomblanch.wordpress.com/2014/02/26/resetting-an-arduino-from-software/)

https://github.com/MarlinFirmware/Marlin/blob/RC/Marlin/Marlin_main.cpp#L6952 https://github.com/MarlinFirmware/Marlin/blob/RC/Marlin/Marlin_main.cpp#L7068

sarf2k4 commented 8 years ago

Sorry, I guess my question were confusing. What I meant was, instead of just killing the printer's operation suddenly then we can't do anything except "power cycle" the mainboard, is there any way to change the kill button into same way like "power cycle" method?

thinkyhead commented 8 years ago

Do you want to make the KILL button work precisely like the board's "reset" button? Or do you just want the firmware to "restart" (entirely in software, no hardware reset)?

jbrazio commented 8 years ago

As per the above link it should be possible to trigger a software uC reboot instead of a halt by using this right ?

#include <avr/wdt.h>
#define Reset_AVR() wdt_enable(WDTO_1S); while(1) {}
Blue-Marlin commented 8 years ago

No. That's not an option. If Marlins USE_WATCHDOG is active we are refreshing the watchdog timer.

Blue-Marlin commented 8 years ago

We also have our own watchdog ISR then - executing kill(). (watchdog.h)

jbrazio commented 8 years ago

Isn't the flag combination of USE_WATCHDOG && WATCHDOG_RESET_MANUAL both set to true doing exactly what the op wants ?

// Initialize watchdog with a 4 sec interrupt time
void watchdog_init() {
  #if ENABLED(WATCHDOG_RESET_MANUAL)
    // this case will halt the system at the ISR using a infinite loop
  #else
    wdt_enable(WDTO_4S);
    // We don't piggy bank on the ISR, so the AVR will just reboot if the watchdog timesout no ?
  #endif
}
sarf2k4 commented 8 years ago

I'm not sure the differences between board's reset and firmware restart feature, it is just if possible to reboot the whole firmware after the "kill button" pressed rather than we had to power cycle the board to restore the functionality again

It is assumed that the mainboard might be out of reach or enclosed for protection and to do emergency stop often a power cycle

Blue-Marlin commented 8 years ago

It has been said many times before, but i'll repeat it for you. Resetting the board in an emergency situation is not the best choice because: a) the board may immediately begin to execute a autostart file from SD. b) the host might not realize the board was reset and keep sending stuff.

The difference between hardware reset and software reboot is the initialisation. The hardware reset makes all pins inputs. The software reboot ought to reinitialise all relevant pins to a safe state, but no one can give a guarantee about that. All good boards are built that way, so they don't do anything harmful when the pins are inputs. That is the main reason why, for example, RAMPS-FD v1.0 is not a good board.

jbrazio commented 8 years ago

I by no means was thinking of an automatic reboot. I do understand your standpoint and I do back up the security reasons behind it but I still believe we can have some of both worlds. Some, if not all of your points can be tackled.

the board may immediately begin to execute a autostart file from SD.

  1. The AUTOSTART flag and the REBOOT_INSTEAD_OF_HALT pseudo flag can be made mutually exclusive.
  2. -or- When emergency stop is triggered an EEPROM bit could be set, when the bit is set and then Marlin would start into a stopped state ignoring AUTOSTART stuff.

the host might not have realized the reset and keeps sending stuff.

I could imagine a emergency stop screen like we have now, with a mandatory timeout of 30s and only after the timeout iit would allow the user to reset the board by either pressing a button or by releasing the emergency stop switch from its "emergency position" (like this were you have to rotate it).

The big question is if all ports are reset to a known state after the firmware restarts.. Well isn't Marlin init() code setting the IO ports to a known state ?

jbrazio commented 8 years ago

@thinkyhead Due the discussion on this thread and the related ones at #3077 I suggest to mark this issue as #closed #wontfix.

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.