Failing to connect to printer

What is the problem?
Serial connection keeps failing. It started when we "stress-tested" the printer by pulling the serial cable from the Rpi to the printer out of the printer, and now it just won't connect, after being perfectly connected for a long time.

What did you already try to solve it?
We usually connect to the printer using the REST api, so we tried this as well as doing it manually without our API-system running.

We also monitored the htop to see if anything was out of the ordinary (as Googling' lead us to some posts where this was brought up), but nothing popped up. The htop.out is in the shared log-folder below though.

We have 8 other of the exact same printer running the exact same firmware, octoprint version as well as Raspberry version - only this one printer has the issue.

Switching out the Raspberry did "fix" the issue, but we'd very much like to figure out why this happened, so it can be avoided in the future - maybe we are doing something wrong?

Update while writing; we managed to get it connected once, but pulling the serial cable and inserting it again resulted in the same issue - all other printers can handle this just fine

The log files
The lines below is what keeps happening. It looks like it connects to the printer just fine - it receives a lot of data before suddenly saying "Connection closed"

Changing monitoring state from "Connecting" to "Offline"
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=0x6fd340f0, 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
Send: N0 M110 N0*125
Recv: start
Send: N0 M110 N0*125
Recv: echo: External Reset
Recv: Marlin 1.0.0
Recv: echo: Last Updated: Oct 29 2016 10:22:46 | Author: (none, default config)
Recv: Compiled: Oct 29 2016
Recv: echo: Free Memory: 11431  PlannerBufferBytes: 1232
Recv: echo:Hardcoded Default Settings Loaded
Recv: echo:Steps per unit:
Recv: echo:  M92 X80.00 Y80.00 Z400.00 E93.00
Recv: echo:Maximum feedrates (mm/s):
Recv: echo:  M203 X500.00 Y500.00 Z5.00 E25.00
Recv: echo:Maximum Acceleration (mm/s2):
Recv: echo:  M201 X500 Y500 Z100 E5000
Recv: echo:Acceleration: S=acceleration, T=retract acceleration
Recv: echo:  M204 S500.00 T500.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 X20.00 Z0.40 E5.00
Recv: echo:Home offset (mm):
Recv: echo:  M206 X0.00 Y0.00 Z0.00
Recv: echo:PID settings:
Recv: echo:   M301 P21.73 I1.54 D76.55
Connection closed, closing down monitor

Full logs;

Additional information about your setup
OctoPrint 1.3.12 running on OctoPi 0.15.1 - Raspberry Pi 3B

You have a ton of exceptions in your lock that indicate issues with exclusively locking the port due to it being "temporarily unavailable". That sounds like there's a connectivity issue after all. Check the output of dmesg.

I also see some serious allocation issues further down where it can't start additional threads anymore in various cases. Sounds like something seriously got messed up somewhere. I'd try and see if you can reproduce the issue in safe mode & without your "API-system" to rule that out as the culprit.

That message

Connection closed, closing down monitor

can also come from an earlier connection (there's a slight delay in this message being generated after a disconnect, so something belonging to an earlier connection can show up in one opened immediately after). A full serial.log of a failing connection would be interesting, the snippet you pasted doesn't look like it's actually disconnecting or there would be a line that says so. It looks like the start messages sent by a printer right after it resetting (possibly due to connect).

Sounds like an issue with either the printer or the Pi then.

Also, who is "we"?

1 Like

I'll try some things and get back to you! It also sends a request to our server every time it's trying to connect, and it kind of seems like it does this quite a few times every second, probably resulting in a lot of unfinished threads running on top of each other. Another printer just "caught" this error, which was fixed by disabling our entire system (octoprint plugin as well as a script running every minute from the crontab). This happened after an update where I was supposed so have made the "auto serial connect" using our system much better (by making it more agressive), but I think the printer needs a break - gotta slow it down a bit.

"We" talked to you a few months ago on Discord about an Octoprint hub system we're working on, now called "SimplyPrint"; https://simplyprint.dk/ - danish startup helping schools have a functional 3D-printer room, and guide them how to use it in their classes :slight_smile:

Hello,
I try to connect the octoprint to the printer (prusa MK3S) but I can't do that, it tells me that " Error: Failed to autodetect serial port, please set it manually. "
I connected the webcam to the RPI zero W, and I see what camera sees on octoprint, but I can't connect to the printer, I dont' see any temperature. :frowning_face:
I'm using the latest version of octoprint software flashed on RPI zero W.
What can I do in order to fix the problem?

Thank you all!

  1. Use the search instead of hijacking an unrelated thread

  2. Don't use a ZeroW, contrary to what Prusa recommends. I who happens to have written OctoPrint don't recommend it. It is slow, underpowered, causes all kinds of issues. Get a Pi3 and use that.

  3. If you connect via GPIO/the board's header pins, make sure to enable "RPI Port" in the printer's settings, otherwise (= USB connection between Pi & printer) disable it:

    OctoPrint won't connect to my Prusa MK3

Thank you for your advice, sorry for writing in a wrong thread. It seemed to be the right one.

I did indeed send to many serial-connection requests, which I previously thougth Octoprint handled (not allowing the API to send a "connect" reuqest if it is already trying to connect), but now I've set a cap that it tries max. 1 time every minute.

The printers were being requested to up to every 4 seconds, so it's understandable that the serial connections kept giving up.

Thanks for your time @foosel !

She does this for a living; I'd suggest that you're a prime candidate for visiting her patron site and making a contribution.

We 100% agree. We plan on making a contribution per. month per customer ($20) :slight_smile: Talked about this in PM as well! Love Octoprint and wouldn't be where we were without it!

1 Like