Connect only works on 2nd attempt

What is the problem?

Hello all,

I tried searching, but the other connection issues usually talked about not connecting at all or loosing connection during prints. If I missed it anyway, I'm sorry.

I've been using Octoprint now for some months and everything is working fine during prints. I just have this interesting effect that I almost always have to press connect twice. After that it's working really nice, it's really just that, but I'd still like to figure out, what the reason is.

What did you already try to solve it?

I have a USB cable, where I cut the power cable myself and I tried others, so that doesn't seam to be problem. I have an original RasperryPi power supply, so that's also not it. I've attached the SystemBundle and the log which shows connection attempt 1 and 2. If there is any other information that would help figure out this issue, please let me know.

connection.log (4.3 KB)

Have you tried running in safe mode?

yes

Did running in safe mode solve the problem?

no

System info Bundle

Systeminfo bundle (37.6 KB)

Additional information about your setup

OctoPrint version 1.6.1, OctoPi version 0.18.0 on RPi4, Ender 3 V2, Jyers Marlin latest, Chrome, Mac / Windows

Hello @bjoern.busch !

For you have a Creality printer, try with/without a SD card in the printer.

Also have a look on this:

Thanks for the hints. I always have the SD card in, so I tried it without the SD card (turn printer off, remove SD card, turn on, wait a couple seconds, try to connect in Octoprint), but that showed the same result of having to press connect twice.

About the 5V pin, I physically opened the cable and cut the 5V cable (vasectomy style), since I found it difficult to get the connector in with the tape method and I think that makes no difference, since trying another cable (which still has the 5V cable intact) shows the same behaviour.

You found other wires that the red and black one in the cable?

Yes, there were 4 wires, red, black, white and green and I cut out about 2 cm of the red wire.

I tried to play with the different connection settings now:

I increased the timeouts for:

Communication timeout
Connection timeout
Autodetection timeout
Initial baudrate detection pause
Max. consecutive timeouts while idle

I enabled Wait for start on connect

Is there a way to increase the number of handshake attempts? I still see only 3 attempts in the log.

I also enabled serial.log, but I see no further details than that it tries to connect 5 times...

2021-10-16 16:56:31,450 - Enabling serial logging
2021-10-16 16:56:40,601 - Changing monitoring state from "Offline" to "Detecting serial connection"
2021-10-16 16:56:40,635 - Performing autodetection with 1 port/baudrate candidates: /dev/ttyUSB0@250000
2021-10-16 16:56:40,635 - Trying port /dev/ttyUSB0, baudrate 250000
2021-10-16 16:56:40,693 - Handshake attempt #1 with timeout 10.0s
2021-10-16 16:56:40,694 - Connected to: PackingSerial<id=0xa6771950, open=True>(port='/dev/ttyUSB0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2021-10-16 16:56:40,698 - Send: N0 M110 N0*125
2021-10-16 16:56:40,819 - Handshake attempt #2 with timeout 10.0s
2021-10-16 16:56:40,827 - Send: N0 M110 N0*125
2021-10-16 16:56:40,924 - Handshake attempt #3 with timeout 10.0s
2021-10-16 16:56:40,929 - Send: N0 M110 N0*125
2021-10-16 16:56:40,933 - Changing monitoring state from "Detecting serial connection" to "Error"
2021-10-16 16:56:40,954 - Changing monitoring state from "Error" to "Offline after error"
2021-10-16 16:56:40,968 - Connection closed, closing down monitor
2021-10-16 16:56:44,230 - Changing monitoring state from "Offline" to "Detecting serial connection"
2021-10-16 16:56:44,262 - Performing autodetection with 1 port/baudrate candidates: /dev/ttyUSB0@250000
2021-10-16 16:56:44,262 - Trying port /dev/ttyUSB0, baudrate 250000
2021-10-16 16:56:44,325 - Handshake attempt #1 with timeout 10.0s
2021-10-16 16:56:44,326 - Connected to: PackingSerial<id=0xa6771950, open=True>(port='/dev/ttyUSB0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2021-10-16 16:56:44,339 - Send: N0 M110 N0*125
2021-10-16 16:56:44,488 - Handshake attempt #2 with timeout 10.0s
2021-10-16 16:56:44,500 - Send: N0 M110 N0*125
2021-10-16 16:56:44,501 - Recv: ok
2021-10-16 16:56:44,534 - Changing monitoring state from "Detecting serial connection" to "Operational"
2021-10-16 16:56:44,586 - Send: N0 M110 N0*125
2021-10-16 16:56:44,620 - Recv: ok

Have you cheked if the printer connects to another device, like a PC with pronterface?

When it works on the second click and everything else works fine then it's probably not the cable, not the SD card, not the power supply. Could it be anything about the way you click? sorry if that sounds silly, I just wondered how to bring a new angle to the search.

Well, if it was me with that effect I'd try to trigger the connect in a different way, just to see if it makes a difference. Via bash, the API. You'll have to generate an API key and set the variables for that tiny bash script (or simply edit the values into the place of the variables) set the script to executable with a
chmod 755 scriptname - and try it.

# connect octoPrint and the printer 
curl -s -X POST  -H "Content-Type: application/json" -H "X-Api-Key":"$OCTOPRINT_X_API_KEY" -d '{"command":"connect"}' http://$PRINT_HOST/api/connection

Maybe it doesn't help at all, I don't know.

For the record, I remember there was an issue with some specific Malyan/Monoprice printers that required a double connect workaround for connections to work reliably that got then turned into a plugin:

You could try if this helps, but be advised that is really just a shot in the dark based on the observed symptom of the issue.

I tried using Pronterface, but I couldn't get it to connect, but that's probably due to the fact that I have never used it before and probably have some settings wrong. Maybe I'll spend some time on that in the future.

For the "how to click", I tried different browsers, different OS's and also from the mobile app and I have the same behaviour from all platforms, so I hope that this is ruled out. Thanks for the bash advice, I might also try this.

For now, thanks @foosel for the plugin, this also seams to solve my issue. I guess for now I can conclude that it's a FW issue and not something in Octoprint, so I'll keep my eyes open for updates on my FW and maybe I'll raise an issue there.

Thanks everybody!

1 Like