Klipper 'mcu' shutdown: timer too close

[Denis]

Basic Information:

Printer Model: Tevo Tornado
MCU / Printerboard: MKS Gen L V1.0 (ATMEGA2560) w TMC2208 (UART)
klippy.log
klippy.zip (3.2 MB)
Klippy Version: klipper v0.11.0-299-gb1f597c5
Host: Raspberry Pi Zero 2 W Rev 1.0
fluid version: fluidd v1.25.3
printer.cfg (11.1 KB)
Slicer: CuraEngine builtin Cura 5.4

Describe your issue:

Hi, I get a random mcu shutdown due to timer too close. I changed the position of the model in Cura and did a second try, but with the same outcome at around the same print area. Second time some layers later. Before the second print I also tightened all cables.

While analyzing the klippy.log I am seeing a spike of Bandwith and Host buffer around the shutdown. Never had problems before, but it seems that this is the biggest and most complicated .gcode file I printed yet (141 MB).

Can there be issues from the slicer? Do you have any ideas how to fix this problem? I read something about increasing the buffer size, but this would flatten some fluctuating data amount, here I see more of a big spike, which leads to the problem and the timer getting violated.

Cheers
Denis

UPDATE/SOLUTION: The problem occurred more frequently, even after disabling nearly everything on the host (webcam, etc) and reducing the complexity. A fresh install on a new SD card solved the problems and the print succeeded with the previous high complexity and even time-lapse active. Most likely it was a faulty/well-aged SD card.

Thanks for the support Arakon, @LifeOfBrian and @Sineos

[Denis]

Here is the log of the second attempt, basically the same crash:
klippy_second_attempt.zip (3.0 MB)

[Arakon]

If the slicing resolution is set too high, that can cause high load during prints with lots of direction changes. Maybe check what that is set to in cura.

[Denis]

Yes there are a lot of direction changes in that printing area. Maximum Resolution is 0.5mm and Maximum Deviation is 0.025mm. Increasing the maximum deviation to e.g. 0.05mm would make it slightly less accurate, but reduces a lot direction changes. Will try that, thank you.

So, if it would help, this means the mcu (ATMEGA2560) is on the limit to process the amount of commands in time, right?

[LifeOfBrian]

Check this for better understanding:

Timer too close

Background This error typically occurs when the host sends a message to the MCU, scheduling an event at a time that is in the past. Reasons High system load of the host High disk activity of the host Swapping due to low free memory Disk errors / dying SD card Unstable voltage Other hardware hogging the USB bus or other system resources Running in a Virtual Machine USB, UART or CANBUS wiring faults leading to extremely delayed messages ElectroMagnetic Interference (EMI) affecting proper signa…

[Sineos]

@Denis

So, if it would help, this means the mcu (ATMEGA2560) is on the limit to process the amount of commands in time, right?

As indicated by @LifeOfBrian this is rather a host problem and not a board problem.
Usually, this type of error is not caused by too high resolution unless the amount of data is somehow overpowering the host.

[EddyMI3D]

UPDATE/SOLUTION:

@Denis

The problem occurred more frequently, even after disabling nearly everything on the host (webcam, etc) and reducing the complexity. A fresh install on a new SD card solved the problems and the print succeeded with the previous high complexity and even time-lapse active. Most likely it was a faulty/well-aged SD card.