Octoprint - Concerning behavior while printing

Get Help
1

What is the problem?
Yesterday I started printing the owl model which comes bundled with Creality CR-10 MAX printer, on its SD Card. Printing started fine, was supposed to finish overnight, and when I woke up this morning, the printer was stuck at some point, hotend active, and OctoPrint was non-responsive. As a matter of fact, the whole Raspberry Pi was AWOL. It is the second time OctoPrint becomes unresponsive. The first time the print actually finished, so all I had to do was reboot the RPi. This time though...

What did you already try to solve it?

Nothing I really could do to resolve it, except read what is provided in the logs and try to make sense of it.
First off, I have installed and using Motion to connect to a USB Webcam and capture snapshots every minute. This way I was able to catch the moment it failed, and check the logs.

Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)

I will post relevant excerpts but if you need me to, I can upload logs somewhere and link the here.

2020-05-22 03:22:04,503 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 03:22:14,438 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 66611}
2020-05-22 03:26:26,939 - octoprint.util.comm - INFO - Finished in 35004.658 s.
2020-05-22 03:26:26,940 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Finishing"
2020-05-22 03:26:26,950 - octoprint.filemanager.analysis - INFO - Starting analysis of local:Maria/CCR10MAX_ofw_face_front.gcode
2020-05-22 03:26:26,955 - octoprint.filemanager.analysis - INFO - Invoking analysis command: /home/pi/oprint/bin/python2 -m octoprint analysis gcode --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 /home/pi/.octoprint/uploads/Maria/CCR10MAX_ofw_face_front.gcode
2020-05-22 03:26:27,026 - octoprint.printer.standard.job - INFO - Print job done - origin: local, path: Maria/CCR10MAX_ofw_face_front.gcode, owner: war
2020-05-22 03:26:27,169 - octoprint.plugins.DisplayLayerProgress - INFO - Printing stopped. Detailed progress stopped.
2020-05-22 03:26:27,408 - octoprint.plugins.tracking - INFO - Sent tracking event print_done, payload: {'origin': u'local', u'throttled_mask': 131072, u'elapsed': 35004, 'file': '0c710814e2fce2509410a2f76650f02e9304aad8', u'throttled_now': False, u'throttled_past': True}
2020-05-22 03:26:30,122 - octoprint.util.comm - INFO - Changing monitoring state from "Finishing" to "Operational"
2020-05-22 03:27:21,277 - octoprint.filemanager.analysis - INFO - Analysis of entry local:Maria/CCR10MAX_ofw_face_front.gcode finished, needed 54.33s
2020-05-22 03:37:04,504 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 03:37:14,441 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 67511}
2020-05-22 03:52:04,506 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 03:52:14,540 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 68411}
2020-05-22 04:07:04,509 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 04:07:06,854 - octoprint.util.connectivity_checker - INFO - Connectivity changed from online to offline
2020-05-22 04:22:04,512 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 04:37:04,514 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 04:52:04,516 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 05:07:04,518 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 05:22:04,521 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 05:37:04,523 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 05:52:04,525 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 06:07:04,528 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 06:22:04,530 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 06:37:04,532 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 06:46:45,664 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2823, in _readline
ret = self._serial.readline()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 4968, in readline
c = self.read(1)
File "/home/pi/oprint/local/lib/python2.7/site-packages/serial/serialposix.py", line 501, in read
'device reports readiness to read but returned no data '
SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2020-05-22 06:46:45,801 - octoprint.util.comm - ERROR - Please see https://faq.octoprint.org/serialerror for possible reasons of this.
2020-05-22 06:46:45,811 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2823)"
2020-05-22 06:52:04,534 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-05-22 06:17:09,637 - octoprint.startup - INFO - ******************************************************************************
2020-05-22 06:17:09,640 - octoprint.startup - INFO - Starting OctoPrint 1.4.0
2020-05-22 06:17:09,641 - octoprint.startup - INFO - ******************************************************************************

As you can see, first off Octoprint (wrongly) believes the print has finished. The owl is still half way through, and my snapshot webcam images show the printer doing its job until the very last moment, when it stops abruptly, hotend at 200 degrees Celsius, and stays in that position until I wake up and shut down the printer.
Another issue is OctoPrint thinking it went offline at 04:07:06, something must have happened wither with the RPi or the OS.
Finally the log messes up timestamps for some reason, which makes no sense to me.

Syslog also points to loss of network connectivity:
May 22 04:05:03 octopi kernel: [232630.445064] CIFS VFS: Server 192.168.2.100 has not responded in 180 seconds. Reconnecting...
May 22 04:05:45 octopi kernel: [232672.924049] uvcvideo: Failed to query (GET_DEF) UVC control 2 on unit 2: -110 (exp. 2).

Motion outputs webcam snapshots directly to my NAS, and the last saved image was at exactly 4:00 AM.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)

OctoPrint Version 1.4.0, OctoPi Version 0.17.0, running on Raspberry Pi 4 Model B Rev 1.2, printer: Creality CR-10 MAX, firmware 1.7.0, browser is Google Chrome, Operating System (used to access OctoPrint) is both Windows 10 x64 1907 and Android (while using OctoRemote).

I really don't understand why OctoPrint suddenly decided the owl has finished printing (it was about half way through in terms of Z-Height). More troublesome is the fact that the hotend remained primed for hours.

2

I think it's a power related issue.
Is your power supply sufficient?

3

Original Raspberry Pi power supply, 5V, 3A, provided by Plusivo, namely this kit: https://www.plusivo.com/kits/83-plusivo-pi-4-super-starter-kit-with-raspberry-pi-4-with-4-gb-of-ram-and-32-gb-sd-card-with-noobs.html

4

Not wishing to be argumentative but (a dead give away that thats exactly what I'm going to be) but the PSU with that kit is not original Raspberry. There are several posts that attest to just how critical a solid PSU capable of delivering sufficient current, is to correct Pi4 operation.

2 Likes
5

I am sorry, this was my first RPi, so I assumed the kit would contain the right power supply. Sounds like they were slamming the wrong thing in there. Shame on them.
I have just ordered the original (as in truly original) power supply. Will take a few days, so in the meantime I'll just print from the printer's SD Card.
Thank you for this information!

1 Like
6

Also watch out for throttling warnings in the future.
This could help with power related issues

1 Like
7

Yes, I have noticed that, I will go ahead and tape the 5V pin - I have noticed that upon turning my printer off, if the RPi is still on, the printer display will remain on.

8

Perhaps you misunderstood, I did say that the supply you already have is not adequate simply that it is not a genuine Raspberry part. Note the genuine part is 5.1v 3A

9

It;s fine, I already ordered an original supply, I will replace it.

10

Some folks have indicated that the USB power from the p to the printer can be problematic and should be disabled. I think there is a post that talks about taping the power lead on the USB cable so that the printer power only comes from the printer power supply and not the Pi USB. It also suggests that this may help with power/ throttling issues.

11

The original (this time truly original) power supply came today, I replaced the other one, will tape the power pin as well tomorrow. Today it hanged again just before the new power supply was delivered, the RPi was unconnectable (through web, SSH, etc) but continued sending GCode to the printer.

12

I had the same issue with my Pi. I found a 5.2V@ 3A PSU and all my problems went away. If you are close to "starving" your Pi, you are GUARANTEED to have issues like you are now experiencing. It is not a fault of the Pi or the software, you simply need to give it the power required to run. Keep in mind, power consumption can change abruptly due to what the Pi is doing in the CPU, memory and the power hungry peripheries you have plugged into it.

13

Besides the power issue, which applies to all models, the Mod 4 suffers from excessive heat, which does indeed cause it to freeze up. There have been multiple firmware updates that have improved the problem.

Pay attention to your heat-sinks, but the most effective way of minimising the problem is to mount the unit vertically, with the USB cables at the bottom (best) or with the power cable at the bottom (2nd best).
In order to check if heat is indeed your problem, run another test with a fan blowing in a way that gets the air moving on both sides of the board. It is really important that the underside of the board is not right up against something - you want to make sure there is air movement on both sides even if you don't have heat problems.

14

I have installed the new power supply, so far, so good. I don't think it was a matter of overheating, OctoPrint displays a visual warning as well as entry in its log files if temperature reaches 80 degrees or more. This temperature isn't reached even while the RPi compiles timelapses, which sometimes take 20-25 minutes to finish. Same for undervoltage warnings, they do appear on the UI and in logs.

The RPi is not enclosed in a case. Well, only the bottom part is, the top part is left open. I have been monitoring its temperature in terminal, never reached 70 degrees while in use.
Maybe the power supply was bad, or maybe there was something else at work. I will update this thread if this happens again.

15


I bought one of these, to isolate power to the CR-10S Pro V2, different from yours. I bought a powered usb strip to plug the camera in because they are power hogs. Don't scrimp on a good one. I have not had an issue since. But before, like you the thing would just hang up and I did have an official RPI power supply. This is the USB hub I ordered.
https://www.amazon.com/gp/product/B076YN6CSG/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

16

Very nice product, but shipping costs 4 times the actual product price to get to me :slight_smile:
I will modify it myself.

17

It happened again. Lost all connectivity while printing, print didn't stop and eventually finished well, timelapse capture didn't stop, captured all required frames but didn't convert to mpg. I couldn't access the RPi at all until I pulled the power plug and connected it to power again.
When it restarted, I was able to convert the timelapse, and the Print Job history plugin showed me it managed to measure used flament and all other details, including the thumbnail for the print.
I believe the Pi loses Wireless connectivity for some reason, based on this relevant entry from the logs:

2020-05-31 04:51:47,777 - octoprint.util.connectivity_checker - INFO - Connectivity changed from online to offline

I really have no idea why, the wireless network works, I have checked my AP and router logs and they show no interruption.

I guess I will have to buy a monitor and connect a keyboard and mouse to the Pi and manage it locally if this happens again.

18

I have a similar problem. If I have the Webcam tab open, after a while the WLAN connection drops. In my case it seems the WLAN-AP is the culprit. If I reboot it all is well. Otherwise maybe it's some weird interaction of AP vs RPi.

19

In my case it's not the AP. I tried rebooting it to no avail, as a matter of fact all my other wireless connected devices (plenty of them) continue to work perfectly.

20

Update: I have switched from Wireless 5 GHz to Wireless 2.4 GHz and connectivity is now rock-solid. It seems that when the Pi briefly had wireless connectivity interrupted for some reason, it never retried connecting again.
Now all works perfectly.

1 Like