Cannot connect printer after 1.4.2

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...:frowning:

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 N0
125
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 N0
125
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)

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.

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?

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.

I'm still seeing a lot of garbled communication even in the handshake. Something is up either with your USB cable or the controller itself if this persists even across firmware flashes.

Just for comparison, this is what's going over serial should look like when connecting:

Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyACM0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0x72810430, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
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: FIRMWARE_NAME:Marlin 2.0.5.4 (GitHub) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ender-3-Pro EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
Recv: Cap:SERIAL_XON_XOFF:0
Recv: Cap:BINARY_FILE_TRANSFER:0
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRESS:0
Recv: Cap:PRINT_JOB:1
Recv: Cap:AUTOLEVEL:1
Recv: Cap:Z_PROBE:1
Recv: Cap:LEVELING_DATA:1
Recv: Cap:BUILD_PERCENT:0
Recv: Cap:SOFTWARE_POWER:0
Recv: Cap:TOGGLE_LIGHTS:0
Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
Recv: Cap:EMERGENCY_PARSER:0
Recv: Cap:PROMPT_SUPPORT:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
Recv: Cap:MOTION_MODES:0
Recv: Cap:CHAMBER_TEMPERATURE:0
Recv: ok
Send: M21
Recv: echo:SD card ok
Recv: ok
Send: M155 S2
Recv: ok
Send: M20
Recv: Begin file list
Recv: SKR-MI~1.GCO 176
Recv: End file list
Recv: ok
Recv:  T:22.19 /0.00 B:23.44 /0.00 @:0 B@:0
Recv:  T:22.81 /0.00 B:21.87 /0.00 @:0 B@:0

Your serial.log on the other hand has once again weirdly merged many of these lines, not even with missing EOFs but overwrites in the middle. And comparing two connect attempts it also looks like only a subset of lines is event being transmitted each time that varies. Something's broken here:

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=0xaf131ed0, 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.9.1
Recv: 
Send: N0 M110 N0*125
Recv: echo:start                                            <-- printer boots twice?!
Recv: echo:Marlin 1.1.9.1
Recv: 
Recv: echo: Last Updated: 2020-06-20 | Auths: 1232          <-- garbled
Recv: echo:V56 stored settings retrieves; crc 51462)        <-- garbled
Recv: echo:  G21    ; (mm)
Recv: echo:  M149 C ; Units in Cel
Recv: echo:  M203 X500.00 Y500.00 Z10.00 E50.00
Recv: echo:Maximum Acceleraanced: Q<min_segment_time_us> S<min_feedrate> T<min_travel_feedr:Material heatup parameters:
                                                            ^-- garbled
Recv: echo:  M145 S0 H185 B45 F255
Recv: echo: echo:SD init fail
There was a timeout while trying to connect to the printer  <-- OctoPrint gives up since no ok was ever received
Changing monitoring state from "Offline" to "Detecting serial connection"
Performing autodetection with 6 port/baudrate candidates: /dev/ttyUSB0@115200, /dev/ttyS4@115200, /dev/ttyS3@115200, /dev/ttyS1@115200, /dev/ttyS0@115200, /dev/ttyS2@115200
Trying port /dev/ttyUSB0, baudrate 115200
Connecting to port /dev/ttyUSB0, baudrate 115200
Handshake attempt #1 with timeout 2.0s
Connected to: Serial<id=0xa50b0230, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0*125
Recv: start
Changing monitoring state from "Detecting serial connection" to "Operational"
Recv: echo:Marlin 1.1.9.1
Recv: 
Send: N0 M110 N0*125
Recv: echo:start                                            <-- printer boots twice?!
Recv: echo:Marlin 1.1.9.1
Recv: 
Recv: echo: Last Updated: 2020-06-20 | Author: (thisiskeithb, Ender-3)
Recv: echoecho:V56 stored settings retrieved (656 bytes; crc 51462)
                                                            ^-- garbled
Recv: echo: echo:  M200 D0                                  <-- garbled
Recv: echo:Steps per unit:
Recv: echo:  M92 X80.00 Y80.00 Z40ration (units/s2): P<print_accel> R<retract_accel> T<travel_acce
                                                            ^-- garbled
Recv: echo:  M205 Q20000 S0.00 T0.00 X20.00 Y20.00 Z0.30 E5.00
Recv: echo:H1.54 D76.55
Recv: echo:SD init fail
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: N1 M115*39
Recv: FIRMWARE_NAME:Marlin 1.1.9.1 (Github) SOURCE_CODE_URL:https://gi:0
                                                            ^-- garbled
Recv: Cap:EEPROM:1
Recv: Cap:VOLUMETRIC:1
Recv: Cap:AUTOREPORT_TEMP:1
Recv: Cap:PROGRCY_PARSER:0
Recv: Cap:AUTOREPORT_SD_STATUS:0
Recv: Cap:THERMAL_PROTECTION:1
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.
                                                            ^-- no ok from M115
Send: M21
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.
                                                            ^-- M21 takes WAY too long, eject printer's SD?
Send: M105
Recv: echo:SD init fail                                     <-- M21 fails, printer's SD either not there or broken
Recv: ok
Send: M155 S2
Recv: ok T:24.02 /0.00 B:25.00 /0.00 @:0 B@:0

One thing I noticed is that the M21 command ("init SD") seems to take very long. If you have an SD card in your printer, try ejecting it. If not, try putting one in (DOS formatted, known to be good and not faulty). We've had weird printer controller freakouts due to wonky SD cards before here.

Hello b-morgan,

in the evening when i had time again to work on this and check back on my post i could not manage to read any more data from the SD Card...

2 days ago i could spend another hour... checked the SD Card for corrupted sectors and so on before formatting - looked good. Close to a new card...

Then i tryed if it is any hardware issue. Took my old image, used etcher, Set octoprint up again and printed the last 2 nights sucessfully ...
I fear, i cant provide any logs anymore....

My machine is an stock Ender 3 with Marlin fw flashed to it. It is the v1.8.7 TH3D Firmware.