Printer keeps crashing Mid-Print

Basic Information:

Printer Model: Voron 2.4r2 350mm
MCU / Printerboard: BTT Manta M8P V1.1, BTT SB2240 Can Tool Board
Host / SBC: BTT CB2
klippy.log

Describe your issue:

My Voron 2.4r2 350mm printer, keeps crashing mid-print. Otherwise, the printer performs very well with no indications before crashing, which is extremely frustrating.

Error Message Received:

MCU ‘mcu’ shutdown: Timer too close
This often indicates the host computer is overloaded. Check for other processes consuming excessive CPU time, high swap usage, disk errors, overheating, unstable voltage, or similar system problems on the host computer. Once the underlying issue is corrected, use the “FIRMWARE_RESTART” command to reset the firmware, reload the config, and restart the host software. Printer is shutdown.

What I’ve Tried:

  • Reviewed the graphs extracted from the klippy.log file; everything appears fine (https://sineos.github.io/)
  • Searched the klippy.log for errors but had difficulty identifying any, as I’m not an expert in reading these logs.

Additional Information:

The printer operates smoothly for the most part and only crashes during prints over 1-2hours.

No obvious patterns or specific print jobs trigger the crash consistently.

I’m seeking help to identify the underlying cause of these mid-print crashes. Any guidance on interpreting the klippy.log or troubleshooting steps to resolve the “MCU ‘mcu’ shutdown: Timer too close” error would be great

Thanks in advance for any assistance!
klippy.zip (1023.7 KB)

Hello @MrCharly169 !

There is this:

Timeout with MCU 'EBBCan' (eventtime=18470.201722)

You may check the Can setup

Thanks for the quick response! I’ll check my CAN setup. What could be causing the issue? Could the clock speeds be set too high?

Funny enough, I’m experiencing the same problem with my Voron 0.2 now.

Your actual error is

Timeout with MCU 'mcu' (eventtime=18470.201722)
Transition to shutdown state: Lost communication with MCU 'mcu'

See Timeout with MCU / Lost communication with MCU

The follow-up error regarding the EBB is consequential to the MCU dying.

Hi Sineos,

Thank you for the clarification. It’s reassuring to know that the issue isn’t stemming from the CAN bus.

Update on Troubleshooting:

I unplugged the two USB camerasLogitech C920 and Nozzle Cam 3DO 4K—as I suspected they might be causing the problem. Since unplugging them, the printer is running strong without any crashes. Here’s what I observed when the cameras were connected:

  1. Performance Issues:
  • Resolution Reduction: I had to decrease the resolution of both cameras to 640x380 to achieve around 10 FPS.
  • Streaming Degradation: After running the printer for a few hours, the streaming performance drops further to just 1-2 FPS

Questions & Request for Suggestions:

  • USB Bandwidth: Could the USB cameras be overloading the host (BTT CB2), leading to these performance issues? I´m not observing that the CB2 load surpasses 30-40%.
  • Optimization: Are there ways to optimize camera settings or host configurations to handle both cameras without compromising performance?
  • Hardware Limitations: Is the BTT CB2 limited in handling multiple high-resolution USB streams simultaneously?
    crowsnest.log (7.2 MB)

Thank you all for your help! Since disconnecting the cameras from the CB2, the printer has been running flawlessly.

However, I still want to use my cameras and have checked my configuration countless times without finding anything wrong. Could it be that the CB2 is simply too weak to handle the workload?

I’m also experiencing similar random MCU crashes with my Voron 0.2 (Pi4) when using a PiCam3. I’m unsure if I’m missing something in the configuration.

Since the problem is deviating, should I open a new thread?

Thanks

It is well known that webcams tend to “destabilize” the USB connection, and this point is also explicitly mentioned in Timeout with MCU / Lost communication with MCU.

Why some webcams or setups are affected while others are not is not known. You can try to place an active USB hub in between. There are reports that this has helped improve the situation.

Likely, this is exactly the same issue.