SerialException error immediately on print start

What is the problem?
My printer was working 2 days ago. I've made no configuration changes, hardware nor software, and suddenly I'm getting SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?) immediately on print start. This happens either when I start a previously successful print, or when I set a temperature of the hotend. When I try to start a print, the bed gives 1 twitch that sounds like starting the homing process, then stops and throws the error.

What did you already try to solve it?

  • Rebooted Pi and power-cycled printer
  • Rebooted Octoprint in Safe mode
  • Checked seating of USB cable on both ends

Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)
serial.log (12.5 KB)
octoprint.log (96.4 KB)

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible)

  • Printrbot Simple Metal
  • Octopi 1.3.10 running on a PiZero-W
    Setup has been working fine with no changes for over 6 months.

Please don't tell me I've got a dead printrboard.
Thank you

Hello @Alex_Holman!

To check if the printer board still works with the USB, connect it to your PC with Pronterface running. You also may check the quality of the USB cable. Maybe a new installed electric device nearby you can cause EMI.

1 Like

The Zero only has one core and half the memory of a 3B. Do yourself a favor and upgrade this.

Hi,
Thanks for the suggestion. I fired up Pronterface on the laptop with a new USB cable and tried a test print. Got the same result. Output from the Pronterface console is:

Connecting...
echo:Unknown command: "~"
Printer is now online.
SENDING:M84
Loading file: /home/holman/holman_storage/Documents/3dFiles/calibration_40x10/calibration_40x10.gcode
Loaded /home/holman/holman_storage/Documents/3dFiles/calibration_40x10/calibration_40x10.gcode, 10404 lines
112.66mm of filament used in this print
The print goes:
- from 61.07 mm to 91.34 mm in X and is 30.28 mm wide
- from 56.07 mm to 96.33 mm in Y and is 40.27 mm deep
- from 0.00 mm to 12.00 mm in Z and is 12.00 mm high
Estimated duration: 59 layers, 0:08:37
Print started at: 09:53:31
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 501, in read
    'device reports readiness to read but returned no data '
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/printrun/printcore.py", line 260, in _readline
    line = self.printer.readline().decode('ascii')
  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 509, in read
    raise SerialException('read failed: {}'.format(e))
serial.serialutil.SerialException: read failed: device reports readiness to read but returned no data (device disconnected or multiple access on port?)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.7/threading.py", line 926, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.7/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/printrun/printcore.py", line 347, in _listen
    line = self._readline()
  File "/usr/lib/python3/dist-packages/printrun/printcore.py", line 281, in _readline
    if 'Bad file descriptor' in e.args[1]:
IndexError: tuple index out of range

I think with pronterface and a new USB cable generating the same error, I'm going to move onto trying to reflash the firmware for my printrboard... unless anyone shouts "Dear god no, try this first" before I get around to figuring out how to do it.

Any other suggestions are welcome.

1 Like

Your serial cable should be as short as possible and include internal metallic shielding or a ferrite core. Otherwise, electrical interference can be seen on the TX/RX lines.

Okay, I completed the firmware flash following the instructions from www (dot) brookdrumm (dot) com (slash) firmware. Obfuscated because I'm limited on newbie accounts.
It completed properly and... same issue.

For completeness, here's the logs post firmware flash
serial_post_firmware_flash.log (52.5 KB) octoprint_post_firmware_flash.log (24.5 KB)

Also, given the suggestions above about the USB cable, I've tried a handful from my collection. I don't have any that are micro-usb with a core or are visibly shielded, but I'll look to source one.

  1. Existing cable, 6in long, no ferrite core, has worked reliably for +2 years
  2. High quality looking cable, 3ft feels thick enough to possibly be shielded.
  3. Just another cable, 3ft, its black.

Again, none have worked. Not to dismiss the advice above (I'm still looking for a ferrite'd or shielded cable), but this doesn't feel like a random EMF error. The connection fails reliable directly after print start.

Not sure about your Marlin. Do you need to install one of the plugins related to grbl as a result? (Wouldn't know, personally.)

That's a pretty high baud rate if you're having troubles. You might consider knocking that down to 115200 while troubleshooting this.

I took the firmware instructions and image off Brook Drumm's website. He's the founder and head of Printrbot, so I'd trust him to give a proper firmware image and complete instructions. I'll give a try at dropping the baud rate, though I'm inclined to try poking as few variables at a time as possible.

So another data point, according to the logs the machine seems to fall over proximal to issuing Send: N2 M104 S210*100. To confirm, if I go into the gcode terminal and send a M104 the machine falls over. However, interestingly, if I send an M104 with a temperature under the current ambient temperature of the hotend, everything continues working just fine.
At this point I'm starting to wonder if my power supply went poof and just isn't able to supply the wattage needed to heat the hotend. Alternatively, is the power distribution on my Printrboard fried? I've got an ATX power supply kicking around (currently the machine has been running off a laptop style power supply because I don't have a heated bed). I'll give the ATX supply a shot in the next day or two.