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
[Request] Octopi: Warning text on shutdown confirmation dialogue #2131
Comments
Do you mean it didn't ask you at all if you wanted to shut down? Or it asked you if you wanted to shut down, but just didn't mention interrupting a print?
Not 100% sure but I'm pretty sure it doesn't. Some printer mainboards just like to reset themselves when they see certain types of serial traffic. The board probably just thought "hey, serial connection, reset time!". It's how arduino / some atmega based boards are so easily able to be flashed without requiring external programmers. Any serial connection will reset the board, putting it into a sort of "gimme the firmware" mode for a short while. edit: How's this grab you? |
So to answer the first question, no warning it would interrupt prints. And for the second question, you're right it could have been the printers controller stopping because of the traffic it received. |
The process of reconnecting to the serial bus of the controller resets the controller. This isn't something done by Octoprint, but the Arduino, as it takes every connection as a possible programming connection, and restarts the bootloader. You will notice that if you disconnect from the printer after setting a temperature and then reconnect, the printer will reset and start cooling down. |
In this case OP was shutting down so I wouldn't expect anything would reconnect to the board, disconnect, sure but reconnecting? I totally agree it's something hinkey with the serial reset Arduino's do but I don't think I've ever had mine do it on shutdown. |
It does it on reboot when the USB bus is started up. Applying power to the
USB port causes the arduino to reset. Disconnecting the USB bus may cause a
reset as well, but I don't think so.
…On Oct 4, 2017 9:33 PM, "ntoff" ***@***.***> wrote:
The process of reconnecting to the serial bus of the controller resets the
controller.
In this case OP was shutting down so I wouldn't expect anything would *re*connect
to the board, *dis*connect, sure but reconnecting? I totally agree it's
something hinkey with the serial reset Arduino's do but I don't think I've
ever had mine do it on shutdown.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2131 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACDmtW9CHdgF4LDblVkGXWUIzqsYBW-Aks5spDHTgaJpZM4Po3fI>
.
|
A warning message has been implemented by the just merged #2146. Available on |
I just thought of something, the auto updater will just automatically restart OctoPrint when it's done, won't that (be even more likely to) also trigger a reconnect? Maybe the auto updater should also have the warning applied to its dialog too? And a warning that it's going to auto restart OctoPrint once the update is done. edit: cleaned my glasses, it does tell you that it's going to auto restart :p oops I still stand by the other bit though, that the auto updater prompt should warn about possible SD interruptions too. |
That's a good point. Something warning the user that they should not perform an update/restart when the printer is actively printing is probably a good idea as well. |
I mean, for the record, I'm pretty sure OctoPrint won't even let you update if OctoPrint is what started the print, but in this case we're talking about people who start a print via the LCD panel on the printer, so as far as OctoPrint knows, the printer is idle. Maybe a future feature request? A way of detecting if the printer is idle? I know not all firmware issues the "wait" or "busy" thing but I guess at least that's a place to start. |
Even something as simple as a button in Octoprint that, when toggled on, tells the system "hey, I've started printing from the printer, please stay on to record/monitor settings/etc. and DON'T try to send any data or reset. And if I tell you to reset, please yell at me in the form of dialogue boxes." |
Too unreliable, people will still post issues like "I forgot to tick the box and octoprint restarted, why can't it be automatic?", people are actually doing that now with the timelapse functionality because they forget to enable it pre-print. Either way: https://github.com/ntoff/OctoPrint/tree/improve/auto-update-warn-sd-interupt How's this? |
Haha yes, I assumed as much. I knew it wasn't a very good implementation of that idea. It's rather unfortunate that the hardware we're dealing with causes us to create all of these workarounds. Then again, Octoprint is much better than any built-in interface on all of the machines I've seen so far. |
I also like that all of the proceed buttons in the screenshots are red. Training the user to interpret a red button as something that will interrupt the software and whatever actions it / they are performing. |
@ntoff send a PR :) Happy to also include this, definitely makes sense! |
@scottpost4 I'm pretty sure the buttons are red by default, that's not something I've changed. Are your confirmation buttons not red? |
@ntoff apparently my glasses needed cleaning as well. Yes they are haha |
Closing because 1.3.6 was just released. |
Simple request for the addition of warning text on the shutdown confirmation dialogue box.
"Shutting down the system will stop/cancel any printing currently underway."
I was using Octopi the other day simply to MONITOR my printer. The print was started from the printer, and was on an sd card mounted in the printer. When the print was almost complete I shut down the raspberry pi using the shutdown system command in the web interface. I received no warning (as I usually would with most other tasks that would interrupt prints). I assume Octopi, when shutdown, sends a disable steppers or stop command to the printer. This stopped my nearly done 6 hour print. This text would have given me pause, and I would have left the system running until the print was complete.
The text was updated successfully, but these errors were encountered: