Print jobs randomly stop with a SerialException

What is the problem?

My print jobs stop randomly, the printer disconnects, and Octoprint displays an error message : SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

What did you already try to solve it?

  1. Maybe some other process is trying to read from /dev/ttyUSB0
  2. Maybe the USB cable is in bad shape or loose
  3. Maybe some electrical noise is messing with the connection

For the "other process" issue, I checked with lsof while printing, and I'm confident no other process trying to read the serial device.

For the usb cable, indeed I was using an very old cable (cut and soldered several times, taped everywhere, not as old as me but not so far either). I switched for a new one (without ferrite core though), and the issue stays the same.

For the electrical noise, I reproduced the issue without actually printing anything, disabling motors, heaters, fans. I ran a gcode with a million M117 commands, and it still stops randomly (could go as far as 400K messages, which is roughly an hour of printing)

Have you tried running in safe mode?

Not yet.

Did running in safe mode solve the problem?

Will check asap.

Systeminfo Bundle

octoprint-systeminfo-20241229174542.zip (2.4 MB)

Additional information about your setup

Octoprint v1.10.3 running in a venv on an Arch Linux desktop computer connected with a usb cable (taped +5V pin) to an Ender 5 pro using Creality Marlin firmware with BLTouch. Browser is firefox 133.0.3.

What next?

For now I still have a few things to try :

  • safe mode
  • shielded usb cable / better electric isolation (will try to power the printed from a separate line)
  • build the latest stable marlin firmware

I understand Octoprint cannot do much about this lower level issue, but as many people seem to run into the issue, I'm seeking for guidance about the proper way to investigate further

1 Like

Hello @thomasnemer !

With no word you mentioned what printer you run.

You didn't even say what board are you using, how do you want people to help you? XD

Anyway, my particular case was solved by taping / cutting the 5v/ground wires of my USB cable.

Even though my board is supposed to not be affected by that problem because it has a jumper that prevents voltage backfeeding, removing 5v to begin with solved my problem.

(I actually didn't use tape or cut wire, I used female/male usb breakout boards and connected just the data pins, effectively making a "USB power condom" :rofl:)

Hi, thanks for the answers!

@Ewald_Ikemann : In the "setup" section of my question I wrote I'm using an Ender 5 pro. I should have stated that more clearly, my bad ^^

@Deses : I didn't specify the board as I didn't think it was relevant, but now you talk about it, it seems obvious ^^. I'm using the stock creality 4.2.7 board.

Another thing I should have mentioned yesterday : I already had this issue a few years ago (with the same setup) and that's why I ended removing the +5v from the USB cable, and it did the trick at that time.

Ooops, overseen that. Sorry

Since this is an issue that was corrected in the past, I would suggest you look at the things that might age or change over time. The main thing that comes to mind for me is the power supply for your printer. Maybe it has dipped a bit over time. Could be the main 24v or even the 5v coming off the board. Take a few measurements, see if any are suspect.

1 Like

Actually this made me think of a change I made : I switched the network on this part of the house from wifi + repeaters to PLC adapters, and the printer ended plugged on the PLC adapter for the room... So I tried to plug it on another circuit, and it seems there's an improvement, I could run a million M117 messages gcode file without issue (that's roughly 2h). I've generated a 10 million one and it's running right now, we'll see tomorrow how it goes :slight_smile:

1 Like

I get this issue with two Mingda Magician 3D printers, the X2 and the Magician Max2.

I've seen other Mingdas have similar issue so I suspect it's either the board setup or how its communicating with the USB C cable connection.

1 Like

The 10M lines Gcode didn't run entirely in the end, it got to 5M+, so there's definitely an improvement when not plugging the printer behind the PLC adapter. I've ordered some ferrite cores, and I'll try again when I'll have received those.

I'll never understand why 3D printers ever used serial ports, and it's certainly unfathomable why they still do.

I'm debating getting a small serial-to-ethernet bridge and having Octoprint print over ethernet to it.

1 Like

This has just started happening to me as well. Also 1.10.3 (on a Raspberry Pi 4 Model B), also an Ender 5 Pro. Today, I've swapped out the cable and taped the power line, but hardware wise nothing has changed in literally years and this has only started happening in the last 24 hours. Currently printing from SD card just to get a job done - OctoPrint has failed me for the moment. Not sure what's changed. I'll start disabling plugins when I have time to troubleshoot... I update those whenever they're available, so that could also be an issue.

This is most likely EMI which Creality printers are both very susceptible to and generators of. The best defense is a high quality, shielded USB cable with ferrite beads. Careful routing of all cables (i.e. reroute cables until the problem goes away).

EMI can come from devices other than the printer and the Raspberry Pi. Any new electronic devices under the Xmas tree? Solving EMI issues is probably the most frustrating of all issues. If at first you don't succeed, try, try again.

1 Like