Timer Too Close during Kick macro | ArmoredTurtle 3D | Page 1

exotic vigil May 7, 2026, 4:54 PM

#

Hi, I've hit timer too close twice in the last week or so on the few multi color prints I've run. Both times it's happened during the Kick macro. I've verified I'm on the latest version. I did consider increasing trsync timeouts but I had some other issues after I changed them so I changed them back to verify that wasn't the cause. I need some assistance in understanding why it is occurring. A torture turtle didn't fail but I've had a failure on two 6.5 hour prints, the previous failure was on the last couple layers but this one was after about 2 hours.

Here's the upload from the troubleshooting script: https://termbin.com/06w4

mortal falconBOT May 7, 2026, 4:54 PM

#

<@&1304550334839918672>

exotic vigil May 7, 2026, 4:57 PM

#

Here is also the klippy log from the last timer too close during kick failure (2026-04-29) and I have a full copy of the home directory from that crash so I can share any configs or logs as needed.

📎 klippy.log

delicate nexus May 7, 2026, 5:42 PM

#

More often than not these happen because of disk issues. But review this pin and let us know how you'd like to proceed #boxturtle message

exotic vigil May 7, 2026, 5:45 PM

#

Yeah, printer is LDO Trident 300 Rev D. Pi 4 2gb ram, Sandisk SD card class 10 I think, LDO leviathan, nitehawk 36 over usb, BoxTurtle over CAN, trsync enabled.

I will look into upgrading the SD card in case that is the bottleneck but I haven't had as many issues in the past. But I also have run much slower accels and max velocity.

My default travel acceleration is 12,000mm/s^2 and I've had two failures transitioning from poop, kick start (move to begin position), move to z kick position, then just as the kick move begins TTC occurs. I wonder if it's just the high accel that's causing it with a Pi 4.

delicate nexus May 7, 2026, 5:59 PM

#

The issue with a slow disk is that klipper gets hung up when it's reading or writing, and the more processors you have to keep up talking to, the more chance that these stalls get in the way of work with realtime deadlines.

#

Make sure your macros are up-to-date as well, because some M400's were added along the way to make sure there's a sufficient wait in the transition between the different states.

exotic vigil May 7, 2026, 6:25 PM

#

Yeah, up to date macros, they have the M400 added, v1.1.0-0-g68cfe778

delicate nexus May 7, 2026, 6:33 PM

#

What's your USB hub situation look like?

exotic vigil May 7, 2026, 6:46 PM

#

Using the ports on the pi, one for NH36, one for a webcam. Forget which is hooked up to which port though, I think older pi's at least had different usb speeds for each set of ports.

delicate nexus May 7, 2026, 6:54 PM

#

I think you don't need any USB hubs for this setup?

#

You might try it that way, directly connecting your devices, since USB hubs can sometimes have undesirable behavior

exotic vigil May 7, 2026, 7:38 PM

#

no hub, directly connected to the pi, I forget if the leviathan is using the hat for communication or if it's through USB as well. it's configured with a can UUID so might be CAN over USB.

delicate nexus May 7, 2026, 8:25 PM

#

lsusb -tv for me

exotic vigil May 8, 2026, 12:00 AM

#

/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    ID 1d6b:0003 Linux Foundation 3.0 root hub
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    ID 1d6b:0002 Linux Foundation 2.0 root hub
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        ID 2109:3431 VIA Labs, Inc. Hub
        |__ Port 2: Dev 26, If 0, Class=Vendor Specific Class, Driver=gs_usb, 12M
            ID 1d50:606f OpenMoko, Inc. Geschwister Schneider CAN adapter
        |__ Port 3: Dev 4, If 0, Class=Video, Driver=uvcvideo, 480M
            ID 046d:0843 Logitech, Inc. Webcam C930e
        |__ Port 3: Dev 4, If 1, Class=Video, Driver=uvcvideo, 480M
            ID 046d:0843 Logitech, Inc. Webcam C930e
        |__ Port 3: Dev 4, If 2, Class=Audio, Driver=snd-usb-audio, 480M
            ID 046d:0843 Logitech, Inc. Webcam C930e
        |__ Port 3: Dev 4, If 3, Class=Audio, Driver=snd-usb-audio, 480M
            ID 046d:0843 Logitech, Inc. Webcam C930e
        |__ Port 4: Dev 5, If 0, Class=Hub, Driver=hub/4p, 12M
            ID 1a86:8091 QinHeng Electronics
            |__ Port 2: Dev 25, If 0, Class=Communications, Driver=cdc_acm, 12M
                ID 1d50:614e OpenMoko, Inc.
            |__ Port 2: Dev 25, If 1, Class=CDC Data, Driver=cdc_acm, 12M
                ID 1d50:614e OpenMoko, Inc.

Looks like webcam, nitehawk, and MCU canbus adapter are over usb

delicate nexus May 8, 2026, 12:19 AM

#

Yeah, that's right, the nitehawk has the internal hub

#

Well, you could consider moving that camera if you keep having problems, like to another SBC nearby, and just want to work around it for now

exotic vigil May 8, 2026, 3:37 PM

#

Tried running again with still 12,000 accel for travel and webcam unplugged. Still encountered Timer Too Close. https://termbin.com/489qe

Picking up a new SD card tonight from Micro Center so I will see if that improves anything.

delicate nexus May 8, 2026, 4:00 PM

#

Great. Give the performance scaling governor change a try too

exotic vigil May 8, 2026, 4:40 PM

#

I did that already as well 🙁 but let me double check

#

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

delicate nexus May 8, 2026, 4:49 PM

#

Tough case. Let's see how the SD card change goes. The ratings are all over the place and it's hard to tell what's going to work well. Even though the bus speeds might be supported with the class- and u- ratings, the actual media speeds vary. Look for a V30 rating or better (media speed) combined with at least UHS-I (bus speed), as the V rating actually pertains to sustained write speed, and you won't benefit from anything beyond UHS-I due to the pi

#

IOW, given this choice, pick up the extreme pro because it's still UHS-I but has a higher V rating (this isn't a great example because these are sd and not microsdhc):

#

And don't bother with the UHS-II V60 for $120

exotic vigil May 8, 2026, 4:53 PM

#

I was looking at SDSQXWG32GANCMA which looks like it is UHS-3, V30 which is available locally

delicate nexus May 8, 2026, 4:55 PM

#

U3 != UHS-3. This is a UHS-I V30 card which is right on the money. Man I hate sd card ratings. But yeah, that'll be perfect.

#

And if that doesn't work, you can be one of my testing guinea pigs for thread priority and disk cache tweaks

exotic vigil May 8, 2026, 5:30 PM

#

Ah good to know. I did notice that the microcenter page was a little inconsistent but wasn't sure. We'll see how this performs.

BTW, I am a programmer but I haven't looked at Klipper code and I don't do any real-time programming. My basic understanding is that TTC occurs because the host is using the gcode to generate step commands for the MCU to execute. When the scenario that we fail to generate step commands fast enough for the MCU to execute, (i.e. the MCU rtc is too near the host rtc & step generation to guarantee appropriate delivery in time) we find the TTC error.

I'm happy to do any modification to source and config for additional debugging or run the Klipper motion analysis / debugger along side some prints.

delicate nexus May 8, 2026, 5:34 PM

#

Great. I got the impression you had a technical background from your answers. You're exactly right, and the complications to keep in mind here are that 1. linux is not real time by default (although we do have a kernel now that supports RT priorities!) 2. python doesn't actually multi-thread very well due to the GIL. So all these threads to service work to the MCUs, even if they get bumped to RT, can be starved out if another thread in the same process is holding the GIL. And as far as we've seen here, the biggest offender there seems to be klipper logging threads, hence the issues with disk, and the need either speed it up, or possibly to tweak the cache so that it's not hung up for too long.

So there you go, short answer 😉

#

It's proved really hard to nail anything down though, and there are so many factors that can influence timing in the system, so for "fixing ttcs", there really isn't anything prescriptive to do, other than make little changes until you get there

exotic vigil May 8, 2026, 7:22 PM

#

Gotcha, that that was kind of my impression. It likely doesn't help that python doesn't support native threads or at least doesn't perform as well as other languages so we're trying our best to keep ahead of real time processing. I'll update at some point tomorrow / Sunday to see if I can make it through this print at the current speeds / accels with the SD card change. In the meantime I may re-connect the webcam and re-enable home assistant integration since those appear to be unrelated or at least not a large enough resource drain to make a significant difference.

delicate nexus May 8, 2026, 7:26 PM

#

At some point, Debian and the raspberry pi releases will get free threaded python, and that should help a lot

exotic vigil May 9, 2026, 4:56 PM

#

Unfortunately, full reinstall later on the new SD card, no webcam, still hit TTC, again mid-kick macro.

https://termbin.com/bkfg

I forgot that my old SD was 64gb and the new is 32 so I needed to do a fresh install but cloned all the old installs. Everything should be identical aside from recreating venvs and re-running make / install scripts as needed.

This is the same file that failed before.

#

exotic vigil May 9, 2026, 6:35 PM

#

On a whim I removed the m400 at the start of Kick and see a TTC immediately on the first filament swap during kick.

#

https://termbin.com/arwd

feral sleet May 9, 2026, 6:42 PM

#

you can try putting M400 at the end of your kick macro

delicate nexus May 9, 2026, 7:45 PM

#

Also, did you put the performance governor change back in place?

exotic vigil May 10, 2026, 2:15 AM

#

Unfortunately I forgot to change the governor back but now it's changed back and permanant with the klipper service.

I'll try adding m400 at the end of kick also.

exotic vigil May 11, 2026, 8:25 PM

#

Had a chance to run the print again. Same print, same gcode. Ensured that performance governor was configured and persistent and also added M400 before the "kick filament" move as well as at the end of the Kick macro before AFC resumes to gcode swap point.

It completed successfully.

Here's the changes I've made: https://github.com/jmlw/AFC-Klipper-Add-On/commit/8e7acd1828674db8d79b5e45f8b2408e9937e12a

I'm not going to open a PR yet because I'm nto sure that it's relevant for a majority of installs. Also I added at the end and before the actual kick move because I had TTCs moving back to the prime tower after cut, purge, kick as well as mid-kick when toolhead moves to a small Z to knock the filament with the toolhead.

delicate nexus May 11, 2026, 8:28 PM

#

I think we'd be 100% happy making this change, if you could just confirm that reverting it, leaving only the performance governor change in place, makes the issue reappear. The M400's in the macros can't hurt, and if they are helping for you they'll help others as well.

#

When the original M400 change was made, it was a best guess as to where they were needed and they were not everywhere. Prior to that the advice we were giving here was basically "pepper M400 all over the macros if you're having problems", so we never really knew for sure where they were needed.

#

You've got what seems like a pretty nice pathological case here

exotic vigil May 11, 2026, 8:32 PM

#

I can try running again in the next few days with just the governor change. I also haven't plugged the webcam back in yet so that could still be a factor as well.

#

Though the M400s make me think that the macros themselves aren't the issue, the execution of the macros is. I'd need to take a look at AFC & how it interacts with the klipper gcode queue, I'm not quite sure where that is. I remember reading in the past that klipper devs weren't especially supportive of plugins adding gcode so there could be some race condition with the way gcode is processed from file vs the plugin. Totally blowing smoke there though cuz I don't really know what I'm talking about.

feral sleet May 11, 2026, 8:44 PM

#

Well we just use klippers gcode object to call gcode macros commands... Sooo 🤷‍♂️

exotic vigil May 12, 2026, 12:46 AM

#

smh, 3.25hr in w/o the new M400's and it's still running w/ ~2.5hr left. Even confirmed in Klippy log that last config echo'd was missing them. Maybe it's non-deterministic. Was running low on the last two filaments that were the primary color so switched to a Sunlu roll for that, otherwise the old rolls (lane 3 and lane 4) were loaded with Inland Matte PLAs, current lane 4 is a Sunlu PLA. I expect to behavior difference though because I'm printing the same file anyway, no temp changes.

delicate nexus May 12, 2026, 3:53 AM

#

Well, you can try putting them back, and then reverting the performance governor change in that case

#Timer Too Close during Kick macro