Consistent failure at 50% print - MCU timeout

Basic Information:
Printer Model: CR-10 V2
MCU / Printerboard: atmega2560
Raspberry Pi 4 Model B 4GB
Fully updated Klipper and Mainsail

After getting my first 3d printer, I ran a bunch of calibration prints and stress prints that all completed without problems. I then moved on to my first “real” print, a cosplay helmet prop (around 48 hours print time).

I have now tried printing this 3 times - every time the print fails around 49-50% completion. I get a “lost communication with mcu” error in Klipper and have to do a firmware restart to get back online. The error contains no further details about the problem (see screenshot).

I have been asking about this problem on both Reddit and Discord for Klipper, but have not found a solution. I really hope someone here is able to see something in the files that could cause this. The failures are so consistent that I don’t believe it to be loose connections, I have made sure that everything sits tightly. If you need more info or files, please ask away!

printer.cfg (4.0 KB)
klippy.zip (3.2 MB)

Gcode (uploaded externally due to filesize and 2 link limit for new members)

This is just a guess. I think your atmega2560 is too weak for your printing speed.
Your klippy.log shows a high bandwidth from the beginning of your print Advanced Trouble-Shooting / Graphing Klipper.

Good luck, hcet14

I did try adjusting the print speeds. The Print Speed setting is at 50mm/s and Travel Speed at 100mm/s, this also being the highest speed value out of all settings. Acceleration at 1000mm/s2. Would this still be considered too fast?

Sorry, I don’t have a CR-10. Do a search here or wait til someone answers.

Good luck, hcet14

See: Timeout with MCU / Lost communication with MCU

-Kevin

Hey Kevin, thanks for the link! I did already read through that, and these potential causes were also mentioned several other places I have asked or searched for this issue. I really went through my setup to ensure that it’s not something loose.

My printer and Raspberry Pi are both using their own, original power supply. The USB cable between the RPi and printer I have secured by putting a slight strain on it (running the wire underneath the control box) so it don’t get affected by the printers vibrations and I have taped it as well. Have tried various USB ports on the RPi and no cables are damaged.

I also think if it was something like that, the problem would be more random. Here I printed the same model 3 times, and they all failed around 49-50% completion - I just feel this is too consistent and “repeatable”. All other models (though smaller) have printed without any problems. I hoped someone here could look through the files and maybe spot what could cause the issue.

I’m now doing this job for quite a while: All instances of this error that I have seen, boiled down to the reasons mentioned in this link. If you read carefully, it is not only the USB cable.

Edit:
I had one printer board, where the USB port on the board was of such bad quality that the slightest movement / vibration of the cable / plug was sufficient to raise this error.
But as stated, this is only one among some more potential reasons.

I believe you, I am just at a loss of what else I can try and it’s super frustrating. If it’s something like a bad USB port as you mention, then it’s beyond my knowledge and ability to troubleshoot or fix. I am so tired of this problem that I have ordered a new mainboard, so hopefully this big change will put this problem to the grave.

Yes, debugging such can really really be frustrating. Unfortunately from remote there is not much more help we can offer. Good luck!

…but never heard from @KazWahs

Good luck, hcet14

Alas, as indicated by others, there isn’t any further information to give guidance on. All we know is that the rpi can no longer communicate with the micro-controller. We don’t have any further information on why that is.

For what it is worth, I have seen past reports of this problem occurring during some prints at roughly the same points in the print. In at least one case it was eventually tracked down to bad cabling on the toolhead - during some prints the wires would get moved in a particular pattern that would cause a wire short - which led to resets on the micro-controller board that showed up as a “lost communication” report. In other cases, heat would build up during particular prints causing just those prints to fail.

-Kevin

I never did get back around to it. One thing after another keeps cropping up.

1 Like