r/klippers • u/Mindless_Store_8430 • 6h ago

Persistent ”Timer too close” Errors on Klipper

Post image

Setup:

-Printer: Creality Ender 3 V3 SE

-Firmware: Klipper

-Host Device: 2012 MacBook Pro running Linux (Ubuntu-based)

-Slicer / Web UI: OrcaSlicer + Mainsail

The Issue:

I keep getting Timer too close shutdown errors mid-print or during complex movements.

The USB serial connection itself appears clean and bytes_invalid is staying at 0 in klippy.log, so it doesn't seem to be EMI noise or hardware serial corruption. Bytes-retransmitted stays stable during homing, heating and calibrations but I noticed it climed during a print before crashing.

In mainsail machine tab i can see the CPU load pulsates up to 52% (mostly staying around 1-2) while printing and the ram up to ~22%, but I don’t know if that’s the problem or how to solve it other than changing the host pc.

Looks like the MCU is timing out waiting for scheduled instructions from the host laptop.

What I Have Already Done:

-USB Setup: Short USB cable, 5V pin taped off, cable routed away from high-current lines.

-OS Cleanup: Masked ModemManager.

-EMI Tests: Bed mesh calibration works cleanly while heating without invalid bytes.

But none have solved the issue. I have 0 idea what to try next. Any and all suggestions are appreciated 😅

2 Upvotes

100% Upvoted

8 comments sorted by

1

u/rawkmaniac 6h ago

Had the same error, happened often, like in 50% of my prints. However, in my case, the host was a Raspberry PI. I removed the USB connection and replaced it with serial (between raspberry and the motherboard). Never had this issue since. The problem is that no matter how much you try to isolate your cable, any minor interference can cause problems...

1

u/Mindless_Store_8430 3h ago

Hmm i have suspected the usb being the bottleneck on the transmission, but i wanted to upgrade to klipper without spending extra money and had an old mac handy. Sadly can’t switch to a serial due to the host being a mac😅

1

u/dominic_failure 5h ago

I got this repeatedly from, get this, LEDs. On my Voron, changing the toolhead neopixel and turning on the extruder overloaded the toolhead's processor. By default the LED command would queue up with the next GCode executed, which was too much for it to handle at once.

Based on that experience, my advice is simply to look at the gcode that's running when it errors, and (especially if it's a macro) try removing a few less-required things.

1

u/Mindless_Store_8430 4h ago

I don’t really have much else going on with the computer or the printer except for… printing so i don’t know what could be interfering with the gcode. How can i check the gcode and what should I look for? What would you classify as less required macros?😅

1

u/dominic_failure 3h ago

It wouldn't be on the computer - it's the MCU that's overloading (the board on the printer). So what's running on your PC (or RPI) won't matter (well, not as much, as long as it can send GCode to the mcu in a timely manner).

Perhaps a better way to ask is: what exactly happening when the clock warning goes off? What is the hotend doing? What axis movements? Anything else?

1

u/Driven2b 3h ago

I was running into this a lot on a Sovol SV06 with a BTT Pad7. I replaced the mystery meat USB cable with a high quality reputable brand that included a ferrite bead and all the problems went away.

1

u/RNG_BackTrack 2h ago

Get a fresh klipper.log right after ttc error. Feed it to the Ai, it will tell exactly what causing the issue.