-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR] Softer, disconnect-less HALT option. #20365
Comments
You should track down why your printer is halting. It’s a safety feature since Marin controls things like heaters. The point of halting is to shut down everything and alert you that your printer did something unsafe and needs attention. |
Absolutely, It also happens on probing error (not so dangerous) But I disabled OctoPrint from disconnecting on !!/Error now. |
There’s good reason to watch for slow heat ups and those settings are configurable: Marlin/Marlin/Configuration_adv.h Lines 213 to 225 in 3eddbc7
|
@thisiskeithb Now let's rather discuss the issue: So- with no adverse effects, this would save a lot of frustration for lots of users of the newer controllers. |
Halting your printer is about safety. It's why the feature exists. |
Yes, I am not saying anything against halting - but it can be done in a more convenient, equally safe way. You could also have a relay to make sure it halted by shorting the mains supply, but one usually takes the more sane/convenient solution to a problem. |
This is a safety feature. |
My suggestion increases safety in cold environment (not causing too liberal runaway settings) This applies especially to users who use big print beds, and toggle between thin powder-covered steel sheet, and heavy glass plate with PEI. You are telling me that in order to punish the user as hard as possible for false positive on the thermal runaway (or probing error), you prefer that a user configures a 2°C / 500sec threshold for frozen glass bed, rather than a safe 2°C/60s that is sufficient with thin steel during most of the year. (then reset remotely the few times it may be needed) Opposing this suggestion gives users incentive to have too sloppy thermal runaway settings (because the penalty is too inconvenient). I won't' nag and discuss this anymore, if you oppose improvements and convenient safety features by principle and prefer to annoy users to configure them too liberally comment out THERMAL_PROTECTION_* - then that is an active choice to decrease safety. |
Fundamentally, I think halting everything on errors can cause more safety issues than they solve, compared to killing everything and just keeping the serial processing open so Marlin can respond with the error on any command until actually reset. For example, any situation where the device connected to the serial port loses state, you lose the actual error message - on boards which reset on DTR, you just end up without the ability to see the issue, and on boards which don't, you just get a dead connection. |
Preventing a possible fire is more important than keeping an error message on the screen/over serial which is why Marlin completely halts. |
My hotend melted and I got a circuit break (because the isolation of the wires melted too), when I ignored THERMAL_PROTECTION.... It was a problem in my temp sensor (loose), but I was trying to force Marlin to work. So, I learned that safety features should not be ignored. |
Switching off heaters may prevent fire. IF we were actually interested in safety: |
The point is: every time marlin has halted for me, I needed do something manually on the machine. At least for me.
Sarcasm?! Really?? |
Halting doesn't just shut down communications. It kills everything and that's why it requires user intervention. Your machine did something outside the norm and needs you to investigate. I don't see how it would ever be more safe to let a printer continue to run for the sake of a user message instead of completely shutting down everything would make sense. |
Now explain how it would be less safe to switch off steppers, heaters, keep communication ,reporting temperatures, and only accept M999 |
Simple: M999 will allow you reset the printer and keep trying to print, over and over, instead of go to investigate what is causing the halt. |
So... it would M999, restart, set temperatures (which do not enable heaters if already too high..) Allowing M999 also "allows" user to lit a fire manually. - disconnecting communications does nothing good. - certainly does not allow a secondary system to save the day. |
Lets compare the views, I think it should explain why isn't safer to let user restart the printer remotely when it halted. Marlin now:
What you are suggesting:
Do you got it now? We can't create something that incentives users to just ignore thermal runaway (or any other halts). That is the point. |
@rhapsodyv So YES, any should be able to regain control, just like reconnect allows it for most users anyway. And for the final time: The printer is in an equally safe state by just switching off steppers/heaters and accepting only M999 |
If we could find some guaranteed way to reboot, that would be something to try. But, the locking up of the board to force physical interaction with the machine is for now a very intentional part of KILL. |
#21652 adds “soft reset” abilities. Closing. |
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. |
Description
SKR , and many other newer boards do not reset on serial port opening, DTR, like older Arduino/Atmega based boards do.
Any HALT, even for non-dangerous situations like failed probing/levelling, makes the printer go into a brick mode, until power-cycled.
This is extremely inconvenient when printing remotely.
Feature Workflow
Add option to "Soft HALT/KILL"
When "soft halted", respond to commands with "!!" "error:" or "fatal:" as usual
This will stop any decent software, like OctoPrint
Then, accept only M999 command (restart)
This would provide a safe way of stopping a print, without disconnecting from the host.
Additional Information
This is related to:
#14300
The text was updated successfully, but these errors were encountered: