MCU 'mcu' shutdown: Timer too close on voron 2.4

MCU ‘mcu’ shutdown: Timer too close This often indicates the host computer is overloaded .

Basic Information:

Printer Model: voron 2.4 350
MCU / Printerboard: HOST : old laptop linux mint 4gb ram Intel Core 2 Solo SU3500, Intel Pentium Dual Core SU4100 MCU: Spider v2.4
klippy.log

Describe your issue:

Hello, im having this issue " MCU ‘mcu’ shutdown: Timer too close This often indicates the host computer is overloaded ."
I dont think that my host pc is getting overloaded even becouse while its printing i can see the cpu at 10 -15% top.
Some one with some experience in reading the log can please tell me whats the real cause to this?
Scenario: long print estimated 16h error showed after 5h
Thanks in advance :slightly_smiling_face:

Hello @shoxz !

You may have a look on this:

Also try with 16 microsteps.

1 Like

Hi Eddy thanks for reply.
i ve already read those, going by step
high load: not the case im running 10 to 20%
low free memory: host is clean only linux and klip ram is using only 800mb of 4gigs , hdd has around 100gb free
unstable voltage: is this refered to host or to mcu? host cant have unstable cause its connected to the plug and also has a working battery (laptop) , if we are talking about mcu thats another story , what do you think?
about the remaining i dont know how to filter them to the proper cause.
did you have a chance to take a look to the log?
thanks again

Could it be the high host buffer utilization?


Good luck, hcet14

1 Like

sorry i tried to google it but didn’t get it, could you please explain whats host buffer and what may be the cause? thanks

Some background jobs saturated CPUs to > 200% just before the shutdown happened:

You can list scheduled tasks with sudo systemctl list-timers and sudo crontab -l and see if the culprit can be found by its execution schedule. You can also look at the system logs around the shutdown time, background processes usually leave some trace.

You can somewhat harden klipper against disruption by background tasks by adding to /etc/systemd/system/klipper.service:

[Service]
Nice=-18
IOSchedulingPriority=1

But in general, I recommend not running the Klipper host on a desktop linux distribution, since they often come with lots of fluff running automated background updates, checks, backups, etc.

1 Like

hey Piezo, thanks also for your answer, background process or mainly update was a thing that came in mind also to me, thanks for the command line. Today im printing again the same gcode, i ve closed all linux process that can make update or background activity. Lets see.

Got the same error again after 10H, btw @Piezo im not able to save the klipper.service even if im logged as root, is that normal?
Im almost sure that i will buy an overpriced RPi cause i really need to have this printer stable for long jobs becouse is going to print pricy filaments.
Do you think that swapping to Pi will solve it?

is quite old Intel® Core™2 Solo Processor ULV SU3500
You might compare the RPi benchmarks against your 4gb ram Intel Core 2 Solo SU3500.

Did you start installing Klipper with a fresh (deleted everything on the HDD) linux mint install?

Good luck, hcet14

1 Like

Can you post the klippy.log? This will allow checking if it’s the same issue and CPU load pattern.

I think your problem is caused by the distribution. An old SU4100 laptop should not have any issues with Klipper if you dedicate it entirely to this task with a lightweight distribution like Debian. You don’t have to buy a raspberry brand pi, any old refurbished business desktop computer, old laptop, should do the job. If you want the form factor of a Single Board Computer, you can use another brand, or a NUC/Mini PC. Avoid the single core SBCs like the Raspberry Pi Zero (W).

No. sudo chmod u+w /etc/systemd/system/klipper.service can possibly fix that. sudo -e /etc/systemd/system/klipper.service should be able to edit it anyway.

1 Like

i know its old, but is empty and clean installed linux mint lite , there is nothing except klipper and some script for input shaper, no webcam also

1 Like

@Piezo i ve just pulled it, i dont know if the issue is still showing cause i started another 2 “short prints” after that scenario. i was thinking about the pi cause u said that vm are not good for the task :+1:
Klippy.log

Bandwidth is high. Don’t know. how to interpret that.

That looks good from your klippy.log

But, there is no " MCU ‘mcu’ shutdown: Timer too close" in your klippy.log

1 Like

yes im sorry , i ve pulled downloaded the klippy log after 2 other prints , maybe has been overwritten during those two.
what can cause a high bandwidth?

Little update, i ve been able to modify the klipper.service with ‘sudo chmod u+w /etc/systemd/system/klipper.service’ , Since then i ve done two 6h prints without issues, maybe it got better, im going to update again when im going to do a longer one :slight_smile: thanks for now Piezo and also thanks to all the guys that took time to reply :+1: