Unable to connect to printer after fresh OctoPrint instyall

Get Help
1

Unable to connect to printer after fresh install of OctoPrint. Worked fins for past several years, but had to reinstall OctoPrint from scratch since I couldn't figure out how to upgrade Python the latest version. After the install, OctoPrint cannot connect to the printer, although it can connect to the Pi camera.

What did you already try to solve it?

Disconnected the USB cable connecting the Pi to the Prusa MK3S,
ssh to Pi and entered "dmesg -w", then entered a few blank lines.
Plugged in the USB cable and got the following (suggesting that the Pi/OctoPrint can see the printer):

[ 5140.469160] usb 1-1.4: new full-speed USB device number 5 using dwc_otg
[ 5140.614675] usb 1-1.4: New USB device found, idVendor=2c99, idProduct=0002, bcdDevice= 1.30
[ 5140.614706] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5140.614719] usb 1-1.4: Product: Original Prusa i3 MK3
[ 5140.614728] usb 1-1.4: Manufacturer: Prusa Research (prusa3d.com)
[ 5140.614738] usb 1-1.4: SerialNumber: CZPX2920X004XK01629
[ 5140.616335] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device

Ran OctoPi and got the following on the serial log after clicking the "Connect" button, showing that although the Pi can see the printer, it's unable to connect after the "N0 M110 N0*125" command (or any command??).

Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 7 port/baudrate candidates: /dev/ttyACM0@115200, /dev/ttyACM0@250000, /dev/ttyACM0@230400, /dev/ttyACM0@57600, /dev/ttyACM0@38400, /dev/ttyACM0@19200, /dev/ttyACM0@9600
Trying port /dev/ttyACM0, baudrate 115200
Connecting to port /dev/ttyACM0, baudrate 115200
Handshake attempt #1 with timeout 2.0s
Connected to: Serial<id=0x70f8d8c8, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0125
Recv: Command not found!
Recv: start
Changing monitoring state from "Detecting serial connection" to "Operational"
Send: N0 M110 N0125
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N1 M11539
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N2 M2118
octoprint-systeminfo-20250425092029.zip (89.6 KB)
ecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from "Operational" to "Offline after error"
Connection closed, closing down monitor

Have you tried running in safe mode?

Yes, but still have the problem

Did running in safe mode solve the problem?

No

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)
Zip file attached..

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

Octoprint version 1.11.0
OctoPi Build 2025.04.22.094030 with "webcamd", based on OctoPi 1.0.0, running on Raspberry Pi 3 Model B Rev 1.2
Prusa MK3S
Latest operating system from OctoPrint downloads

2

image
image708×62 6.5 KB

2025-04-24 15:31:10,412 - octoprint.util.comm - ERROR - Something crashed inside the serial connection loop, please report this in OctoPrint's bug tracker:
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/comm.py", line 3222, in _monitor
    self._perform_detection_step()
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/comm.py", line 3515, in _perform_detection_step
    self._trigger_error(error_text, "autodetect")
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/comm.py", line 4123, in _trigger_error
    self._callback.on_comm_error(
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/printer/standard.py", line 1545, in on_comm_error
    self._error_info = ErrorInformation(
  File "/home/pi/oprint/lib/python3.9/site-packages/pydantic/main.py", line 253, in __init__
    validated_self = self.__pydantic_validator__.validate_python(data, self_instance=self)
pydantic_core._pydantic_core.ValidationError: 2 validation errors for ErrorInformation
faq
  Input should be a valid string [type=string_type, input_value=None, input_type=NoneType]
    For further information visit https://errors.pydantic.dev/2.11/v/string_type
logs
  Input should be a valid list [type=list_type, input_value=None, input_type=NoneType]
    For further information visit https://errors.pydantic.dev/2.11/v/list_type

curious, have you tried setting the port and baudrate instead of using AUTO?

3

I just tried al; baud rates, and the only one that received a response was 115200. I still got a time out though, so this seems to suggest that the baud rate and port (/dev/ttyACM0 and 115200) are correct. The problem still persists, so I'm not sure what to try next. The log portion that at least seemed to receive something:

===
Connecting to port /dev/ttyACM0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0x6786a580, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Recv: start
Send: N0 M110 N0*125
There was a timeout while trying to connect to the printer
Changing monitoring state from "Connecting" to "Offline"
Connection closed, closing down monitor

4

Is anything showing up on the printer side when you start the connection, ie Prusa firmware update prompt or anything else on the printer's screen?

5

When I click the connect button in OctoPrint, the printer screen shows a 3 line message:

Original Prusa I3
Prusa Research
3.14.1

After a second or so, the screen switches back to the default screen, showing the temps, etc.

6

I wonder if enabling this option in OctoPrint settings would help.

image
image936×612 28.8 KB

7

Thanks for the suggestions, and my apologies for taking so long to respond. I had previously enabled "Wait for start on connect", but that had no effect; the printer still disconnected after a short period of time.

I think what I'm going to do is pull the SD card, reflash it, and start over. That's relatively quick to do and should give me a clean start with all default parameters.

I'll be back…

8

I did a fresh install of OctoPrint, but the problem still remains. After setting up OctoPrint in the web app, I tried a connect and got the following:

===
Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 7 port/baudrate candidates: /dev/ttyACM0@115200, /dev/ttyACM0@250000, /dev/ttyACM0@230400, /dev/ttyACM0@57600, /dev/ttyACM0@38400, /dev/ttyACM0@19200, /dev/ttyACM0@9600
Trying port /dev/ttyACM0, baudrate 115200
Connecting to port /dev/ttyACM0, baudrate 115200
Handshake attempt #1 with timeout 2.0s
Connected to: Serial<id=0x71dcd358, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0125
Recv: Command not found!
Recv: start
Changing monitoring state from "Detecting serial connection" to "Operational"
Send: N0 M110 N0125
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N1 M11539
Communication timeout while idle, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Send: N2 M2118
No response from printer after 3 consecutive communication timeouts, considering it dead. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
Changing monitoring state from "Operational" to "Offline after error"
Connection closed, closing down monitor

Looking at the above, it does appear that a connection is successful (line 6). The failure occurs right after sending "N0 M110 N0*125" in line 7, where line 8 shows "Recv: Command not found!". I'm not sure whether or not this is expected, but operation does continue from this point, so I'm guessing that it's OK.

Line 10 seems to indicate that everything is operational, but all subsequent send commands (lines 11, 13, and 15) fail with a timeout error.

Again, this is a fresh install with nothing else added. The previous version of Octoprint used to work, so this is something new that has happened since I upgraded to the latest version that (presumably) includes a newer version of python.

I'm attaching a system bundle for this version in case that helps diagnose the problem. If there's a way to drop back to the previous version I would appreciate some information on how to do that. If that's not possible, I'm stuck with printing from the SD card, which is clearly less than optimal.

octoprint-systeminfo-20250426110938.zip (21.6 KB)

Thanks in advance for any help...

9

Yeah, but there is no reponse from the printer for any of the following commands from this point on.

try enabling serial logging in OctoPrint's settings and attempt the connection again, then re-share your system info bundle.

10

After digging around some more, I finally found the problem. It turns out that the RPi port in the MK3S printer was enabled. Disabling it fixed the problem, and now communication proceeds with no issues at all and everything is fine. No idea how it got enabled, but I'm guessing it was done by some dumb operator (me).

Thanks for all the help with this, and my apologies for tying up this forum with a problem that was clearly of my own making.

1 Like
11

yeah, the only reason I didn't mention that setting was because you said it had been working. I think I remember someone mentioning that there's got switched with a firmware update.