Serial connection dies- just started today

#1

What is the problem?
Error in state - Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2605)

What did you already try to solve it?
Complete reinstall, new USB cable, multiple reboots, safe mode different a/c outlet

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
MP Maker Select Plus - Stock Printer Firmware - Logs

Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: ['/dev/ttyUSB0']
Connecting to: /dev/ttyUSB0
Changing monitoring state from "Detecting serial port" to "Opening serial port"
Connected to: Serial<id=0x6a5f65b0, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Send: N0 M110 N0*125
Recv: start
Recv: echo:Marlin 1.0.0
Send: N0 M110 N0*125
Recv: echo: Last Updated: Oct  7 2016 08:56:29 | Author: (none, default config)
Recv: Compiled: Oct  7 2016
Recv: echo: Free Memory: 3892  PlannerBufferBytes: 1232
Recv: echo:Stored settings retrieved
Recv: echo:Steps per unit:
Recv: echo:  M92 X80.00 Y80.00 Z400.00 E94.00
Recv: echo:Maximum feedrates (mm/s):
Recv: echo:  M203 X450.00 Y450.00 Z5.00 E25.00
Recv: echo:Maximum Acceleration (mm/s2):
Recv: echo:  M201 X3000 Y3000 Z100 E3000
Recv: echo:Acceleration: S=acceleration, T=retract acceleration
Recv: echo:  M204 S1000.00 T800.00
Recv: echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s),  Z=maximum Z jerk (mm/s),  E=maximum E jerk (mm/s)
Recv: echo:  M205 S0.00 T0.00 B20000 X10.00 Z0.40 E1.00
Recv: echo:Home offset (mm):
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echo:PID settings:
Recv: echo:   M301 P33.00 I1.00 D-67.00
Recv: echo:SD card ok
Recv: ok
Changing monitoring state from "Connecting" to "Operational"
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: FIRMWARE_NAME:Marlin V1; Sprinter/grbl mashup for gen6 FIRMWARE_URL:http://www.mendel-parts.com PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000
Recv: ok
Send: M20
Recv: Begin file list
Recv: 1A29A~1.GCO
Recv: 2B31B~1.GCO
Recv: 344CC~1.GCO
Recv: 41DDD~1.GCO
Recv: PI_CAM~1.GCO
Recv: SPOOLR~1.GCO
Recv: CABLEC~1.GCO
Recv: SHELFG~1.GCO
Recv: BRACEL~1.GCO
Recv: CELTIC~1.GCO
Recv: VASE~1.GCO
Recv: EINSTE~1.GCO
Recv: JFKBUS~1.GCO
Recv: BANGLE~1.GCO
Recv: BENDER~1.GCO
Recv: End file list
Recv: ok
Send: M105
Recv: ok T:23.1 /0.0 B:24.5 /0.0 T0:23.1 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.9 /0.0 B:23.7 /0.0 T0:22.9 /0.0 @:0 B@:0
Send: M105
Recv: ok T:22.7 /0.0 B:23.9 /0.0 T0:22.7 /0.0 @:0 B@:0
Send: M105
...
Recv: ok T:34.6 /0.0 B:31.8 /55.0 T0:34.6 /0.0 @:0 B@:127
Send: M105
Recv: ok T:34.5 /0.0 B:31.8 /55.0 T0:34.5 /0.0 @:0 B@:127
Send: M105
Recv: ok T:34.4 /0.0 B:31.9 /55.0 T0:34.4 /0.0 @:0 B@:127
Send: M105
Recv: ok T:34.7 /0.0 B:32.0 /55.0 T0:34.7 /0.0 @:0 B@:127
Send: M104 S185
Recv: ok
Send: M105
Recv: ok T:34.7 /185.0 B:31.9 /55.0 T0:34.7 /185.0 @:127 B@:127
Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2605
Please see https://faq.octoprint.org/serialerror for possible reasons of this.
Changing monitoring state from "Operational" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2605)"
Connection closed, closing down monitor
#2

You suggest that you did a complete re-install. I might assume from that everything was working prior to this but correct me if I'm wrong.

As serial cables go, you want one that connects on both ends without extra adapters, it's as short as possible to do the job and it either has internal metallic shielding or it has at least one ferrite core. Both ends of the connection should fit snugly; if it makes/breaks connections while your printer is moving around then that's no good.

Your log reasonably tells a story of something that's almost working well. And yet, it throws the M104 command to heat up your hotend I assume to 185 degrees C and then things go bad.

Is it that your firmware gets quiet after a blocking command like M104? And yet it seems to answer at least one temperature request and the temperature target changed to 185.0 which is expected. It seems to respond "ok" after the M104 itself.

Not sure what else I can add to this. Of course there's a link provided.

#3

@ScottZ0, does your printer need the connection fix plugin?

Secondly, try experimenting with the values at settings->printer->serial->intervals->timeouts. Just for fun, set those two connection timeouts to 10x the values listed. I tend to think it's related to that.

#4

Hey all. Thanks for the help. Its very strange since it was working perfect until this morning. I tried all suggestions, but its sadly still happening. Here is some additional info if anyone has any ideas. When I set the bed temp to 55 c it accepts the change in the target box but the temp never rises. I don't get an error until I try and set the hotend. Its strange that the camera works perfect. Also, I can upload gcode but it just freezes the program. It definitely is a one way communication. Any additional ideas would be greatly appreciated.

#5

I would suggest that returning to the original serial cable might be the best chance for success (as long as it has internal metallic shielding or a ferrite core).

Unless you say otherwise, we have to assume that your controller's firmware didn't get upgraded in any of this.

You didn't indicate whether you manually entered the M104, whether this came from your slicer or whether this came from your Gcode Scripts in the startup section.

Start researching the gcode values that you might see. An M104 and an M109 are different. The first is non-blocking, you set the target temperature but don't wait for it. The second is blocking, the firmware won't continue until the target is reached. I see different approaches with slicers. Some will initially run an M104 at first, start homing the axes and then run an M109. Approaches like these can help a slow bed heater, for example.

I've seen this approach sometimes, written in pseudo-gcode:
; Non-blocking heatup of the bed temp to 50
; Non-blocking heatup of the hotend to 170
; Home everything, reset things, set mode(s) of movement
; Run autoleveling routine
; Blocking heatup of bed temp to 60
; Blocking heatup of hotend to 190
; Move to position of priming line, etc.

Is it possible that your hotend's thermistor wiring (or the thermistor itself) got damaged or became disconnected? It's a common problem on my particular printer because the wiring connections are fragile there. Sit there with a hair dryer, heat the hotend manually like that and watch the temperature graph, it should respond to being heated up. If there's no change then this could be the cause.

#6

Hi All. I just wanted to update this and say it is now resolved. After purchasing a new USB cable and a new power adapter the issue persisted. The reason the error code was showing up in Octopi > State was related to the power switch on the MP Maker Select +. I had it in the off position and when any settings were changed within Octopi it would reboot the printer which generated the error code. When I moved the power switch to on it worked as designed. I feel stupid it was such an easy fix and I bothered the community without doing simple diagnostics. In any case. thanks again for the help.

S