Cannot connect printer after 1.4.2

Get Help
40

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

41

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 hub

I 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 monitor

I 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

42

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.

Captura de pantalla 2020-09-06 a las 21.42.56
Captura de pantalla 2020-09-06 a las 21.42.56634×1434 82.2 KB

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.

43

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
44

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

45

Are you running a newer creality printer? The reason I ask is because others have reported weird connection issues, as mentioned here.

46

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.)"

47

@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.

48

i had the same problem but solved it by exchanging the original pi adapter to a chinese wall adapter. weird but true...:frowning:

49

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.

50

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)

51

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.

52

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"

53

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)

54

Damn Creality firmware...

55

Is this something that can be address with an upgrade to the firmware to the printer?

56

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)

57

Because according to the serial.log, OctoPrint is now actually getting something back from the printer:

Recv: 0
Recv: ok
Send: M105
Recv: ok T:21.05 /0.00 B:20.98 /0.00 @:0 B@:0
Send: M155 S2
Recv: ok

Considering that this is OctoPrint 1.4.2 again, whatever the issue was was either with your OS image, or maybe while flashing you wiggled something in the vicinity of cabling that made it work again. I cannot really tell you, only speculate. What I CAN tell you is that contrary to your past report OctoPrint now gets parseable responses back from the printer. That firmware still seems to have issues considering that broken M115 response, so you should probably consider flashing a mainline Marlin build instead of using this broken version. Sadly there are a whole host of issues with various vendor firmwares, and Creality is currently leading the effort in driving me nuts with non standard communication.

58

So there is one curiosity in the logs, There are several commands that get sent during the handshake such as M115 and M21. The printer seems to ack those, however on the handshakes that don't work I don't see the extra commands. Also by hand sending(I am using cutecom) the serial commands the communications works, IF is send any command after I get the "init valid". I do need to send a command twice IF the "init valid" doesn't have a LF. But get "ok"s back each time. It would appear that my firmware needs a little bit of time after the serial connection is opened prior to receiving commands. Is there any setting that would delay the handshake?

60

So I don't know if this is the appropriate thread, since it is unclear if this is a hardware issue or a software.

I upgraded to 1.1.9 and am still having difficulties connecting to the printer. I believe I have narrowed some of the difficulty down to the "auto" setting for serial port. Or rather the lack there of

When I set the serial port to auto I can consistently connect. (After the first connection that is changed to say ttyUSB1) If I disconnect and reconnect it fails. If I then set the serial port back to auto it succeeds.

here is the serial log for this.
serial (2).log (6.8 KB)

Again if there is a better thread for this since it is not apparent if this is a 1.4.2 bug or some other ender 3 specific issue, let me know and I will move the conversation there.

PS additionally I have had the communication difficulties when printing. I believe I have narrowed it down to the temperature monitoring during heat up but am still investigating which command is hanging. I didn't have serial logging on when this error occurred so I am trying to repro it.