Octoprint no longer connects if port set to AUTO

What is the problem?
When connecting to my Anet running Marlin 1.1.9, I have always left the port set to AUTO. I have never had any issues. Now, with 1.4.0, I can see it trying to connect, as it reboots the controller board as always, but on the terminal, it shows:

Changing monitoring state from "Offline" to "Detecting serial port"
Serial port list: ['/dev/ttyUSB0', u'/dev/ttyS0']
Trying /dev/ttyUSB0
Could not connect to or enter programming mode on /dev/ttyUSB0, might not be a printer or just not allow programming mode
Trying /dev/ttyS0
Could not connect to or enter programming mode on /dev/ttyS0, might not be a printer or just not allow programming mode
Changing monitoring state from "Detecting serial port" to "Error: Failed to autodetect serial port, please set it manually."
Failed to autodetect serial port, please set it manually.

If I set it to /dev/ttyUSB0, it connects without issue

What did you already try to solve it?

I have lengthened timeouts in the connection section, checked wait for start on command" all to no avail.

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

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

Octoprint 1.4.0 on Octopi0.17.0, Raspberry Pi 4B 4G version, Anet A8 printer, Marlin 1.1.9 firmware


I assume that if you select AUTO for the device, OctoPrint wants to make sure that this is something that can respond correctly if an attempt is made to put it into programming mode. Note what happens on line 2613; a list of one doesn't go through the stk500v2 handshake.

2020-03-05 16:50:13,325 - octoprint.util.comm - INFO - Could not enter programming mode on /dev/ttyUSB0: u'Timeout'

Looks like one of your plugins is throwing this, for what it's worth:

2020-03-05 16:49:55,903 - octoprint.util.comm - ERROR - Error while processing hook ABL_Expert:
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/util/comm.py", line 2849, in _readline
    ret = hook(self, ret)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_ABL_Expert/__init__.py", line 242, in on_printer_gcode_received
    self.printer_cap[cap] = int(line.split(':')[-1])
ValueError: invalid literal for int() with base 10: 'EEPROM OK '

Weird thing is, it never reaches the timeout set in the connection options. I have bumped all timeouts to 30 seconds. I get the failure in about 5 or 6 seconds. set to /dev/ttyUSB0, it has no issues.

Thanks for the heads up. ABL expert plugin said it's beta in the plugin list, so I removed it.

I walked the history of comm.py way back through 2019. The code in that section hasn't changed a bit.

1.4 broke mine as well. I have to go into config tell it a specific port, save, go back and set the actual port and hit save again and i can connect.

The same problem here. I even doesn't find that the manual connection settings fixes the problem :slight_smile: If I try to use AUTO mode, it fails imediately and Octoprint has no response - only fix complete restart or "service octorint restart".

Looking on GitHub, this appeared to be an issue in the RC's as well, and it was pushed out knowing it was an issue... Kind of sad.
rolling back to the previous version

Tell you what. If this occurs using your control board—and foosel can't reproduce this on any of hers—then it sounds like we need to identify what you're running if you're getting this.

  • Anet A8 printer
  • Marlin 1.1.9 firmware

It's this, right?

Why don't I buy one for foosel so that she can support it? (Honestly, guys, you can't expect her to support the world's supply of controller boards unless she has one.)

I always tell my clients, "hey, no problem. when shall I expect that you'll be shipping me one of those?"

That issue on GitHub was multiple printers. I have no problem getting her an Anet A8 mb to test with. And can even flash it with Marlin...

I do this for a living. All these cards are different, no matter what they say. The Duet doesn't like M999 and will drop the connection, the Smoothieboard won't continue past a panic if you don't M999, etc. You just get to the point where it's like "fuggit, ship me the damned board and I'll test it here".

Just as an FYI, Octoprint has the same issue with the Girlfriends Ender3, running 1.1.6 firmware.

Same here. Prior octoprint version autodetected the printer no problem, now 1.4.0 doesn't , but it will connect manually at 250000. Geeetech A10 connected to RPi 3B. Serial.log showing failure ...

2020-03-10 03:35:11,663 - Enabling serial logging
2020-03-10 03:35:34,656 - Changing monitoring state from "Offline" to "Detecting serial port"
2020-03-10 03:35:34,695 - Serial port list: [u'/dev/ttyUSB0', u'/dev/ttyS0']
2020-03-10 03:35:34,696 - Trying /dev/ttyUSB0
2020-03-10 03:35:40,090 - Could not connect to or enter programming mode on /dev/ttyUSB0, might not be a printer or just not allow programming mode
2020-03-10 03:35:40,105 - Trying /dev/ttyS0
2020-03-10 03:35:40,107 - Could not connect to or enter programming mode on /dev/ttyS0, might not be a printer or just not allow programming mode
2020-03-10 03:35:40,112 - Changing monitoring state from "Detecting serial port" to "Error: Failed to autodetect serial port, please set it manually."
2020-03-10 03:35:40,122 - Failed to autodetect serial port, please set it manually.

So the issue seems to stem from the actual autodetect never working to begin with with your printers, and things just working since the only detected serial port was your printer (which would bypass port autodetect). 1.4.0 added a new port pattern to accommodate some setups out there, and that matches something on your system for whatever reason which doesn't present on my machines or that of most of the testers it seems.

Simple solution: configure your printer port manually and save with that instead of AUTO. You should do this anyhow tbh, all this guess work just slows down connecting.

Long term solution: I'll throw out the garbage port detection that never really worked for most people anyhow and adapt what I'm doing for baud rate detection to port detection as well, as already mentioned.

1 Like

Sounds good, thanks. I will configure manually and save settings.

If anyone plugs another smart USB device into their Pi (other than their printer), then I highly recommend creating a udev rule to match their printer board and manually set this alias up in OctoPrint.

Short version: sometimes your printer board and another device fight over /dev/ttyACM0 (or similar) status and OctoPrint could be confused. Setting it manually makes it connect much faster and without so much testing.

Can you or someone else put together a guide on how to do that? I just spend the last few hours trying to figure it out from various guides I found and nothing seemed to work at least for Octopi.

You can't set it manually. When the printer gets powered off it reverts to AUTO when the device isn't detected anymore. When you turn the printer on you have to refresh the connection list and select the port manually ever time.

Have you tried the port lister plugin?

First things first, try the plugin as suggested. I'm sure it's simpler than what I do.

Look for your controller board:

  Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
  Bus 001 Device 005: ID 03eb:8a6e Atmel Corp. 
  Bus 001 Device 004: ID 1d50:6015 OpenMoko, Inc. Smoothieboard <- TARGET
  Bus 001 Device 003: ID f055:9800  
  Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Note the ID information for that. It's 1d50 + 6015 in my case.

Look for an existing udev rule for serial ports:

ls -l /etc/udev/rules.d/99-usb-serial.rules
  -rw-r--r-- 1 root root 309 Mar 12 19:31 /etc/udev/rules.d/99-usb-serial.rules

In my case, I have one and I'll need to edit it. It's also possible that it doesn't exist and could be created. If it doesn't exist then sudo touch /etc/udev/rules.d/99-usb-serial.rules to create an empty one. Next, sudo chmod 644 /etc/udev/rules.d/99-usb-serial.rules so that the rights are correct.

Edit it:

Note how I've plugged in the idVendor and idProduct which we learned earlier. Also note that I'm creating an alias of /dev/smoothieboard for my board. Yours will likely be different so make the necessary adjustments for your setup. Be careful not to use anything as an alias which might already be used so feel free to call it chewbacca or something unique.

sudo nano /etc/udev/rules.d/99-usb-serial.rules
# --- Contents follow, adding this
SUBSYSTEM=="tty", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="6015", SYMLINK+="smoothieboard"
# --- End of contents to add

(Carefully) edit your config.yaml:

Note that yaml files are finicky about whitespace at the beginning of lines.

# Safety first, save the original one
cp ~/.octoprint/config.yaml ~/.octoprint/config.yaml.saveme
nano ~/.octoprint/config.yaml
# --- You need this paragraph; it may be necessary to edit the existing
# --- section, noting that the main headings are alphabetically-sorted.
    - /dev/smoothieboard
    autoconnect: true
    baudrate: 112500
    port: /dev/smoothieboard
# --- End of edits

In my config.yaml the prefixing whitespace is exactly four space characters.

Reboot everything and check to see if it's happier. Keep that copy of your config.yaml.saveme in case bad things happen.

1 Like

Yes, I have had PortLister for about a day now. It refreshes the serial ports list, tries and fails to auto connect, and that is about it.

When I tried this before I didn't set the permissions and didn't edit the yaml file.

It works now however. I can finally walk up to the printer, turn it on, and print something with OctoScreen without fussing with my phone or WebUI. Huge thanks for the guide. I am sure it will come in handy for others that have this issue until it is fixed.

False alarm, I am having more issues now.

On a fresh reboot I can sometimes get it to connect but most times I get an "[Errno 11] Could not exclusively lock port". This is with the PiCam disconnected. Also tested a different USB cable on the other bank of USB ports. Disabled all plugins except PSU Control (I would have to disassemble the printer and re-wire).

I have another Pi. I am going to try to test a fresh installation without the PiCam/PiTFT but at this point I am thinking about just reverting to 1.3

Connecting to: /dev/EZBoard
Connecting to: /dev/EZBoard
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0x69b862f0, open=True>(port='/dev/EZBoard', 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: ok
Send: N0 M110 N0*125
Changing monitoring state from "Connecting" to "Operational"
Recv: ok
Send: N0 M110 N0*125
Recv: ok
Send: N1 M115*39
Recv: Cap:EEPROM:1
Changing monitoring state from "Offline" to "Error: Connection error, see Terminal tab"
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:Z_PROBE:1
Unexpected error while connecting to serial port: /dev/EZBoard SerialException: '[Errno 11] Could not exclusively lock port /dev/EZBoard: [Errno 11] Resource temporarily unavailable' @ comm.py:_openSerial:2691 (hook default)
Recv: ok
Send: M155 S2