OctoPrint randomly loses connection to the printer with a "SerialException"

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 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.
  • If all of the above is fine, you are running OctoPrint from a Pi and you are still running into issues you might also want to try the following. 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.

if you loose connection does that mean you have to start over with your print? or is there a way to reboot and pickup where it left off.
Thank you

Start over.

"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).

1 Like

Would it be possible to have the printer trying to connect again and at least shut down any heaters?

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.

Any thoughts?


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? :smile:). 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...

1 Like