Klipper shutdown - Timer too close - Suspicious oid, linked to a heater

[JuanR3D]

Basic Information:

Printer Model: Custom
MCU / Printerboard:Manta M8P, EBB42 Gen 2 (toolboards)
Host / SBC CM4
klippy2026-07-25.zip (5.8 MB)

klippy.log
** I have deleted some lines of the log since it exceced the maximum size of the upload

Describe your issue:

I’m getting random Timer too close shutdowns.

I previously replaced all my older BTT EBB42 boards with the newer EBB42 Gen2 because I suspected the older boards were causing stability issues related to scheduled OIDs/digital outputs.

However, I’m still occasionally seeing Timer too close.

From what I’ve seen so far, I believe the issue is related to the extruder heater PWM output, but I’m not completely sure.

Could this still be related to OID scheduling or delayed digital output updates? Is there anything specific I should check or any known cause for this type of failure?

I’d really appreciate any help.

I don’t know if this could be related to some delayed macros I use for various checks, or perhaps to the configuration of my outputs or heaters.

Please take a look at my configuration and log. I’m completely lost with this issue.

[EddyMI3D]

@JuanR3D

** I have deleted some lines of the log since it exceced the maximum size of the upload

Even it is zipped?

Git version: '160ea1f-dirty'

This is not a genuine Klipper: 3D Printers with Preinstalled and Modified Klipper Versions and The "dirty" Flag and the Team's Position

You may ask BIQU what is going on.

[cardoc]

Can you provide a schematic of your CAN wiring? Include branch lengths and resistor locations,

IMO, 4 TTC’s in a row with no print running = Hardware issue

[JuanR3D]

Hi, yes, even zipped, it was 11 MB, so i just removed some lines.

My modifications only apply to set_velocity_limit and a custom bang bang temperature control i generated for my heated bed. Klipper version is almost up to date since i updated it very recently.

I’ll ask biqu if there is something with their heater output in the EBB, but I dunno if this is the case.

[JuanR3D]

Hi,

Thanks for your reply.

Here’s my CAN bus topology.

It is a linear bus with no stubs or branches, and it is as the following:

1. BBCAN_0 → 2 m → EBBCAN_1 → 5 m → Manta M8P (CAN bridge to CM4 host) → 5 m → EBBCAN_2
2. 120 Ω termination resistors are installed only at EBBCAN_0 and EBBCAN_2.
3. Every board has its GND connected.
4. The cable shield is connected to ground at a single point inside the electrical cabinet.
5. The chassis/star ground is also generated at that same single point to avoid ground loops.

I don’t think this is a CAN wiring or signal integrity issue.

If you look at my log, the communication statistics are extremely clean. The machine has been powered on for about 11 days, and the only TX/RX errors present are the few accumulated during startup. After that, communication remains stable throughout operation, with no retransmissions or signs of CAN bus instability.

I’m using graphstats right now in order to see something

[EddyMI3D]

@JuanR3D

Klipper version is almost up to date since i updated it very recently.

I see - but it is no genuine Klipper.
We do not know what BIQU has done to the Klipper-code.

[JuanR3D]

My custom modifications are unrelated to this problem. Even without them, I’d still be running BIQU’s fork, whose code is based on the official Klipper source. So unless you can point to a specific BIQU modification that causes this issue, I don’t see how that’s relevant.

[JuanR3D]

Hi.

I’ve been investigating this issue a bit further by checking different processes, using graphstats, and comparing several printers.

It looks like the problem is related to some process gradually consuming more and more memory over time, while CPU usage remains fairly normal.

These are the graphs from one printer:

24-07

25-07

26-07

27-07

Today
I found the printer idle with almost 85% RAM usage, even though it had finished printing several hours earlier.

While generating the graphstats graph, the system eventually ran out of memory and triggered the OOM killer (graphstats was simply the last process requesting additional memory).

And these are the graphs from the printer of the fault timer too close.

Please note that on 25-07 the printer remained paused over the weekend due to a filament runout, and this is also the printer that experienced the original failure.

24-07

25-07 (Day of failure)

26-07 (some restarts)

27-07

Today

I’m also checking the logs, and it seems that Xorg is the process consuming the memory.

At the time the system was almost out of memory, Xorg was using approximately:

• RSS: ~2.6 GB
• Anonymous RSS: ~2.5 GB

Eventually, the kernel reported:

Out of memory: Killed process XXXX (Xorg)

Klipper, Moonraker and Crowsnest all had normal memory usage.

The Xorg log doesn’t show any obvious DRM, VC4 or OpenGL errors.

I’m wondering if this could be related to KlipperScreen, since it’s the only application using Xorg on these printers.

I never turn off the display, and screen blanking is disabled. Could this be related? Has anyone seen something similar before?

Any tips or things I should check now?

Thanks

[hcet14]

@JuanR3D

** I have deleted some lines of the log since it exceced the maximum size of the upload

Could you split the full (unedited) klippy.log and upload it?

[JuanR3D]

Hi, i managed to zip the zip of the file haha.
I hope it works

klippy.log.2026-07-25.zip.zip (9.9 MB)

[hcet14]

Sorry, you got me wrong or my explanation was bad

When you do this with the unedited klippy.log you get several files and we will be able to unpack the full unedited klippy.log.
You’ll get several files named klippy2026-07-25.zip.001, klippy2026-07-25.zip.002, and so on. Each file will be small enough to upload. Upload them all.

[JuanR3D]

Somehow it creates one good, but the other one is z01, not zip, so I cant upload it here as browser says it is an uncompatible file.

klippy.log.zip (2.7 MB)

Please use this we transfer, here is the log

logs

[nefelim4ag]

Stats 1313611.3: ... sysload=0.94 cputime=63573.259 memavail=40192
Stats 1313613.0: ... sysload=0.94 cputime=63573.336 memavail=41524

Sent 95 1313611.981506 1313611.981296 15: seq: 1e, queue_digital_out oid=11 clock=954418526 on_ticks=408496
Sent 96 1313612.885238 1313612.885028 15: seq: 1f, queue_digital_out oid=11 clock=973618526 on_ticks=841780
Sent 97 1313612.899829 1313612.899619 15: seq: 10, queue_digital_out oid=11 clock=1012018526 on_ticks=307534
...
Receive: 90 1313612.885693 1313612.885238 12: seq: 10, shutdown clock=1006234631 static_string_id=Timer too close
Receive: 91 1313612.900044 1313612.899829 7: seq: 11, is_shutdown static_string_id=Timer too close
(1006234631 - 973618526) / 64000000
0.509626640625

So, it was busy with something; maybe it is due to memory pressure.
It struggles to produce stats every 1 second.

Normally, zswap can help if you have a recent enough kernel.

-Timofey

[JuanR3D]

I’ve also noticed that memory is under pressure at times, although I still don’t know why. I still need to investigate what’s causing the memory leak.

I’ll check zswap, thanks.

[printicus]

In your diagram shown further up you show MantaM8P and CM4. Why are you using BQ’s fork then? You can use mainline klipper, or MainsailOS…

[JuanR3D]

I dont use bq fork. I use original code of almost everything, I just modify some code of klipper and klipperscreen in order to custom my machine. In fact, mi code is based in MainsailOS.

[printicus]

@JuanR3D

My custom modifications are unrelated to this problem. Even without them, I’d still be running BIQU’s fork, whose code is based on the official Klipper source. So unless you can point to a specific BIQU modification that causes this issue, I don’t see how that’s relevant.

Sorry, but you sed:
“My custom modifications are unrelated to this problem. Even without them, I’d still be running BIQU’s fork, whose code is based on the official Klipper source. So unless you can point to a specific BIQU modification that causes this issue, I don’t see how that’s relevant.”
so I assumed you use BQ’s fork…

[cardoc]

@JuanR3D

My custom modifications are unrelated to this problem.

How can you be sure?

@JuanR3D

I dont use bq fork. I use original code of almost everything, I just modify some code of klipper and klipperscreen in order to custom my machine. In fact, mi code is based in MainsailOS.

I’m confused. You are rolling together Mainsail OS with some but not all of BIQU’s mods blended in, then a few custom tweaks here and there.

THEN

Insist the problem you are having is a mainline Klipper issue??

[JuanR3D]

Sorry for the confusion. The reason I kept mentioning BIQU is because Eddy’s first comments got me thinking that maybe there was some BIQU-specific code involved that I wasn’t aware of .

I honestly don’t know if BIQU maintains its own Klipper fork or what the situation is there.

Just to clarify for everyone: I’m not starting from anything BIQU-specific. My setup is simply a CM4 running MainsailOS, with my own repositories for Klipper, KlipperScreen, etc. They’re basically upstream, and I only merge in a couple of tiny modifications that I’ve made myself.

I’m not running a BIQU software stack or any BIQU-specific Klipper code (at least not knowingly ). It’s essentially upstream Klipper with a few small patches of my own. That’s why I don’t think my setup is fundamentally different from a standard Klipper installation.

[JuanR3D]

That’s fair, and I can’t be 100% sure.

What I mean is that I don’t believe the few code changes I’ve made are what is causing these issues. They’re very small modifications, and nothing that I would expect to affect memory management or system stability.

What makes this even harder to track down is that the problem is completely random. Most of the time the machine runs perfectly fine, and then, every now and then, something weird happens. It can go for a long time without showing any symptoms, which is why I’m so determined to figure it out.

At the moment my main suspicion is actually something else entirely—maybe an installation issue, a misconfiguration, or some service running on the host that is escaping my attention. I still need to investigate further before I can draw any conclusions.

So I’m not trying to say “this is definitely a mainline Klipper bug.” I’m just trying to understand what’s going on, and so far I haven’t found evidence that my own modifications are the cause.