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
I am using a Debian VM on my PowerEdge R710, and it has 4 cores and 4 gigs of ram. I have had tons of successful prints, until this latest one. I am even a little bit slower than normal due to printing PETG and not PLA. I have had this issue several times with OctoPrint as well. I will have several successful prints, and then all of a sudden I will have a print that fails about 25% or 50% through. I cannot figure out any issues on the PC end, there aren’t errors in the DMESG, and there is very little CPU/RAM usage on the VM. Attached are my logs, this issue has been intermittent until this print. Usually I can clear the bed, restart the print and it will finish. Not this time! I have attached the GCODE also for that print.
After several restarts, and I changed orientation of one of the parts I successfully printed this piece. This is an intermittent issue, and I am not sure how to remedy this.
The Klipper host software (klippy) has some real-time requirements. In general, it may have to respond to an event within a couple of hundred milliseconds. Should it fail to respond in a timely manner then it can result in errors like you’ve reported.
It sounds like you’re running the host software in a VM. Be aware that if anything on the host machine (the r710) consumes notable CPU time (or memory, swap, etc.) then it can cause a scheduling delay in the VM running Klipper which can lead to errors like the above. This real-time nature of Klipper is one of the reasons we currently recommend running Klipper on a dedicated single board computer (SBC).
I have klipper in a VM in Proxmox, with 4 cores dedicated to it; as well as 4 gigs of ram. It should have plenty of resources, and I never see over 1 or 2% CPU usage inside of the Debian VM.
Is there a way to slightly de-sensitize the timer for this error in my case? Pi’s are quite difficult to come by at decent prices right now it seems.
Hmm, I have the SKR Mini E3 1.2 in the Ender 5; but I also have a Ender 3 on SKR Mini E3 2.0. I think I left it at 8mhz for both of them, but I can only find a refence for the 2.0
This link says to set it to 8mhz for the 2.0; anyone got information for the SKR Mini E3 1.2 clock ref?
Yep; good find. I am unsure then. I don’t get why sometimes it will work great, and then randomly after several prints this will happen. It always happens like 1/4 or mid print.
Klipper is not about CPU power or RAM. You can throw as much as you want at it without any benefit. Essentially it will run on a Raspberry Pi Zero which has the performance of a mechanical watch.
Klipper is about precise timing down to milliseconds. Here the pitfalls begin:
VM systems are tuned to scheduling fairness → Klipper demands real-time
VMs do houskepping and stuff in the background → Klipper says “not while I’m printing”
VMs add hardware abstraction and complexity → Klipper wants direct and exclusive hardware access
It can work to run it in a VM or it can lead to subtle and hard to diagnose problems.
My VM server is running two firewalls, two linux VMs, pihole, netflow collector and klipper with fluidd. I have zero timing related issues. Browsing the internet, compiling and watching videos is not causing any issues - all running on a 4 core 8 years old desktop CPU. One problem, I mentioned earlier, was with USB passthrough freezes VM when pi pico mcu is connected.
PS: is there a way to tell what the jitter and/or latency is between klipper and mcu? I would be curious to know how various VM tasks affect the timing.
It’s great that it works for you, but it doesn’t for the OP. I’ve also seen several reports from other users with similar issues when attempting to use a VM. This is why it is not a recommended configuration. The failures are hard to diagnose and generally outside the control of Klipper.
I do remember how years ago some doubted that using rpi and python for printing was not real-time enough. And those people were proven wrong. I posted my experience here because normally forums are where people come with issues so it might give readers false idea that running klipper in a VM is impossible.
I appreciate your replies w00sh. I had run Octoprint and Marlin only with this same configuration for years without issue. I understand Klipper requires instant access to the bus, and doesn’t like to wait…
I’m just asking if there is a way we CAN desensitize the “timers” in a way that will not affect print quality or safety.
I have an Atomic Pi SBC, and maybe a Pi Zero W laying around I could try alternatively in the future. I have klipper on a Pi3b/Ender 3 also, but will be building my RatRig Vcore3 soon as well. I would prefer to be on a single firmware across the board.
I would prefer for the Ender 5 to work in a VM and I’d hate to go back to Marlin. Due to this printer being on top of my server rack it’s convenient.
I am going to look into the Linux logs and see if anything pops out at me. Maybe a driver or USB host issue.
…I forgot that I’m also running Home Assistant on the same server…
Anyway, Kevin mentioned that timing requirements are in 100s of miliseconds range so KVM should not have issues meeting that. See if you can tweak power management settings so the CPU does not throttle too much, use USB port passthrough, adjust CPU units for your VMs. First thing however, I would suggest to try setting up new barebone VM with klipper. Here’s what I’m using: Ubuntu 20.04.02 LTS
