Same issue here on both my Ender 3 and CR10s Pro.
Random disconnects since upgrade to 1.5.1.
Did a fresh install and upgrade on the CR10, same issue....
We need logs. Complete logs. We cannot see what you are seeing, we cannot help you unless you give us logs.
Same issue, same timing, printed fine overnight and for weeks previously, updated to 1.5.1 this morning and ran into the issue above.
Edit: This error was also triggering a watchdog error on my Prusa Mini that I needed to clear on the screen. I just rolled back to 1.4.2 and everything is working fine again (I skipped 1.5.0 because there was a bit of other flakiness with it that I had, until now, blamed on my failing trackball buttons of all things).
serial.log (5.3 KB)
octoprint.log (119.1 KB)
2020-12-06 19:13:21,180 - 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 3831, in _readline
ret = self._serial.readline()
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 6455, 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-12-06 19:13:21,250 - octoprint.util.comm - ERROR - Please see https://faq.octoprint.org/serialerror for possible reasons of this.
2020-12-06 19:13:21,281 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:3831)"
2020-12-06 19:13:21,285 - octoprint.filemanager.analysis - INFO - Starting analysis of local:Frankensteinpaddle_switchplate_nosupport.gcode
2020-12-06 19:13:21,287 - 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/Frankensteinpaddle_switchplate_nosupport.gcode
So... this error message comes with an FAQ link. Have y'all actually read it?
As written there, this is happening a layer beneath OctoPrint. Whatever is going on, the serial connection closes on OctoPrint. That's not something it can do anything about. I don't know why this happens now and didn't before (nothing in the serial communication was changed that could even begin to explain this).
For those of you with Creality printers, those are known to have several hard- and firmware issues, including massive backpowering problems:
Rule that out being the issue here first please.
I found this in your log:
2020-12-06 19:11:33,988 - werkzeug - INFO - 127.0.0.1 - - [06/Dec/2020 19:11:33] "e[37mGET /?action=snapshot HTTP/1.1e[0m" 200 -
2020-12-06 19:11:44,985 - werkzeug - INFO - 127.0.0.1 - - [06/Dec/2020 19:11:44] "e[37mGET /?action=snapshot HTTP/1.1e[0m" 200 -
2020-12-06 19:11:55,692 - werkzeug - INFO - 127.0.0.1 - - [06/Dec/2020 19:11:55] "e[37mGET /?action=snapshot HTTP/1.1e[0m" 200 -
2020-12-06 19:12:06,336 - werkzeug - INFO - 127.0.0.1 - - [06/Dec/2020 19:12:06] "e[37mGET /?action=snapshot HTTP/1.1e[0m" 200 -
2020-12-06 19:12:17,189 - werkzeug - INFO - 127.0.0.1 - - [06/Dec/2020 19:12:17] "e[37mGET /?action=snapshot HTTP/1.1e[0m" 200 -
2020-12-06 19:12:27,184 - werkzeug - INFO - 127.0.0.1 - - [06/Dec/2020 19:12:27] "e[37mGET /?action=snapshot HTTP/1.1e[0m" 200 -
2020-12-06 19:12:32,073 - werkzeug - INFO - 127.0.0.1 - - [06/Dec/2020 19:12:32] "e[37mGET /?action=snapshot HTTP/1.1e[0m" 200 -
Something is misconfigured on your end, OctoPrint is trying to take webcam snapshots from itself, that won't work. Not saying this is related, but you still should take care of it.
What kind of watchdog error, what was the message? From your serial.log, the connection breaks down during a blocking heatup, without anything even done by OctoPrint during that time.
Before this gets misunderstand as a "bug denial" here - I'm not saying what y'all are observing is wrong or that there are no bugs at all in 1.5.1 (there always are bugs in every single piece of software on this planet), but what I'm trying to tell you is that this particular error is an error that happens outside of my control. I wouldn't even know how to intentionally trigger it from my end inside OctoPrint, let alone stop triggering it, and based on the changes I have done on 1.5.0/1 to the communication layer, I also have no idea at all how this could be caused by the update, so I'd prefer if we could all rule out any other options first.
1 Like
I did read the FAQ before posting, but since it wasn't happening until 1.5.1, and others were reporting the same thing, I wanted to add my experience here.
This is the watchdog error I'm getting.
Interestingly enough, my printer is in the basement and the temps reported by the printer are just under 16C - as mentioned in the comments of the link above. Could be a factor, but doesn't explain why 1.4.2 works fine and 1.5.1 is grumpy (temps before heating up were below 16C for both versions).
If your environment is that close to the mintemp shutoff, I strongly recommend to solve that first. Again, I cannot tell you why 1.4.2 vs 1.5.1 makes a difference here, I didn't touch anything that would even remotely explain it, but I'd like to rule out hunting ghosts.
It's on my list, heh. Only recently became that cold in there.
At any rate, it appears to be a coincidence that I experienced this error on the same morning I upgraded to 1.5.1. 1.4.2 just experienced the same problem but 1.5.1 is happy to print if I preheat the printer. 
1 Like
Updated to1.5.1 and started having the same issues. Switch usb ports on my pi 3 and tried again and haven't had an issue since. I have no idea why that worked though.
So, this is a complete shot in the dark, but I'm curious... Do y'all with the Creality printers remember if you had an active connection from OctoPrint to the printer when you ran the update?
I have similar issues with my Anet A8, since I updated to 1.5.1 i started having some "pauses", producing ugly warts in my prints.
ATM I can't produce logs because I am away from the printer, but I saved this string from terminal:
Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
I printed perfectly for months before upgrading.
It could indeed be a coincidence, but starts to smell cheesy...
While I updated Octoprint the USB cable was connected but the printer was off.
Hi,
I too have the same issue, with Octoprint 1.4.2 no issues, since upgrading 1.5.1 every print more or less fails.
Octoprint 1.4.2 on a Raspberry Pi (octopi) 3b+ - works
Octoprint 1.4.2 on a Intel NUC (Ubuntu 20.04) - works
Octoprint 1.5.1 on a Raspberry Pi (octopi) 3b+ - fails with serial device disconnections
Octoprint 1.5.1 on a Intel NUC (Ubuntu 20.04) - fails with serial device disconnections
I have tried around 4 old USB cables AND 3 brand new ones - Anker, AmazonBasics etc, with and without ferrite cores on each end.
Printer: Creality Ender 3 v2 - Firmware: Marlin E3V2-2.0.x-14-Smith3D.M (Oct 13 2020) - Latest - I use a BLtouch 3.1 ABL.
Serial connection details: /dev/ttyUSB0, baudrate 115200
Here is the extract from the log:
2020-12-10 12:18:02,213 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 61213}
2020-12-10 12:25:58,737 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/util/comm.py", line 3831, in _readline
ret = self._serial.readline()
File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/util/comm.py", line 6455, in readline
c = self.read(1)
File "/home/pi/oprint/lib/python3.7/site-packages/serial/serialposix.py", line 596, in read
'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2020-12-10 12:25:58,920 - octoprint.util.comm - ERROR - Please see https://faq.octoprint.org/serialerror for possible reasons of this.
2020-12-10 12:25:58,983 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:3831)"
2020-12-10 12:25:59,042 - octoprint.plugins.action_command_notification - INFO - Notifications cleared
2020-12-10 12:25:59,955 - octoprint.plugins.tracking - INFO - Sent tracking event print_failed, payload: {'origin': 'local', 'file': '5cbc456b2e5466882bd8e802ef37a48595e2cfd7', 'elapsed': 10326, 'reason': 'error', 'commerror_text': "SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:3831"}
For the time being, I have reverted back to 1.4.2 as I was not experiencing any issues with that version of OctoPrint.
Everyone observing this - and by "this" I explicitly mean constant "SerialException: device reports readiness to read but returned no data" issues after an update to 1.5.x with 1.4.2 being fine, nothing else - please provide:
- Printer model (if modified: printer electronics)
- OctoPrint, Python & (if applicable) OctoPi version
- full octoprint.log
- Whether a connection to the printer was active at point of update or not
- Whether the issue persists in safe mode
- Whether the issue persists after switching the USB port
- Whether the issue persists after a reboot of the system OctoPrint is installed on
- If on a Pi:
- Pi model
Currently seeing this primarily with Creality printers as far as I can tell.
2 Likes
Foosel,
Please see below my responses to your query (inline):
-
Printer model (if modified: printer electronics)
Creality Ender 3 v2
Firmware: Marlin E3V2-2.0.x-14-Smith3D.M (Oct 13 2020) -
OctoPrint, Python & (if applicable) OctoPi version:
Octoprint: 1.5.1
Python: 3.7.3
OctoPi: 0.17.0 -
full [octoprint.log] - See attached log below
-
Whether a connection to the printer was active at point of update or not:
Yes -
Whether the issue persists in safe mode
Unknown -
Whether the issue persists after switching the USB port
Yes -
Whether the issue persists after a reboot of the system OctoPrint is installed on
Yes -
If on a Pi:
- Pi model
Model 3B+
- Pi model
octoprint (4).log (603.6 KB)
--
Also:
Whilst I do not have logs as I have disconnected the NUC:
Same versions as above, but the hardware - GIgabyte Brix GB-BACE-3150 - with Ubuntu 20.04 LTS
Happy to upgrade again to 1.5.1 if needed for diagnosis etc.
EDIT:
Update 1: printing in 1.4.2 without a a reboot after downgrading from 1.5.1 to 1.4.2 (I did do a service octoprint restart) caused a serial port issue, so I have hard rebooted the Pi (shutdown -h now) and killed the power, rebooted the OctoPrint instance into SAFE MODE and I am trying again (1.4.2).
I have noticed in the logs, that the safe list (blacklisted plugins) have included all previous version of the GCodeEditor plugin. I have the latest version installed (which is not blacklisted) I also see a tuyasmartplug plugin error as well.
Now all the plugins are disabled due to printing in safemode, so hopefully the print completes (its a long 9 hour print).
I have enabled octoprint.log and serial.log logging.
If this safemode print is successful, I shall upgrade to 1.5.1 and try a safemode print (or simply rebuild the MicroSD card with a fresh OctoPi 0.17.0) and try it with no plugins.
Either way, I shall not be re-introducing the GCodeEditor plugin.
1 Like
Here is my info:
- Printer model - Ender 3 with updated MKS Gen L main board
- OctoPrint, Python & (if applicable) 1.5.1 / 0.17.0 Python I think is 3.7.3
- Whether a connection to the printer was active at point of update or not - Yes it was as I remember
- Whether the issue persists in safe mode
- Whether the issue persists after switching the USB port - Yes
- Whether the issue persists after a reboot of the system OctoPrint is installed on - Yes
- If on a Pi:
- Pi model - 3b+
Also, I run Octoprint on an Artillery Sidewinder X1 which also has a MKS Gen L board. The difference is I run the TH3D firmware on my Ender 3 and I run Vanilla Marlin 1.9 on the X1 and it is running fine after the update to both 1.5.1 and 1.5.2.
Jeff Lovell
octoprint.log (74.1 KB)
1 Like
Quick update. In looking at past log files on my Ender 3, The update to 1.5.0 worked ok, is it only the 1.5.1 and 1.5.2 that is causing the issue.
Jeff
This is even more confusing, and makes it look more and more like this problem is coincidence to me. Since there were no changes anywhere near printer communication, I can only assume it was either the update process, or coincidence, or some mysterious ghosts that we have no idea about. The number of people reporting this seems too high to be complete coincidence, but then I am yet to see a pattern, evidence or other significant indicator of what this might be.
I wonder if it would be worth trying to roll the update back to 1.5.0/1.4.2, to try and rule out any code changes made (if any?) that would impact this. Shot in the dark, but if it starts to work again then that would be a massive step in the right direction