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.
2 Likes
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
Are you running a newer creality printer? The reason I ask is because others have reported weird connection issues, as mentioned here.
Hello,
updated today to 1.4.2 after having a break from printing for about 2 months.
Did one print on the older octopi then updated. After the update it wont connect anymore...
The log looks similar to others posted already here:
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.)"
Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 0 port/baudrate candidates:
Changing monitoring state from "Detecting serial connection" to "Error: No more candidates to test, and no working port/baudrate combination detected."
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.)"
@eaZy, It is said that "misery loves company" but in this case, the contribution of additional detailed information would be most helpful. As is shown above every reply in this topic...
Need help? Read this first! Remember to provide version numbers, relevant log files and general information about your setup. WE NEED LOGS TO HELP YOU!
Most important would be your printer make and model, controller board make and model (if not original), and the firmware revision.
i had the same problem but solved it by exchanging the original pi adapter to a chinese wall adapter. weird but true...
Hello,
I am working with an Ubuntu Linux (18.04.5) NUC running Octoprint and have had this problem for some time. But I have managed to solve this problem by a lot of trial and error (change USB port, restart NUC). If the connection was there once, it worked too.
Had problems again today. When I plug in the USB cable from the printer, nothing appears in the syslog. So I changed the USB cable to the printer and it worked right away.
So I would recommend those with problems to try a different USB cable.
I am having the same problem, I am on a tinker board and everything was working fine. Upgraded to 1.4.2 (along with the psu control plugin) and I couldn't connect to the printer. Then it was sort of working. The only noticeable thing I did was change which USB port I was plugged into. Exchanged the mouse with the printer and it started to connect.
I was still getting the occasional "There was a timeout while trying to connect to the printer". Which was a problem because during the print head will pause for about a second (leaving a small blob)and then pick back up. I first thought that maybe this was in the slicer but I printed the same model via sd card and it works as expected.
Thinking everything was working, I cleared the logs and disconnected. I restarted octoprint and attempted to connect. Same problem has started again. Rebooted the system this time and was able to connect.
octoprint (1).log (35.3 KB) serial (3).log (3.9 KB)
Your serial.log looks like there is some excessive data corruption going on on the serial line:
2020-09-22 13:32:35,131 - Recv: ececho:TF card ok
...
2020-09-22 13:33:05,231 - Recv: init validFIRMWARE_NAME:Marlin Creality 3D SOURCE_CODE_URL:https://github.48-9b12-c55c62f367ff
...
2020-09-22 13:33:35,331 - Recv: Cap:PROGecho:TF card ok
No wonder there are timeouts, OctoPrint is receiving garbage from this printer, and not a single ok in sight to its attempts to handshake via M110.
I noticed that. I just made a change to the Firmware& Protocol, selecting "Wait for start on connect", and reconnected. (it worked) then I disconnected and attempted to reconnected (didn't work)
I got this serial output
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyUSB0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0xaab5b290, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Recv: start
Recv: echo: External Reset
Send: N0 M110 N0125
Recv: Marlin 1.1.6.1
Recv:
Recv: echo: Last Updated: 2echo:TF card ok
Recv: Init power off infomation.
Recv: size:
Recv: 585
Recv: init valid:
Recv: 0
Recv: 0
Recv: ok
Changing monitoring state from "Connecting" to "Operational"
Send: N0 M110 N0125
Recv: ok
Send: N1 M11539
Recv: FIRMWARE_NAME:Marlin Creality 3D SOURCE_CODE_URL:https://github.COL_VERSION:1.0 MACHINE_TYPE:Ender-3 EXTRUDER_COUNT:1 UUID:cede2p:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
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: M21
Recv: Cap:EMERGENCY_PARSecho:TF card ok
Recv: Init power off infomation.
Recv: size:
Recv: 585
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: M105
Recv: init validok T:22.70 /0.00 B:23.01 /0.00 @:0 B@:0
Connection closed, closing down monitor
Changing monitoring state from "Operational" to "Offline"
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyUSB0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0xaa37b990, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Recv: start
Recv: echo:Marlin 1.1.6.1
Send: N0 M110 N0125
Recv:
Recv: echo:start
Recv: echo: External Reset
Recv: Marlin 1.1.6.1
Recv:
Recv: echo: Last Updated: 2018-11-28 | Author: (Ender-3)
Recv: ececho:TF card ok
Recv: Init power off infomation.
Recv: size:
Recv: 585
Connection closed, closing down monitor
Changing monitoring state from "Connecting" to "Offline"
I used cutecom to open a terminal and check what is actually coming across the line.
I consistently see that the termain has init valid but without a LF. If is send the M110 N0 command twice after I have received that it seems to clean up the communication (at least on cutecom)
Damn Creality firmware...
Is this something that can be address with an upgrade to the firmware to the printer?
So I got frustrated and flashed the OS and reinstalled. I connected up the first time so I am including the logs. I did notice that there were no "ok"''s in the same area of the handshake. Why would the octoprint connect now and not before?
octoprint.log (61.9 KB) serial.log (1.9 KB)