Long print interrupted


#1

What is the problem?
I started a print that should last about 12h but discover in the morning that the print stopped near half of the job. Despite there was apparently no problem, the bed was still hot, the nozzle too, the head still in position ...

What did you already try to solve it?
I tried to connect with my phone and saw that it printer was offline (it was still switched on and wired to the raspberry). So I Switched the printer off and on ... still no connection, and then unplugged and plugged back the raspberry and still offline.

Later on, from my computer I could connect to the printer, but I'm not sure it's possible to resume the print ?

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)octoprint.log (32.5 KB)
Additional notes:

  • My raspberry is a PiZero (latest generation).
  • It's the first time I have this issue
  • It's the first print right after a long time due update (to OctoPrint 1.3.8, OctoPi 0.14.0)

Thanks for any help !


#2

Based on your log, your printer stopped responding to commands sent by OctoPrint at 23:04

2018-07-19 23:04:42,929 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2018-07-19 23:05:12,963 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2018-07-19 23:05:42,996 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2018-07-19 23:06:13,019 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2018-07-19 23:06:43,067 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2018-07-19 23:07:13,110 - octoprint.util.comm - INFO - No response from printer after 6 consecutive communication timeouts, considering it dead.
2018-07-19 23:07:13,177 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Offline (Error: Too many consecutive timeouts, printer still connected and alive?)"

Subsequent attempts to reconnect to it this morning also didn't work out:

2018-07-20 05:39:51,381 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial port"
2018-07-20 05:39:51,417 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial port" to "Connecting"
[...]
2018-07-20 05:40:26,536 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Offline"
[...]
2018-07-20 05:40:49,509 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial port"
2018-07-20 05:40:49,541 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial port" to "Connecting"
2018-07-20 05:40:49,595 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
[...]
2018-07-20 05:41:24,653 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Offline"
[...]
2018-07-20 05:41:53,891 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Opening serial port"
2018-07-20 05:41:53,921 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial port" to "Connecting"
2018-07-20 05:41:53,969 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
[...]
2018-07-20 05:42:29,083 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Offline"

The log hints at the printer also not responding to the handshake M110 that OctoPrint sends out there.

So, based on just this log and without any access to the terminal output or a serial.log, it looks like for some reason the printer started giving OctoPrint the silent treatment, which of course made it impossible to run a print job. I note that you also have Octolapse installed and active based on the two present logs of resend requests which both happened exactly after M400 + M114 probably sent by Octolapse:

2018-07-19 22:15:50,673 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 83006, current line = 83008
| Last lines in terminal:
| Send: N82997 G1 Z7.990 F1002*19
| Recv: ok
| Send: N82998 G1 E0.2000 F4200*51
| Recv: ok
| Send: N82999 G92 E0*68
| Recv: ok
| Recv: ok
| Send: N83000 M83*19
| Recv: ok
| Send: N83001 G1 E-6.50000 F5100*37
| Send: N83002 G91*24
| Send: N83003 G1 Z0.200 F1000*17
| Send: N83004 G90*31
| Send: N83005 G1 X150.000 Y150.000 F3600*68
| Send: N83006 M400*42
| Send: N83007 M114*43
| Recv: ok
| Recv: ok
| Recv: Error:checksum mismatch, Last Line: 83005
| Recv: Resend: 83006

I'm not aware of any printer timeout issues between 1.3.8 and Octolapse, but maybe @FormerLurker has some more insight there than me.

Finally:

Not really. You could try measuring the z-height, manually adjusting your GCODE file so that it starts at the point it most likely stopped and then run that. But if that will work out depends on a ton of factors and is somewhat unlikely.


#3

I had this exact scenario a few days ago and posted here. I was using a Pi 3B and have Octolapse installed but it wasn't active.


#4

It's certainly possible that this was Octolapse, but I don't see a response to the M114 command, which is odd. Octolapse has an (admittedly obscene) hard-coded 10 minute timeout for this command, so even in the worst case scenario it should respond after that.

However, I have updated the timeout and timeout handling in the latest release candidate to handle some other issues I've run into. Also, there are some updates to OctoPrint that deal with the 'job_on_hold' lock that Octolapse uses to stop the current print. It might be a good idea to try this with the newest release candidates (OctoPrint 1.3.9rc4, Octolapse v0.3.3rc1). You can install the Octolapse release candidate from the plugin manager using this URL: https://github.com/FormerLurker/Octolapse/archive/v0.3.3rc1.zip

This release candidate of Octolapse requires OcotPrint 1.3.9rc3+. It has known issues with previous versions.

If you want to be my guinea pig, you are welcome to try v0.3.3rc2.dev from this url: https://github.com/FormerLurker/Octolapse/archive/v0.3.3rc2.dev.zip

The only difference between the two is that the development version allows you to track and update maintenance and development builds from the software update plugin. It is still under development, and I'm still figuring it all out, but it seems to work for stable, release candidate and development branches. I've not figured out how to 'downgrade' yet, however, so if you wish to do that you'll need to do that in the plugin manager (uninstall/reinstall or manual downgrade via the release url).


#5

The problem is that it requested a resend of a line before the M114 was issued, and since we don't have a serial.log, there's no way to know if that was handled properly after the resend request was processed.

I remember stumbling over an issue with resend handling during an active job_on_hold while debugging our dead lock issue though, so maybe this is related. Sadly though, impossible to say without a serial.log so all this is just guess work on my side really :slight_smile:


#6

Thank you all for your answers.
What I'm going to do is

  • Upgrade OctoPi to latest version
  • Enable serial logging
  • Try to print a simpler model
  • If it happens again, I'll try disabling Octolapse

#7

Hi @Julien_Amsellem What ended up happening the next time you tried? Did you have to disable Octolapse? I just experienced the same issue as shown in your log after about 7 hours of printing. Late comment here I know, but any update here?


#8

Hi Welsh3D,
I retried a second time with Octolapse enabled and it did print perfectly (about 17h of printing).
So I guess it's a seldom issue. Now I have updated to latest OctoPi version and did not face the issue again (but I don't print very often).