Yet another "Printer Disconnects Mid-Print" post

[Deses]

What is the problem?

My printer is stopping all my test prints approximately at the same height.

My printer is in the middle of a rebuild and all the cables are lying around, I've even terminated some new ones (like the 3DTouch to remove the Dupont connectors and use proper JST-XH) and made extensions (Z stepper and Y endstop).

This is how the insanity is looking like:

I also compiled a new bugfix-2.1.x Marlin to update my 4 year old firmware. Board is a SKR Mini E3 v1.2.

What did you already try to solve it?

• I tried moving all the cables in a way that they don't cross with the USB cable.
• I tried several USB cables.
• I even dug out an OLD cable from a portable HDD that had a ferrite core.
• Tried with and without my shoddy "USB filter" that only has D+ D- wired. (it's the blue box between the Pi and the cable shown in my pictures).
• Did my tests late at night when no other electronics in the house are functioning to rule out EMI.
• I read through Printer disconnect mid print and all the linked threads, that's why I tried many things to rule out EMI.
• My new pancake stepper motor came with a heatsink so I attached it since it was getting kinda hot.

Have you tried running in safe mode? Did running in safe mode solve the problem?

Yes / No.

The one at the back is the one printed in safe mode.

Systeminfo Bundle

octoprint-systeminfo-20240703113226.zip (868.9 KB)

Additional information about your setup

• OctoPrint version: Build 2023.06.27.083607 with "camera-streamer"
• OctoPi version: based on OctoPi 1.0.0, running on Raspberry Pi 4 Model B Rev 1.4
• Printer: Ender 3 of Theseus.
• Firmware: Comparing MarlinFirmware:bugfix-2.1.x...Deses:bugfix-2.1.x-deses · MarlinFirmware/Marlin · GitHub
• Browser: Brave browser
• Operating system: Win 11

Additional thoughs:

I honestly think it's the Marlin firmware "bugfix-2.1.x". I should probably try compiling the stable 2.1.x version or even 2.0.x and see what happens.

[foosel]

Contrary to what the name bugfix might imply, that's actually a development branch and build you have running there. So yes, I strongly suggest trying a stable release version instead.

FAQ for that:

OctoPrint tells me I'm running a firmware development version, why?

OctoPrint's bundled FirmwareCheck plugin has been updated to also give you a short heads-up if you are running a development build of your firmware. [image] This is nothing to be alarmed about, but you should at least be aware that you are not running a final release version, and from our experience on OctoPrint's support channels we had to find that a lot of people aren't, hence the introduction of this short info. Running a development build means that more bugs might arise that also negativ…

From your logs:

2024-07-03 11:26:03,437 - octoprint.util.comm - INFO - Communication timeout while printing, trying to trigger response from printer.
2024-07-03 11:26:04,518 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/comm.py", line 4172, in _readline
    ret = self._serial.readline()
  File "/home/pi/oprint/lib/python3.9/site-packages/octoprint/util/comm.py", line 6931, in readline
    c = self.read(1)
  File "/home/pi/oprint/lib/python3.9/site-packages/serial/serialposix.py", line 595, in read
    raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2024-07-03 11:26:04,630 - octoprint.util.comm - ERROR - Please see https://faq.octoprint.org/serialerror for possible reasons of this.

FAQ for that:

OctoPrint randomly loses connection to the printer with a "SerialException"

A "SerialException" like e.g. device reports readiness to read but returned no data indicates that something a layer beneath OctoPrint broke and the connection to your printer was lost due to that. There's nothing OctoPrint can do about this - as already said the issue happens beneath OctoPrint. It's basically like someone pulled the rug from beneath its feet. The most common reasons for this are: You forgot to actually turn on the printer. You are running OctoPrint on a Raspberry Pi but have…

[Deses]

Yeah... I think I'll just go ahead and make a new stable firmware, since I know none of the points in the "SerialException" list applies to me.

Thank you Gina for taking the time to answer!

[Deses]

So an update on this.

I did go back to 2.0.x and also had a serial disconnection. In the logs I saw that it was related to MeatPack so I disabled it. Did some dry runs first and some actual test prints later and everything turned out fine. The quality was pretty good too!

So I'm positive this can be resolved. Maybe in the future I'll try 2.1.x again now that I know what to look for.

Thank you!