Connection timouts while printing (only then)

[StefanM]

When I print, me octoprint stops. Makes nothing more and the printer keeps the heat, but doesnt move anymore. That can happen after some minutes, or after an hour. Very bad if the printer keeps the heat up forever
I have that since around the last 10 prints...

I tried to debug it and did many things...
In short I did:

• exchanges rapsi v3 with raspi v4 incl new SD card.
• newest octopi installed 1 week ago
• 5v in usb cable "isolated" to remove power to printer trough usb (Put tape on the 5V pin - Why and how)
• I did replace the USB cable completly
• switched from usb3 to usb2 at raspi v4
• tried a lot of conenction settings
  • low latency: on, off
  • parity double check : Always, never
  • exclusive access: yes, no

I cant figure out the issue.

I did enable serial logging, and there are some things strange:
2024-02-15 13:19:48,201 - Enabling serial logging
2024-02-26 15:16:16,966 - Changing monitoring state from "Offline" to "Detecting serial connection"
2024-02-26 15:16:17,782 - 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
2024-02-26 15:16:17,782 - Trying port /dev/ttyUSB0, baudrate 115200
2024-02-26 15:16:17,945 - Connecting to port /dev/ttyUSB0, baudrate 115200
2024-02-26 15:16:18,084 - Handshake attempt #1 with timeout 2.0s
2024-02-26 15:16:18,270 - Connected to: Serial<id=0xacb7bd48, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2024-02-26 15:16:18,272 - Send: N0 M110 N0125
2024-02-26 15:16:20,274 - Handshake attempt #2 with timeout 2.0s
2024-02-26 15:16:20,379 - Send: N0 M110 N0125
2024-02-26 15:16:22,394 - Handshake attempt #3 with timeout 2.0s
2024-02-26 15:16:22,429 - Send: N0 M110 N0125
2024-02-26 15:16:24,404 - Trying port /dev/ttyUSB0, baudrate 250000
2024-02-26 15:16:24,434 - Handshake attempt #1 with timeout 2.0s
2024-02-26 15:16:24,475 - Send: N0 M110 N0125
2024-02-26 15:16:26,478 - Handshake attempt #2 with timeout 2.0s
2024-02-26 15:16:26,484 - Send: N0 M110 N0125
2024-02-26 15:16:28,486 - Handshake attempt #3 with timeout 2.0s
2024-02-26 15:16:28,535 - Send: N0 M110 N0125
2024-02-26 15:16:30,532 - Trying port /dev/ttyUSB0, baudrate 230400
2024-02-26 15:16:30,535 - Handshake attempt #1 with timeout 2.0s
2024-02-26 15:16:30,541 - Send: N0 M110 N0125
2024-02-26 15:16:32,543 - Handshake attempt #2 with timeout 2.0s
2024-02-26 15:16:32,553 - Send: N0 M110 N0125

...

2024-02-26 15:16:58,388 - Closing down send loop
2024-02-26 15:16:58,389 - Changing monitoring state from "Detecting serial connection" to "Offline"
2024-02-26 15:17:09,445 - Changing monitoring state from "Offline" to "Detecting serial connection"
2024-02-26 15:17:09,463 - 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
2024-02-26 15:17:09,464 - Trying port /dev/ttyUSB0, baudrate 115200
2024-02-26 15:17:09,466 - Connecting to port /dev/ttyUSB0, baudrate 115200
2024-02-26 15:17:09,558 - Handshake attempt #1 with timeout 2.0s
2024-02-26 15:17:09,571 - Connected to: Serial<id=0xacb7b910, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2024-02-26 15:17:09,573 - Send: N0 M110 N0*125
2024-02-26 15:17:10,594 - Recv: start
2024-02-26 15:17:10,598 - Changing monitoring state from "Detecting serial connection" to "Operational"

As you can see, sometimes it doesnt connect, I need to press manually cacle to disconnect and reconnect. Sometimes it did work directly. Did enable the wait on start, that did fix it, it seams...

But the printing issue is still there:

2024-02-26 15:52:08,079 - Send: N25226 G1 F1950 X106.715 Y39.23 E791.861351
2024-02-26 15:52:08,109 - Recv: ok
2024-02-26 15:52:08,111 - Send: N25227 G0 F9750 X107.103 Y39.409118
2024-02-26 15:52:08,269 - Recv: ok
2024-02-26 15:52:08,271 - Send: N25228 G1 F1950 X108.847 Y37.664 E791.9434148
2024-02-26 15:52:08,317 - Recv: ok
2024-02-26 15:52:08,319 - Send: N25229 G0 F9750 X109.13 Y37.94779
2024-02-26 15:52:08,445 - Recv: ok
2024-02-26 15:52:08,451 - Send: N25230 G1 F1950 X107.448 Y39.629 E792.0225261
2024-02-26 15:52:08,509 - Recv: ok
2024-02-26 15:52:08,511 - Send: N25231 G0 F9750 X107.757 Y39.886125
2024-02-26 15:52:08,637 - Recv: ok
2024-02-26 15:52:08,639 - Send: N25232 G1 F1950 X109.413 Y38.23 E792.100422
2024-02-26 15:52:08,669 - Recv: ok
2024-02-26 15:52:08,670 - Send: N25233 G0 F9750 X109.696 Y38.513125
2024-02-26 15:57:08,695 - Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.
2024-02-26 15:57:08,702 - Send: N25234 M105*37
2024-02-26 15:57:43,354 - Changing monitoring state from "Printing" to "Cancelling"
2024-02-26 15:57:48,165 - Connection closed, closing down monitor
2024-02-26 15:57:57,691 - Changing monitoring state from "Cancelling" to "Offline"

another try:

2024-02-26 16:31:41,719 - Send: N20525 M10539
2024-02-26 16:31:41,727 - Recv: ok T:236.1 /235.0 B:69.7 /70.0 T0:236.1 /235.0 @:39 B@:127
2024-02-26 16:31:41,733 - Send: N20526 G1 X46.363 Y116.183 E631.4162589
2024-02-26 16:31:41,765 - Recv: ok
2024-02-26 16:31:41,767 - Send: N20527 G1 X47.7 Y115.382 E631.4680995
2024-02-26 16:31:41,813 - Recv: ok
2024-02-26 16:31:41,815 - Send: N20528 G1 X49.1 Y114.72 E631.519693
2024-02-26 16:31:41,860 - Recv: ok
2024-02-26 16:31:41,863 - Send: N20529 G1 X50.551 Y114.201 E631.5708586
2024-02-26 16:31:41,909 - Recv: ok
2024-02-26 16:31:41,911 - Send: N20530 G1 X52.061 Y113.823 E631.6226290
2024-02-26 16:31:41,956 - Recv: ok
2024-02-26 16:31:41,958 - Send: N20531 G1 X53.593 Y113.596 E631.6741384
2024-02-26 16:31:42,004 - Recv: ok
2024-02-26 16:31:42,006 - Send: N20532 G1 X55.143 Y113.519 E631.7257590
2024-02-26 15:36:42,035 - Communication timeout while printing, trying to trigger response from printer. Configure long running commands or increase communication timeout if that happens regularly on specific commands or long moves.

I can upload files to the SD Cart of the printer via octoprint. Did it with 7MB. no connection issues over 22 Minutes and no resend.
repeated 8 times. Nearly 3 hours completly uploading, deleting, uploading again. No issue at all with the connection to the printer.

I did yesterday a print directly on the printer, without octoprint. Worked fine.

Then today tried again the same job via octoprint to generate the serial.log.
The printer is running fine. Uload and the connection it seams too.
What is working with the octoprint?

I did a backup of my settings and plugins.

Creality-CR-10s-backup-20240226-170701.zip

The only plugin I cant disable is the PSU control, as that thing is controlling the power to the printer.
Smart preheat is working fine. Dont think thats an issue.

Any settings completly wrong?

[Ewald_Ikemann]

Hello @StefanM !

There was a template. Where is it gone?

It btw asked for the systeminfo bundle. Please attach it to your next post.

Also: For code snippets always use the preformatted text feature of this editor. The result way more easy to read and thing don't get lost.

Sorry, but the backup is of no help here.

[PrintedWeezl]

It's really hard to diagnose this issue. A lot of us know it very well.

Most of the time it's caused by EMI.

Here are some replies I have given in the past to that issue

Printer Disconnects Mid-Print

That's unfortunately a common thing with some Ender 3s. Those printers are prone to EMI. Since you already got a quality usb cable I can only suggest to check for other devices that could emit EMI. That could be for example a microwave, a washing machine or vacuum cleaner. I had also good results with tin foil - wrap the mainboard box in it (but don't cover the fan venting holes)

Printer Stopping Randomly and disconnects from Octoprint

No worries Creality printers are known for having this kind of issue. It's most of the time caused by EMI. EMI can be emitted by a lot of things like fluorescent tubes, ACs, fridges and sometimes even when you sit down on an office chair with a gas cylinder in it. Things you can try: print with and without an sd card inserted into your printer (you don't need to print from the card - we just had some cases where it helped with some weird issues). if you have something nearby that could…

Bad prints with FLYING BEAR Ghost5

I see a lot of transmission errors in your log. You should try another USB cable - preferably a quality one with ferrite beads. Try to keep the cable as short as possible and don't run it next to the stepper motors. Also is there something nearby that could emit EMI (like a fridge, an ac, etc)?

Anycubic predator connection problem

Did the other cable work a bit better? An error at line 23 is pretty early so I guess there is a bigger problem. If it was as bad as the other cable there could be something nearby that emits emi like a microwave, a refrigerator or a fluorescent light.

Do you think something neaby could cause EMI? For example a fridge/freezer, an ac, a vacuum cleaner, fluorescent tubes etc...

[JCT5978]

The most EMI you are going to get is from the processor on the main board. This appears to be a know issue, I would have to say the processor or another part of a circuit is missing a ground. By chance is the mainboard RF shielded??? Have a metal box around it???

-JC

[PrintedWeezl]

It's very unlikely that the MCU causes the issue. It's most likely caused by something external.

In my case it was fluorescent tubes in the same room. As soon as I turned them off the connection timed out.

[JCT5978]

Thank you for the good feedback. Some where on that mainboard someone didn't ground something.

-JC

[StefanM]

Systeminfo attached, sorry: Dropbox - octoprint-systeminfo-20240227094503.zip - Simplify your life

AND yes, the printer has been relocated, beside a freezer. I will wrap the raspi and controlboard to aluminium foil and try again perhaps that will solve it. How freaky
thx thx thx

[PrintedWeezl]

Uhm make sure you don't short anything out

[StefanM]

I didnt short anything out, but when the freezer restarts, the connection crashes. Its that.
I need to move the printer to the other side of the room first.

alufoil thent help, did cover everything of the elektronic etc, but there are a lot of cables ot the printer which I cant "foil".

[b-morgan]

There are two possible sources of interference. One is EMI and the other is plain old power line noise. The first usually requires shielding and the second a different power circuit. If a different power circuit isn't available, a UPS can help.

[JCT5978]

B-Morgan, good point. Older circuits will sometimes have a "Brown out" (voltage lowers on a heavy current draw).
Might want to put a hand on the circuit breaker and make sure it's not getting warm.

-JC

[StefanM]

I have only one powerline there but an USV. I added the printer to the usv and the problem is gone. did print today for 6 hours without any issue. Thanks a lot for your help !