TL;DR - Raspberry Pi w/ OctoPrint driving a Printrbot Rev F board (#Frankenbot). Had a communication error and recovered.
Had a bit of a scare last night. While watching a print job underway, the head suddenly stops moving. The heater is still pulsing, but motion commands have stopped flowing. The terminal viewing in OctoPrint had some errors I have never seen.
Since the head was still heating and sitting on the print, I clicked “Cancel” in Octoprint.
And then the print job CONTINUED! (normally the Cancel would prompt for confirmation, it didn’t).
I grabbed the error lines (see below) and let the print job continue. Which it did to completion 4+ hours later without any further issues (other than some lifting off the bed. grrr)
But now I’m a little spooked. Why did the communication trip/fail? and why didn’t the Cancel, cancel?
Here’s the section of communication of relevance:
Send: N14820 G1 X86.010 Y133.587 E4071.83963108
Recv: ok
Send: N14821 G1 X85.160 Y133.755 E4071.87623106
Recv: Error:No Line Number with checksum, Last Line: 14820
Recv: echo:Unknown command: “5”
Recv: ok
Send: N14822 G1 X84.556 Y133.946 E4071.90299102
Recv: echo:Unknown command: “”
Recv: ok
Send: N14823 G1 X83.759 Y134.297 E4071.93978106
Recv: Error:Line Number is not Last Line Number+1, Last Line: 14820
Recv: Resend: 14821
Recv: ok
Send: N14821 G1 X85.160 Y133.755 E4071.87623106
Recv: ok
Send: N14822 G1 X84.556 Y133.946 E4071.90299102
Recv: ok
@Stephanie_A Could be. But with only one data point out of millions of successful transmissions, it really could be anything: faulty printrboard, pi, jiggled the cable, reflected some EMI w/ my energetic personality, sunspots, who knows.
To be honest, I’m a little more disturbed that the “Cancel” button on OctoPrint didn’t do what I expected. In this case it saved my print, but really, Cancel should mean Cancel. Not retry or continue.
@David_Sherwood Agreed. The printrboard has a separate physical power switch, and if things had gone further south, that was the next thing I was going to hit.
3d printing is a dark art. can you reproduce it? I know it sounds cold but if not, there is nothing I can do w the info. Even if you can, it would be very very difficult to explain. Marlin only really ever says “ok”…“ok”…“ok”… thanks, marlin.
Hang in there!
Brook
@Brook_Drumm Am a sftw dev by trade. Totally get it. Not much you can go on from me. But figured I’d throw it out there in case others might have similar one-offs that can be strung together.
For now, I’m chocking it up to sunspots
Although, it would be interesting to note what kind of fail-safes are in Marlin (as David alluded to). Things like thermal runaway if thermistor/PID fall out of range, or doing an immediate Z+5mm and cut heaters if there’s a communication error. Stuff like that.
For the record, a cancel in OctoPrint when streaming the file to the printer (= not printing from the printer’s SD) doesn’t require serial communication, it will in fact just stop sending the commands from the file you are printing - and of course also attempt to trigger the cancel script (= shut off heaters, motors, whatever else you have configured). The fact that you didn’t even get the confirmation sounds like something didn’t work out at all on the client side of things - it didn’t ever send out the cancel request to the server, or stuff WOULD have stopped.
If it’s not reproducible however, I’m in the same boat as Brook here, can’t do a lot besides guessing at what could have been the cause I recently found another race condition in the code that might cause issues that make your client lose its login session but it still thinking you have it, but that should still attempt to send data to the server and only fall on its face then - which it doesn’t sound like what happened here. So right now all I can do is say “eh” and shrug helplessly.
I’ve had a similar issue just happen 7/4. The print just stopped, kept heaters on though. I noticed it when watching remotely via telegram plugin, but it wouldn’t take the abort command for some reason. I was luckily able to remote into my PC and use that to stop the print via octoprint interface.
Looking at log it says it changed state from printing to error " printer requested line… But no sufficient history is available, can’t resend!
I’m removing all the recently installed plugin just in case since in the log there are errors with the new octoprint anywhere plugin.
@David_Sherwood regular cancel does not do an emergency shutdown (M112). And boy would people get pissed at me if I enforced something like that “I want to cancel my job” and “omg I need to shut things down stat” are two distinct use cases. The cancel button covers the former. For the latter you don’t really want to rely on M112 because that will be worthless in case of a firmware lockup (if there still is a serial connection OctoPrint will try to force this command down its throat repeatedly, but if there isn’t or the firmware doesn’t receive it’s worthless). You want an actual hardware cut-off for emergencies, ideally wired up to be accessible via remote as well.
Update: The errors were getting worse and worse. I found a thread from 2013 where Gina was wrestling with a checksum bug or something and in there was someone commenting on restarting their Pi. Which I hadn’t done in a while. TOP was showing a load, and the webcam software was burning up a lot of CPU cycles. So I did that - and promptly lost my wifi adapter. (builtin - V3 Pi) sigh. Haven’t resolved that yet, but clearly there’s something amiss with my hardware. I also took the opportunity to put a choke on both the USB cable into the Printrboard and the power supply into the Pi. I’m now running with a wired LAN connection, choked cables, and no camera. Will see if that improves things.
Seems the behaviour was somewhat random that I observed. Since this post I have noticed blobs/scars on prints. When the errors starting happening more frequently, I was able to just observe - and after many seconds, and even sometimes a couple of minutes, the commands would get resent and the job would continue. So, the checksum/line#/communication errors were not fatal, but definitely not ideal.
Question: Is there a way to add a “grep” feature to OctoPrint’s terminal viewer? 300 lines is a rounding error in the stuff that’d dumped. I’d like to put a “grep error” and only see 300 lines of errors. (Well, actually, I’d like to see no errors, but if there are errors, I don’t want them rolling off without being noticed)
can you reproduce it? I know it sounds cold but if not, there is nothing I can do w the info. Even if you can, it would be very very difficult to explain. Marlin only really ever says “ok”…“ok”…“ok”… thanks, marlin.
