Throwing in my two cents, I'm also having the same problem.
I've had a part in my printer (Ender 3) broken for a while, so I haven't tried using octoprint for a couple of months. Now that I've fixed it, I'm getting the
Offline (Error: No more candidates to test, and no working port/baudrate combination detected.)
error.
I've tried: connecting to a different printer mainboard, using a different usb cable, using a different usb port, rolling back to an earlier version of octoprint, manually re flashing octoprint, using the force-reinstall command via ssh. Attached are my logs (main, and serial communication).
Any help would be super appreciated. I want so desperately to finally have my 3D printer back.
Thanks for your time!
serial.log (1.2 KB) octoprint.log (101.0 KB)
Is there a serial port listed that would allow you to manually set the port and baudrate?
Hi Jneilliii,
I can manually set the buad rate (although no baud rate succeeded when I tried setting them manually) but only "auto" appears under Serial Port.
Thanks for your help!
So that means octoprint is not aware of the serial port that your printer is connected on. This may mean it needs to be manually added in the additional serial ports option in order to be recognized. If you SSH to your pi and run the command dmesg | grep tty what is returned?
This thread may also be helpful, and the connection may also be listed with dmesg | grep usb.
Here's what I get with dmesg | grep tty.
Not sure how to interpret those results.
And once again, thanks for your help, it's very much appreciated!
ok ttyAMA0 is the bluetooth chip if I'm not mistaken, so the pi doesn't see the printer at all. this could be a bad USB cable, bad power supply, or possible linux corruption. I'd try the manual reinstall just to see if that makes any difference.
Edit: there's been reports of electrical interference from motors and power cables too.
So I've tried manually reflashing a clean octopi to my raspberry pi's SD card, as well as doing the force-reinstall command. Is there another thing I should try reinstalling/another way to do it? Likewise, I run a small business that includes a mini usb cable with every order, so I've got tons of them lying around, and none seem to work, so that's the one thing I'm pretty confident it shouldn't be. For the power supply issue, the printer powers up and can be used via its monitor, and on the pi end I can connect to the webinterface, just not the printer. Could it still be the powersupply? Genuine question.
I'll try moving it seperate from everything else, but at the moment it's in its own area for from my computer, which is why octoprint is pretty important to me.
Also here's the dmesg | grep usb result.
Worth pointing out that it's connected to wifi via a usb adapter, and I've tried switching the usb cable to the port that the wifi adapter was on, and it still didn't work.
I meant the power supply to the pi, not the printer. If you're not using a true power supply and are using a phone charger wallwart, or ipad charger plug, etc. can cause weird issues.
Yeah, I don't think any of those USB options are relevant.
Sorry, I don't know why I assumed the details of my personal setup would be known to others. Both my printer and pi are powered by my printers PSU, in the case of the pi stepped down to 5vs via a buck converter. Maybe I accidentally hit the buck converters dial and it's not getting the proper voltage now? Could that be it? I can break out the multimeter tomorrow and find out.
I wouldn't naturally think that to be the issue assuming you weren't getting under voltage warnings prior to upgrade. The issue is definitely the pi not seeing the printer though for whatever reason.
Ah this is frustrating. I've literally replaced the usb cables and the printer mainboard itself, and it's still not working, and like I said, the usb wifi dongle works, so the usb ports should work.
I'm truly at a loss.
Thanks for all your help though. My next step might be trying to replace the pi. It wouldn't be my favorite option, since all my other pis are in use with other projects, but if I can't think of something else...
Hello,
I have two ideas for testing:
-
try to disable bluetooth on your raspi - for example follow this instruction: https://scribles.net/disabling-bluetooth-on-raspberry-pi/
-
does your printers USB-Port is working? Can you connect your printer directly to a computer and does it there appear as a Com-Port and works for example with cura or something else?
Best regards,
Sebastian
Ok so I have the good fortune of having a number of setups I can test at once (I have my orignal ender 3, the replacement skr mini board I got for that ender 3, and a broken (no-hot end) ender 3 I recently got on craigslist.) I tried connecting each of them to my computer and got different results for each. My original ender 3 board didn't show up at all in device manager, the SKR mini showed up as an unknown device, and the craigslist ender 3 showed up as its usb controller (CH340). None of them however, showed up in cura (I think? It's been a while since I tried printing directly via cura so maybe I messed something up there).
I disabled bluetooth as well and didn't see any change in behavior.
Thanks for your help+time
Just adding my 2 cents to this thread as I was also having the same issue, but may have just solved it.
Here's my experience.
Everything was working flawlessly before the update and now nothing. At one point I was having an issue but it resolved when I used a modified cable without the power feed. I only had 2 plugins installed and wasn't even using them yet. Enclosure plugin and The spaghetti detective.
I disabled plugins, rebooted in safe mode and tried plenty of different things and tests but to no avail. Still got the same no more candidates to test error. I even forced a reinstall of octoprint and everything else mentioned in this thread but to no avail
So I put it away for a couple days and decided to try a fresh start tonight and log my steps.YMMV
I'm using a pi model B revision 2. I have a usb webcam plugged in.
Here's my method:
Downloaded latest octopi image and wrote it to a fresh card using rufus.
The version is 0.17.0
Plugged in printer, rebuilt my serial cable to reconnect the power feed wire. I fired everything up immediately ssh into the pi and ran a dmesg and lsusb. Here is the output
pi@octopi:~ $ dmesg | grep tty
[ 0.000000] Kernel command line: coherent_pool=1M bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 console=ttyAMA0,115200 console=tty1 root=PARTUUID=6c586e13-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.001262] console [tty1] enabled
[ 1.041583] 20201000.serial: ttyAMA0 at MMIO 0x20201000 (irq = 81, base_baud = 0) is a PL011 rev2
[ 1.936643] console [ttyAMA0] enabled
[ 17.906948] usb 1-1.2: ch341-uart converter now attached to ttyUSB0
pi@octopi:~ $ lsusb
Bus 001 Device 005: ID 0ac8:303b Z-Star Microelectronics Corp. ZC0303 Webcam
Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9512 Standard Microsystems Corp. SMC9512/9514 USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubI loaded octoprint and ran through the startup wizard. After setup it immediately connected to my printer, I was able to control the motors and view the camera. I did not touch any settings or change anything except to enable serial logging. I did not attempt to print anything. .I did not physically touch or go near the printer at all.
I then proceeded to click to update from 1.3.12 to 1.4.2. It upgraded fine, I reloaded the page and the connect button remained greyed out, could not click it to even attempt a connection. I opened up my ssh window and rebooted the pi.
Upon reboot I again ran dmesg and lsusb with identical results. I compared them word for word
Opened a new browser and loaded octoprint. Would not connect.
I get the same error.
Here's the serial log
2020-09-06 07:15:14,219 - Changing monitoring state from "Offline" to "Detecting serial connection"
2020-09-06 07:15:14,673 - Performing autodetection with 7 port/baudrate candidates: /dev/ttyUSB0@115200, /dev/ttyUSB0@250000, /dev/ttyUSB0@230400, /dev/ttyUSB0@57600, /dev/ttyUSB0@38400, /dev/ttyUSB0@19200, /dev/ttyUSB0@9600
2020-09-06 07:15:14,700 - Trying port /dev/ttyUSB0, baudrate 115200
2020-09-06 07:15:14,767 - Connecting to port /dev/ttyUSB0, baudrate 115200
2020-09-06 07:15:14,827 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:14,891 - Connected to: Serial<id=0xaf7a3250, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2020-09-06 07:15:14,946 - Send: N0 M110 N0*125
2020-09-06 07:15:16,975 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:17,112 - Send: N0 M110 N0*125
2020-09-06 07:15:19,091 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:19,177 - Send: N0 M110 N0*125
2020-09-06 07:15:21,163 - Trying port /dev/ttyUSB0, baudrate 250000
2020-09-06 07:15:21,212 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:21,283 - Send: N0 M110 N0*125
2020-09-06 07:15:23,281 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:23,355 - Send: N0 M110 N0*125
2020-09-06 07:15:25,359 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:25,446 - Send: N0 M110 N0*125
2020-09-06 07:15:27,425 - Trying port /dev/ttyUSB0, baudrate 230400
2020-09-06 07:15:27,458 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:27,544 - Send: N0 M110 N0*125
2020-09-06 07:15:29,530 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:29,592 - Send: N0 M110 N0*125
2020-09-06 07:15:31,590 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:31,683 - Send: N0 M110 N0*125
2020-09-06 07:15:33,664 - Trying port /dev/ttyUSB0, baudrate 57600
2020-09-06 07:15:33,707 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:33,779 - Send: N0 M110 N0*125
2020-09-06 07:15:35,781 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:35,870 - Send: N0 M110 N0*125
2020-09-06 07:15:37,860 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:37,925 - Send: N0 M110 N0*125
2020-09-06 07:15:39,921 - Trying port /dev/ttyUSB0, baudrate 38400
2020-09-06 07:15:39,962 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:40,037 - Send: N0 M110 N0*125
2020-09-06 07:15:42,040 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:42,112 - Send: N0 M110 N0*125
2020-09-06 07:15:44,110 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:44,197 - Send: N0 M110 N0*125
2020-09-06 07:15:46,193 - Trying port /dev/ttyUSB0, baudrate 19200
2020-09-06 07:15:46,248 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:46,337 - Send: N0 M110 N0*125
2020-09-06 07:15:48,336 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:48,424 - Send: N0 M110 N0*125
2020-09-06 07:15:50,415 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:50,506 - Send: N0 M110 N0*125
2020-09-06 07:15:52,498 - Trying port /dev/ttyUSB0, baudrate 9600
2020-09-06 07:15:52,540 - Handshake attempt #1 with timeout 2.0s
2020-09-06 07:15:52,605 - Send: N0 M110 N0*125
2020-09-06 07:15:54,611 - Handshake attempt #2 with timeout 2.0s
2020-09-06 07:15:54,677 - Send: N0 M110 N0*125
2020-09-06 07:15:56,711 - Handshake attempt #3 with timeout 2.0s
2020-09-06 07:15:56,854 - Send: N0 M110 N0*125
2020-09-06 07:15:58,872 - Changing monitoring state from "Detecting serial connection" to "Error: No more candidates to test, and no working port/baudrate combination detected."
2020-09-06 07:15:58,967 - Changing monitoring state from "Error: No more candidates to test, and no working port/baudrate combination detected." to "Offline (Error: No more candidates to test, and no working port/baudrate combination detected.)"
2020-09-06 07:15:59,033 - Connection closed, closing down monitorI went into settings and moved the connection timeout and autodetection timeout to 45s. Also moved consecutive handshake attempts up to 30s
Tried again and it connected to the printer within maybe 10 seconds.
It appears to respond to commands now and I've just sent it a succesfull print.
So for what its worth I appear to have fixed me issue. Hope this helps somebody
Same problem here, with my old version of Marlin Bug Fix 2.0.x (from 2019) everything is working flawlessly on Octoprint 1.4.2
Today I decided to update to a fresh Marlin Bug Fix 2.0.x but I started getting the same problem.
State: Error: No more candidates to test, and no working port/baudrate combination detected.
I tried downgrading to OctoPrint 1.4.1 and still the same problem.
Flashing my old firmware again and it's working without any problem.
Note that my BIGTREETECH TFT35 E3 V3.0 is detecting the printer and working in any of this situations.
Please, read the topic. This is about an update to OctoPrint that caused these users problems, whereas you have said that:
The title of the post is
Cannot connect printer after 1.4.2
1.4.2 is an OctoPrint update
Your issue is quite clearly a firmware problem, in no way an OctoPrint problem since you have confirmed it works with your old firmware.
Not solved for me unfortunately. After my previous post, next morning couldn't load camera feed.
I still ran a few successfull prints.
Rebooted the pi.
Ran a few more prints and now this morning getting the connection error again. Haven't messed with anything since last night. Everything is still powered up.
I rebotted the pi again and opened up the terminal and the printer is no longer listed when I command lsusb
I played with a combination of rebooting and unplugging and now it is showing again. Weird.
I ran for weeks with no issues under 1.3.12 with multiple reboots and power cycles and plugging and unplugging things from the pi with no issues at all. and now under 1.4.2 it seems very sensitive to every little movement and power cycle.
I don't know how many changelogs there are between 1.3.12 and 1.4.2 but something in between those two landmarks is making this very finicky.
I'm suspecting this may be a power issue. I'm going to remodify my serial cable to eliminate the power feed wire again later today to see if it becomes less obnoxious.
I'm sure when I break it again I'll add some more insight