Disconnect as soon as CTRL Move

Get Help Electronics
1

I read so many similar issues, serial exceptions, disconnects.
I tried everything; I thought I could solve this by just reading and trying different approaches by myself, but I'm really in a dead end now.

A little bit of background:

  • The printer works fine without Octoprint, with the stock display, stock motherboard and stock firmware.
  • The connection to the Raspberry Pi 4 B is always working, be it through SSH or the Web-Interface to OctiPrint, or the attached camera via webcamd http.

Obviously, I really crave for having a setup, that permanently works with OctoPrint, to get rid of the stock TouchScreen and have my Raspberry Pi 4B run OctoDash or a different GUI on that nice Touchscreen-Case I got.
Setting up OctoPrint first, the whole setup ran fine for at least 2 Weeks, no issues at all.
One day I started to get disconnects, rarely, sometimes in the middle of a print, sometimes during pre-heat or starting the print.
The issues became more and more frequent until the state today, where I can't even ControlPanel->Move Z Axis 10mm without the connection breaking down. After the breakdown, I have to switch off the printer power and reboot entirely, only then it will accept a connection again.
In idle, the printer will successfully report temperatures, not hang up. I can run this for hours without a disconnect. As soon as there are movement commands, it breaks down. It still executes that first 10mm Z-Axis move before it's gone.

I've read numerous sources reporting the Creality stock motherboard to be a real piece of work, sometimes throwing sparks, going up in flames amongst other problems. So I thought, that maybe my Motherboard is already fried. I ordered a new BTT CR6-SE V1.0 replacement board, only to find out that the same issues are also present on this motherboard.
The BTT Motherboard seems to be running an older Firmware than the new one Creality ships, I'm getting the double-temperature report bug now, which was easily fixed with the OctoPrint plugin.

It feels like the serial connection is choking, sometimes after "hang-up on move command" I pull out the USB and suddenly it executes the move.

The attached logs document a successful connect (taped +5VDC variant), have some idle temperature reports from the printer, then hitting Control Panel -> Z-Axis 10mm down to provoke the disconnect.

What is the problem?
Serial connection dead after Moving the print head

What did you already try to solve it?

  • taped USB +5VDC
  • changed motherboard from stock to BTT CR6-SE V1.0
  • exchanged USB cable on each motherboard to at least 7 different cables, one with manually soldered 3 of 4 leads without +5VDC
  • ran octoprint in Safe Mode
  • now running without OctoDash for debugging
  • ran Raspi with different PowerSupplies: usually built-in from the touchscreen case, original brand 5.1 VDC, others
  • ran Raspi naked on a rubber mat without the screen

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, what kind of hardware precisely, ...)
Linux octopi 5.10.17-v7l+
Raspberry Pi 4B (temperature taken care of, passive coolers on the chips, noctua fan keeping it smoothly at 49° Celsius)
OctoPrint Version 1.6.1
Creality CR6 SE, stock and BTT CR6-SE V1.0 Motherboard
Current firmware BIGTREETECH-SKR-CR6 (original touch-screen)

octoprint.log
octoprint.log (1.1 KB)

serial.log
serial.log (5.5 KB)

dmesg
dmesg.log (1.1 KB)

2

Hello @hzzmj !

This is a bit curious:

The head should lower 10mm?
Most printers do not move the head without homing first.
And assuming it does: if the head is 5mm above the print bed, this commands would crash the head into the bed.

For you are running OctoPrint 1.6.1, please share the systeminfo bundle file. Please no log excerpts. Please also enable the serial logging before. When it comes to communication issues with the printer, the serial.log is essential.

3

Hi @Ewald_Ikemann !
Serial.log is enabled.

systeminfo bundle:
octoprint-systeminfo-20210613185820.zip (21.3 KB)

I now pressed X/Y-Homing as the first order of business after fresh connect, which resulted in this:
serial-discoOnXYHoming.log (4.6 KB)

There they are again, these weird "trashy" lines with seemingly random content thrown into the connection.

(btw, I booted the printer with the head ~100mm over the bed, resulting from previous debugging disconnection attemps where I moved +10mm each time)

4

That's a huge mess in the serial.log

When I saw that, this came to my mind:

2 Likes
5

Holy cow.
After reading that post I jumped and immediately did two things:

  • clip, disconnect and remove altogether from the case the cable for the original touch-display, which I just had cable-manage tied to the casing in the last half of the flooring
  • remove this cable drag chain addon I printed, because I knew it pinches one of the flatband cables to the top steppers & printhead quite hard

since that, the printer seems to be working completely fine again.

Thank you so much @Ewald_Ikemann !

2 Likes
6

This one is almost definitely the issue here - since the issue starts as soon as the motors engage, which would create some electrical noise that is doing the disruption here. The LCD is also an EMI issue, but that would not change when the motors started up I don't think. Maybe it contributes a little.