The most common reasons for this are - believe it or not - the same as for random SerialExceptions. So make sure to check those points given there.
Further things to check after you've ruled out the above:
If you are running into a timeout right on connect, your printer might not be ready for a handshake fast enough. Make sure "Wait for start on connect" is checked under Settings > Features. If that doesn't help, try increasing the Connection timeout under Settings > Serial Connection.
Your firmware variant might "block" on commands and don't report anything back to OctoPrint while waiting for user input directly on the printer (M600 is a prime candidate for this on a lot of firmwares). Since there's no "heartbeat" in the communication protocol that your printer talks, OctoPrint has no way to distinguish between a printer that actually crashed or otherwise went AWOL and a printer that simply is giving it the silent treatment due to an improperly implemented GCODE command. OctoPrint errs on the side of caution and assumes the worst to alert the user. You can add such commands to the list of "long running commands" under Settings > Serial Connection > Advanced options - that will only increase the timeout though, not completely ignore it. You can also disable consecutive timeout detection during long running commands at the same location, that should also help. This is only working around a firmware issue however. There are hundreds if not thousands of firmware variants out there that vendors ship with their printers, never update from the mainline distributions and which are usually also heavily modified without any thought about breaking established communication standards. The result of that are issues like this. So please also complain to your firmware supplier/printer vendor about these kinds of problems, in the hopes they might fix their stuff.
If you are running into lots of communication issues on Original Prusa printers with firmware 3.1.0, read this:
If you have "Linear Advance" enabled in your firmware, try disabling it and see if that improves the situation. Depending on your printer controller that feature can cause too much computational overhead and interfere with serial communication timings.
If you are running into these issues on a Pi, also make sure to try another Pi a as it might be a hardware specific issue as experienced by @Brent_Dowelland shared in this post below.
Just wanted to share my experience with using a Pi 3 to control my printers. I've been using Octoprint with a pi 3 on my first Anet A8 for over a year now with no problems.
I recently built an AM8 printer spending a lot of time on cable managment, etc. only to find that once I finished I was getting the dreaded communication errors where the usb connection would drop pretty regularly. I did a lot of research and followed all of the suggestions regarding power supplies, usb cables, etc. Even went so far as to take things apart moving the pi and cables away from other components suspecting some sort of interference. None of it helped.
So, Then I just popped the sd card out of Pi, put it right in another Pi and connected that up. Bingo. Everything works reliably now.
So in my case at least, it appears that the first Pi I used has some sort of issue with maintaining a USB connection and it had nothing to do with the cables or power supply.
Just one other thing to think about if you are at your wits end with that particular error.
I've put my Ender 3 Pro in an insulated enclosure mostly to help keep the dust down (I live in the Desert), but also to insulate it from drafts and figured I might need it for future higher temperature filaments.
The enclosure works well, but it was a little dark, so I got some under-cabinet LED lights and installed them inside the enclosure. They work well, and now my old eyes can see what I'm doing when I try to service the printer.
Suddenly, my communications errors on the octopi went bananas, litterally from zero errors on an hours-long print to 20% errors on a single-layer bed-level test that took 8 minutes.
Turns out the 12v 2A power supply that came with the lights is VERY noisy, and since it was on the same power strip as the octopi, it was wreaking havoc.
My solution for the time being was to get a separate led strip for the printer that runs off of the Ender's 24v supply, and only use the cabinet lights when performing maintenance.
I was having similar reconnect issues, when power cycling the printer via PSU control. The printer most of the time would not auto reconnect as it used to.
I tried to adjust all the handshake settings in Octoprint it self, without positive outcome.
Yet the culprit was not how Octoprint tried to auto connect, since all those settings seem to relate to server start and not reconnecting when the printer when off/online.
The PSU plugin needed to be adjusted with 'Post On Delay'. This is the setting that controls the behavior on reconnecting when power cycling via PSU control. The main problem was, that the USB port did not show up in the system /dev list the moment the command was given, it takes about a second for this list to refresh. Once the port is listed in the system its happy days for auto reconnect !
I just want to add to this. I also had problems due to the PSU plugin due to this. By simply extending the timeout or waiting period to attempt connection after the PSU is turned on solves the problem for me.
