What is the problem?
While printing the Raaspberry octoserver crashed
What did you already try to solve it?
Logged into the server with SSH and restarted it
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
Raspberry Pi 3 B+ running 2018-04-07_2018-03-13-octopi-stretch-lite-0.15.0 OctiPi The Raspberry OS was still running, only the Octoserver stopped. Octoprint was the only thing running on the Raspberry. I had installed some plugins, cost estimator, filament management, & print history.
Definitely look in the logs, share them if you don't see a problem.
I had printed with Octoprint and it was fine. I installed some plugins and then had the Octoserver crashes mentioned above. Disabled all 3 of the plugins that I had installed. Just finished a 5 hr print without any issues. Now to figure out which one was causing the problem. I will start added them back one by one to see what happens.
Enabled the print history plugin and so far so good no more crashes.
I recently had my first crash. I've put a lot of prints through Octoprint so I'm going to chock this up to a blip but I do have one serious concern.
When Octoprint crashed it did not fail safe. In other words the printer stopped moving but did not turn off the bed or hot end. I caught this one and rebooted the pi after only a few minutes, but prior to this print I had a print running overnight and the thought of the printer sitting there with a hot end at 245c in one location for hours scares me a bit.
Not sure if anything can be done on this regard but felt I should post just in case.
I'm not sure if it will help in this case but I use https://github.com/google/OctoPrint-HeaterTimeout
1 Like
Not really much you can do if octoprint (or any host sofware) crashes and stops sending code mid print. The only way to combat that would for the printer's firmware to go "ok, I haven't been given any commands in the last x minutes, the hot end is hot, something's gone wrong, I'm turning myself off".
One saving grace is that some / most printer control boards will reset themselves on serial connections so if the host were to automatically reboot and reconnect, the printer would probably reset (control board dependent).
1 Like
If your firmware supports M85, use that to set a long-ish timeout after which the firmware will take care of handling things (which is actually the party that should take care of things here considering that if the host crashes or loses connection, it can't really talk to the printer anymore).
(Thanks to @gege2b for mentioning that in a recent ticket)
1 Like
Out of curiousity - was one of the other two plugins "OctoPrint Anywhere" or "Octolapse"?
@ibgeek also, which third party plugins do you have installed?
They are both installed but I currently have Octolapse disabled.
Thanks for the info, I'll see if that will work for me. 
If the host vanish and just stops sending stuff on the serial connection, unfortunatly, no plugin would be helpful
the only way I know to avoid leaving the printer with heaters on in this case, is to use the M85 GCode (at least onfirmware supporting it)
I've personnally added M85 S120 on the Start GCode of my slic3r (and M85 S0 at the stop gcode, too)
As @foosel said, shutdown if idle w/ heaters on should be done by the firmware because it's closer to the hardware than the host
1 Like
For clarification, does the M85 timer just start running and turn off when it runs out or does it not start running until there is a loss of comms? I'm assuming S120 = 120 min. So if if your print runs over 2 hours will it fail? Would I need to adjust that to be greater than the time needed to print the part?
Thank you, just want to make sure I fully understand before I try this.
Tony
M85 S120 is two minutes (S is in seconds). The reprap description is linked by @foosel above, and the Marlin description is at http://marlinfw.org/docs/gcode/M085.html
From the Marlin description I believe that every move resets the timer.
1 Like
Thanks. Appreciate the nudge in right direction. 
Looks like this is going in all of my future GCode from now on.
Now since Octoprint is sending all of the Gcode over to the printer when a job is active, is there any way that this can just be done by default or tick box by Octoprint? Seems like it shouldn't be an issue to have Octoprint inject that code when a job is started. Just as an extra safety measure.
Just add it to your "before print job starts" GCODE script:
I'm a bit reluctant to add it by default since not all firmware might support it and this could lead to hilarious results if that command is interpreted differently by some other variant (because who cares about standards and such...).
1 Like
I agree, M85 is not wildely spread enough to be sent by default by octoprint
Personnally, I put it on my custom GCode in my slic3r, so this "watchdog" is activated only when needed (i.e. when printing something, and not when messing with my hotend to clean it)
@ibgeek sorry for the delay, @b-morgan has right, M85 timer is in second and reset at every move command received by Marlin, so as soon as the host hangs for every reason, the printer will be halted after the delay
note that this is not perfect and would be problematic with some setup (mainly with multiples extruders and while switching hotends)
Thanks yep It also doesn't work with filament run out sensors unless you build in enough time and are there to get it done under that time. Was a bit of a rude awakening but if it keeps my home from catching fire, I'll deal with it until something better comes along.