A "SerialException" like e.g. device reports readiness to read but returned no data indicates that something a layer beneath OctoPrint broke and the connection to your printer was lost due to that. There's nothing OctoPrint can do about this - as already said the issue happens beneath OctoPrint. It's basically like someone pulled the rug from beneath its feet.
The most common reasons for this are:
You forgot to actually turn on the printer.
You are running OctoPrint on a Raspberry Pi but have not powered said Pi from a good power supply: The Pi is notoriously sensitive with regards to its power supply, and there are a lot of power supplies on the market that don't stand up to this. Make sure your power supply does provide continuous 5V of voltage and at least 2.5A of current/3A for a Pi3. Things like cellphone or tablet chargers or cheap PSUs might claim they do but don't actually, causing your Pi to brownout. A lot of users have reported random disconnect and also other communication issues to go away once they used a different power supply with their Pis, ensuring them to no longer brownout. Monitor the red LED on your Pi, it should not be flickering. If it does, swap your power supply. See also the discussion in this issue.
You are running OctoPrint on a Raspberry Pi and your USB peripherals (printer + maybe webcam + maybe wifi dongle) draw too much power via USB. Try connecting your printer and other USB peripherals through a powered USB hub. Check this page before buying something - not all powered hubs are known to play nice with the RPi.
You are trying to access your printer's serial connection from another process than OctoPrint at the same time: Don't. Identify the process in question and stop it. OctoPrint can't reliably talk to a printer when half its messages go to another process. Serial ports do not magically multiplex, you can only connect with OctoPrint OR something else.
Your printer's USB cable came loose: Make sure your cable is firmly attached to both your printer and the system you are running OctoPrint on. Ensure no spouses, children or pets are capable of accidentally changing this when you are not in the vicinity.
Your printer's USB cable has some internal breakage: Test if the disconnect can be triggered by wiggling the cable. If so, something inside your cable is broken. Swap the cable.
Your printer's USB cable is not properly shielded and/or too long and/or running next to your printer's motor or heater wiring: Use a properly shielded USB cable with a ferrite bead on the ends (those black heavy cylinder things), as short and possible and not routed next to your printer's motor or heater wiring.
You might be experiencing electrical noise: If your printer operates on a circuit with other devices, especially those with motors in them, try to isolate it, and see if that makes a difference. Consider that you may need special equipment to provide a clean electrical supply. See this topic for some related experiences.
Some people report that their Raspberry Pi's internal USB hub is resetting on its own, causing all USB connections to be reset. Apparently adding dwc_otg.speed=1 to /boot/cmdline.txt (or just cmdline.txt when using your Pi's SD card like a thumb drive) and rebooting to force the USB speed down can help here, even though this should be fixed with recent kernel versions. Mind that this will make any high-speed USB devices (e.g. keyboards, webcams, ...) most likely stop functioning. See also this thread and this ticket.
"But OctoPrint does know where it was in the file!" - yes, but it doesn't know which of the commands it had already sent to the printer had actually been executed by it (thanks to 2-3 buffers on the printer's side). And with the connection gone it also can't really ask it.
On print fail OctoPrint will store the position in the file it was at, and in theory someone could write a plugin with this information to perform print recovery. I wrote a proof of concept for that once but it wasn't reliable enough to publish for general consumption (due to the aforementioned issues).
In general, you really should rather concentrate on fixing the communication loss issues instead of trying to reconstruct half way failed prints, especially since even if with a full blown automatic recovery you'd still get minimal layer shifts and such due to the margins in the endstops (and if the connection was lost you can bet on having to rehome in x/y and doing a wild guess at z height).
In principle yes. But then the tricky questions start. How many reconnection attempts? What timeouts? When's the proper time to just give up entirely? And what if the printer was SD printing when the disconnect happened, in that case a reconnection attempt could nuke the SD print due to the printer controller restarting. But maybe that's what the user wants? But if they don't now you have a really upset user on your hands. So you need a setting for this (yet another one). Default to enabled or disabled? What to recommend even? And now we've spent hours on implementing something like this in a more or less meaningful way when the actual problem that should be solved is the serial connection loss in the first place.
Not saying "nope, not going to happen" - just want to point out why things like this aren't as easy to do as they might seem at first look.
Gina sorry if i am not following normal contact procedures, but my computer skills are limited, and i find it difficult to navigate your web site,
I have a request for future upgrades . this is my current screen view , the second pic is when i use control and scroll on the the mouse to inlarge.
it would be great if I was able to free float the windows to move them side by side so I can get a better view without having to scroll up and down.
Thanks for your time and consideration.
Keep up the great work this is an excellent program !!
I too am have had multiple failed prints due to this issue. I have a cankit official 2.5 amp Rpi supply on both a pi 3 b and a p13b+ .Should I try a higher current power supply or a usb powered hub? I have been running octoprint from my laptop with windows 10 and the same USB cable so octoprint and the cable are not to blame. It must be the Pi (although it happens on both the 3b and 3b+) or the power supply.
Just had a variation on the dodgy USB cable theme.
Symptoms were that everything would seem to run fine - interactive setup was no problem. However after some continuous use (i.e. a few minutes into a print) the Pi would stop getting responses from the printer.
It did turn out to be the cable. I didn't have a simple USB-A to mini-USB-B cable to hand for a new installation, so I robbed an old "Y" cable from an external disk drive that I no longer use (remember them? ). This cable has two USB A connectors on one end, and a mini-USB B on other. The first USB-A connector is data, the second USB-A connector is power-only.
Turns out the first USB-A connector is only wired for data, no ground or 5v power (I guess it's broken - the point of the second USB A was to steal power from two USB ports sufficient to power the disk drive, so I think the first connector was originally connected for power too). Connecting that second USB-A to the Pi solved the problem.
I think this means the data connections were floating, and eventually it was enough to fail to register properly - and that it was connecting the common ground that solved it. I'd noticed that the printer wouldn't draw power from the Pi (normally the main board will steal power enough to boot and drive the LCD) but thought nothing of it...
I noticed today, that for my SKR 1.4 turbo (LPC1769) the marlin FAST_PWM_FAN option makes communication at 250 kbaud (did not test other baud rates) very unstable. Could be either fan-cable routing or the PCB routing but electromagnetic noise seems to be the issue here.
Switching FAST_PWM_FAN off (default is disabled) again solves the issue completely.
I have been battling the SerialException issue for weeks now. It always appears to connect successfully, but then when I try to print I get this error:
Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:3831)
I'm using a Raspberry Pi 4 with OctoPrint 1.5.0 with an Ender 3 v2 (was previously on 1.4.2). Following the advice above, I've upgraded my power supply and I've tried one of the powered USB hubs from the sanctioned list above. I don't believe I have any conflicting serial connection issues, and I don't believe my USB cable is loose. I've tried several different USB cables at this point. I don't know what else to try other than purchasing another USB cable that is perhaps more shielded than what I've tried (although I feel like I've tried shielded). Can anyone recommend an "ideal" USB cable for this? What about this one?
I've been trying really hard to get this to work for quite a while now, and I'm just about out of ideas. Any help would be greatly appreciated because I don't know what else I can even try at this point. I fear that I'm stuck here, and if I don't receive any new ideas I'll have to give this project up, which I would hate to do! Thank you in advance.
I've spend 2 weeks literally loosing sleep over the frustration of not being able to fix something seemingly simple as keeping a serial connection up. So for any other unfortunate souls who like me try everything (different usb cables, 5v tape, different power supplies, use a Windows machine with Octoprint instead of pi which decreased my failure rate from 100% to 50%, ...) I will explain what happened to and worked for me: I have both my pi and my Ender 3 plugged into an extension cord in my basement. In that same extension cord, I also have two lights, for additional light in different sections of that basement. It turns out that if I turn on or off one of those other lights, something happens (not sure if it's power surge or drop or electro-magnetic or whatever) that causes the Ender3 motherboard to disconnect. I get "usb_serial_generic_read_bulk_callback - urb stopped: -32" in dmesg (when running on pi) and that's it. Sometimes the connection recovers by itself, as if by magic, and printing continues (I can see the , sometimes it doesn't, haven't tested further. So, if you too are investigating this issue with your setup, don't assume it's just the PSU that can cause problems, it can be unclean power that feeds into to PSU, too.
(this also explains why the stoppage would happen only when I wasn't watching. I spend literally hours watching the thing, hoping to see something that would give me a clue on why it failed. But of course I always had the light on when watching, turning it off when I'd had enough and left, after which it would crash.)
With the recent addition of a bed heater for my build plate, I was experiencing the dreaded "device reports readiness to read but returned no data" randomly, and none of the tips above helped.
What I noticed, though, is that the printer fans stopped when that error was raised, indicating that the controller board was resetting (a Printrbot Printrboard in my case).
The factory power supply for the Play printer delivers 12VDC/5a, so I guessed that the board was resetting due to undervoltage whenever the print steppers, bed heater, fans, hotend, and extruder were all running at the same time - a relatively infrequent and unpredictable event. I replaced the 5a printer PSU with a 10a model, and lo and behold, the problem has not occurred since.
Thanks for getting me started in the right general direction, and I hope this variation is helpful to someone!
I'm about to throw my pi and SKR into the god damned trash. I'm sick of these random serial "exception". It got a null read, why the fuck is that fatal error?! Just screw OP and use sd card.
Thanks for your insight, I was mad and blowing off steam.
Well is there something that doesn't hang up the phone if there is a second of dead air? I mean that's the dumbest error I've seen for a while. Serial is fraught with errors and it's hung onto like fax machines. That question is rhetorical.
I used to program MCUs like ESP32s, and only used serial to program them, NEVER for production communication when there is a thing known as WiFi. While wifi is slow, UDP packets were much much reliable than serial, yuck. I had quite a domotics operation going a few years back. ... I guess I could re-do pi and cut out the exception but that won't be easy now I read it wasn't Octoprints fault. And now i see that the darn OS resets the USB hub on some random whim? I could apply that patch, but I may lose function of my USB keyboard. I got a quality USB cable (tried 5), a good board (went through 4, 5 counting today, actually temporally reverting to my old stock 422 board), the pi seems ok (it's my 3rd), power supply is raspberry branded (my 2nd), I may try knocking down baud to 56k.
The board I had on my MPCNC had all kinds of issues with disconnects. I was finally able to pin it down to AC power fluctuations in my garage. When the garage freezer compressor would come on the board would disconnect from OctoPrint. You may be looking at a totally different issue.
). This cable has two USB A connectors on one end, and a mini-USB B on other. The first USB-A connector is data, the second USB-A connector is power-only.