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?)
Maybe some other process is trying to read from /dev/ttyUSB0
Maybe the USB cable is in bad shape or loose
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)
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
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" )
@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.2 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.
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.
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
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.
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.
Thanks for the input, I had previously read the remarks regarding EMI so already working towards eliminating that as a possibility.
Literally nothing has changed in my setup in over a year. Print bench has printer, raspberry pi, and a single LED lamp that's on the opposite end of the bench, no less than 24" from any printer wiring. Surge protector powers only the Pi and the Printer and is in fact EMI shielded (according to the labeling, at least).
I'm sourcing a new cable with ferrite core but not convinced that will be the solution. My wiring could be a bit neater, so I'll tend to that as well. I also should likely update my Marlin, but again, it's worked without issue for several years, and without features or hazards to entice me to upgrade, I'm not really inclined to do so.
I can print small jobs without issue, it's only a few hours in where the SerialException message pops up and OctoPrint halts and disconnects, leaving the printer hot and unmoving.
I'll check back after new cable arrives to report if that changes anything.
Thomas, if you're still here - please explain how you designed the gcode with a million M117 commands... M808? Sounds better than wasting filament!
I tried to replicate Thomas' million M117 tactic, but M808 isn't supported in my version of Marlin, and I don't see another way beyond lots and lots of gcode!
I did find a ferrite shielded cable and have replaced it (along with the voltage pin electric tape); currently attempting a 5 hour print of an object that ended in serialexception failure twice before.
(there's also a ferrite core/shielded cable on its way from the river, expected in a few days)
Thank you, b-morgan, for offering suggestions. I've long acknowledged that this is a tinkering hobby, and it's great to have others throwing ideas into the mix.
I received ferrite cores today. I installed 2 on the usb cable and I'm running the 10M lines gcode, if everything goes well, it should run for the next 24h
Thanks for the info, and I'm happy to report that previous print finished successfully! The only thing the original cable was near was the printer's own power supply... maybe that damned thing has just gotten more (electromagnetically) noisy over the years and finally overwhelmed it. The cable I replaced it with is about 10 inches long, doesn't wrap around or under anything, and while I don't have the specs it is thicker (likely shielded) and includes the ferrite nugget on the printer end.
I'm officially a convert, and a happy camper as well.
Thank you, Thomas; and thank you b-morgan!
I could run the 10M lines gcode properly, so I decided to get closer to a real setup : near the printer I have a few ESPs connected to my homeassistant for lights and camera control, so I turned these on, heated the printer and ran a small print, it went well. However the issue came back with longer prints (couldn't get more than 1h printing...). I think the ESPs and printer motors are very noisy (electrically speaking), and this might make the setup more error prone.
I've ordered a shielded usb cable with ferrite cores, I'm currently waiting for it, but apart from the cable and the cable management, the only other thing I can think of as an improvement here would be to move the entire printer's motherboard somewhere else (out of the printer at least). And if nothing works, maybe I'll try to get another motherboard with a wifi module and keep printing from SD card meanwhile.
)
