Timer too close error at Unload sequence

[Ambilights]

I am having an issue where i get "timer too close" at unloading sequence. Print is running fine for a couple of hours with many toolswaps and then suddenly i get this error, always at unloading. I'm running easybrd can on ercf, sb2209 and IDM-scanner on toolhead, U2C-USB. mmu.zip klippy+mmu.log.zip

[moggieuk]

This seems to be appearing more often recently. Unfortunately it is a sign of momentary klipper overload rather than anything fundamental in Happy Hare. As I collect information it may be possible to workaround klipper but I don't have anything concrete at this time.

[Ambilights]

I noticed system load increase just after toolchange was complete and found that my gcode gave alot of "no pixbuf" errors in journalctl, after re-slicing and turning on "enable_object_processing: True" in moonraker.conf, the errors from mcu: mcu was gone. Still i get timer too close errors from mcu: mmu and found:

DEBUG: Reverse homing up to 103.0mm to extruder sensor (synced) to exit extruder 05:39:29 Did not complete homing move: Unable to obtain 'trsync_state' response 05:39:29     TRACE: Reverse homing to extruder sensor. Stepper: 'gear+extruder' did not home after moving -103.0mm (of max -103.0mm), encoder measured 4.0mm (delta 99.0mm). Pos: @-165.0, (69.5mm) 05:39:29     TRACE: Running macro: _MMU_ACTION_CHANGED ACTION='Unloading' OLD_ACTION='Exiting Ext' 05:39:29 Error running _MMU_ACTION_CHANGED: MCU 'mmu' shutdown: Timer too close

Could this be related to "TRSYNC_TIMEOUT"? I will try change it to "TRSYNC_TIMEOUT = 0.05" and see if there is any difference.

[moggieuk]

Ah! Firstly a homing move is taxing on klipper (and Happy Hare uses a lot of them). The TRSYNC "fix" is definitely helping a lot of folks -- I'm not sure why Kevin O'Conner is reluctant to update klipper but he seems adamant that it shouldn't be necessary. I think something has changed in Linux with the handling of serial messages and it is leading to an occasional delay...

Would love to know if hacking TRSYNC helps...

BTW What spec rpi are you running on?

[Ambilights]

8 hours and 350 toolswaps without any interruption later it seems like this hack fixed it, well not the underlying cause but at least i can print reliably again. None of my mcu's reports any "bytes_invalid" or increasing "bytes_retransmits" so i doubt it's the can network causing these timeouts. I wired a separate powersupply for the pi and ensured the cpu temperature stays below 50c so it won't throttle.

While searching for info about these timeouts it's clear that I'm not the only one experiencing this issue though it seems like it's most common on systems running on rpi4, Im running rpi3b. Would be great if any of the klipper dev's could have a look at what's causing it.

Tomorrow I will migrate to rpi5 and see if the issue persist while running with default TRSYNC values.

Thank you for the quick reply @moggieuk

[Ambilights]

And a few hours later "Unable to obtain 'trsync_state' response" showed up, even with TRSYNC_TIMEOUT = 0.05.... I switched to usb connection for the mmu mcu just to be sure it wasn't the can-network, however it didn't make a difference.

Yesterday i replace the pi3b for an pi5 and installed 64bit os and it has been running for about 18 hours without any errors. Klipper load during toolchange went from about 50-100% spikes to 2-5%.

[igiannakas]

And a few hours later "Unable to obtain 'trsync_state' response" showed up, even with TRSYNC_TIMEOUT = 0.05.... I switched to usb connection for the mmu mcu just to be sure it wasn't the can-network, however it didn't make a difference.

Yesterday i replace the pi3b for an pi5 and installed 64bit os and it has been running for about 18 hours without any errors. Klipper load during toolchange went from about 50-100% spikes to 2-5%.

I've had the occasional timeout with my old 3B PI when doing a bed mesh with my tap + can toolhead board. Moved to a CM4 module and its gone. So maybe indeed it needs a bit more raw horsepower with the latest klipper & linux code etc.

[appleimperio]

I'm having the asme issue logs.zip update: Try the TRSYNC fix and last way longer but it still happening

[billgeek]

Thought I'd throw my 5 cents in here as well as I just experienced the same issue. I did two successful shorter prints last night after completing the ERCF build. Today I tried a longer print (around 3.5 hours) and I got the error "Unable to obtain 'trsync_state' response":

12:31:07 [T1] < En <<<<<<<<< (*) << [Ex << (*) <. Nz] -62.0mm (e:63.0mm)
12:31:07     TRACE: Running macro: _MMU_ACTION_CHANGED ACTION='Unloading' OLD_ACTION='Forming Tip'
12:31:07     TRACE: Running macro: _MMU_POST_FORM_TIP
12:31:07     TRACE: Running macro: _MMU_ACTION_CHANGED ACTION='Exiting Ext' OLD_ACTION='Unloading'
12:31:07   DEBUG: Extracting filament from extruder
12:31:07     TRACE: _ensure_safe_extruder_temperature: current_temp=230.4, paused_extruder_temp=None, current_target_temp=230.0, klipper_minimum_temp=170.0, default_extruder_temp=200.0, source=auto
12:31:07   DEBUG: Setting servo to down (filament drive) position at angle: 140
12:31:08     TRACE: (extruder sensor detects filament)
12:31:08   DEBUG: Reverse homing up to 92.0mm to extruder sensor (synced) to exit extruder
12:31:10 Did not complete homing move: Unable to obtain 'trsync_state' response
12:31:10     TRACE: Reverse homing to extruder sensor. Stepper: 'gear+extruder' did not home after moving -92.0mm (of max -92.0mm), encoder measured 5.8mm (delta 86.2mm). Pos: @-154.0, (69.8mm)
12:31:10     TRACE: Running macro: _MMU_ACTION_CHANGED ACTION='Unloading' OLD_ACTION='Exiting Ext'
12:31:10 Error running _MMU_ACTION_CHANGED: MCU 'mmu' 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

[billgeek]

After digging further into my issue I found that my RPi 2B was actually just not powerful enough to run everything. I have an old Core i5 laying around and decided to hook that up and now everything appears to be working.

Definitely seems to be related to the performance of the host in my case.

[deathfrozen]

I have already tried a lot of things and do not yet understand what this might be related to in my case. My system is ERCF2.0. I have an BTT Octopus board - it controls the printer and mmu - connected via a good quality usb wire. I transferred linux to a usb ssd and it works much faster than an SD card. The board with linux - Orange pi 3 lts - with 2 GB of RAM and a 64-bit 4-core processor. The system load is 2-7% during printing and tool change. I installed the official Debian for my board, transferred a clean system to an ssd, locked the processor frequency at the maximum level and installed good cooling for all components of the board, using kiauh set the minimum configuration of klipper (klipper, moonracker, mainsail, klipperscreen), installed and configured Happy-Hare, and KlipperScreen Happy Hare Edition. I set everything up in a minimal configuration - no LEDs, no webcams and timelaps. This error still occurs. Load diagram from klipper: but I don't quite understand how to interpret these graphs, although it looks like the load is pretty uniform. The last thing I did was to hang the capacitor on the servo power supply - I think that when it is activated, there may be a voltage drop. But this also had no effect. I'm already thinking about buying a pi5, but it's many times more expensive than the Orange pi, and in theory the Orange pi has enough performance even with excess - I'm afraid it will be a waste of money. At the same time, long-term prints without changing the tool do not cause any problems.

[igiannakas]

What is your load and unload speed? Have you tried reducing it?

[deathfrozen]

Thanks for the advice. My speeds are:

gear_from_buffer_speed: 150 # mm/s Normal speed when loading filament. Conservative is 100mm/s, Max around 300mm/s
gear_from_buffer_accel: 400 # Normal accelaration when loading filament
gear_from_spool_speed: 80 # mm/s Use (lower) speed when loading for the first time (i.e. pulling from spool)
gear_from_spool_accel: 100 # Accelaration when loading from spool
#
gear_short_move_speed: 80 # mm/s Speed when making short moves (like incremental retracts with encoder)
gear_short_move_accel: 600 # Usually the same as gear_from_buffer_accel (for short movements)
gear_short_move_threshold: 70 # Move distance that controls application of 'short_move' speed/accel
gear_homing_speed: 50 # mm/s Speed of gear stepper only homing moves (e.g. homing to gate or extruder)

Now I'm thinking that maybe because of the under-processed files due to this problem - https://github.com/moggieuk/Happy-Hare/issues/263 . I fixed this error and started a test print. If it does not help, I will try to reduce the load and unload speed.

[igiannakas]

Yeah, too high movement speeds result in more interrupts / events to track. Both from the encoder but also the motors. if it doesnt work I'd go down to 80mm/sec for all movements and see whether this solves it. if it does, it's a processing power issue.

Personally with a RPI4 have not come across this error; but I used to have timer too close errors on occasion before with the BTT CB1.

[igiannakas]

@moggieuk Jinxed it. MMU timer too close error here too with an RPI4. Loading speed at 200mm/sec, Bowden correction move enabled, 16 micro steps on the stepper. Errored out at the end of the Bowden load move before doing homing to the extruder. In the graphs below its the spike around 23:00 or so

klippy.zip mmu-2.log

[appleimperio]

Update to my other post. I was having the same issue even when using a Raspberry pi 4 with 4gb. After many combinations the one that works for me is the Raspberry pi 4 but with the 32 bit OS. I am currently running Bullseye 32 bit. No more timer too close since then. Hope it helps.

[igiannakas]

Got another timer too close message today. Will install Bullseye 32 bit on my CM4 and see how that works. thank you for the suggestion!!

[Ambilights]

Another tip is to try set microsteps to 8 on MMU:Gear, even if you are running low gear_from_buffer_speed.

[igiannakas]

Another tip is to try set microsteps to 8 on MMU:Gear, even if you are running low gear_from_buffer_speed.

I’ve already had it set to 8. I’ve set it to 4 now just in case it helps. Don’t really need precise resolution here so lowering this doesn’t matter much.

I’ve installed bullseye 32 bit lite on my CM4 and testing with the above. Have also increased the tr sync timeout value to 0.05 and reduced my Bowden loading speed form 200mm/sec to 170mm/sec.

[igiannakas]

So quick feedback on my Timer too close error when loading:

Set up:

1. M8Pv2
2. RPI CM4 with 32 gig eMMC storage and 2gb ram
3. MMB v1.1 for the ERCF

Changes made: a) Install Bullseye 32 bit. Apparently later OS versions (bookworm) and the 64 bit kernel are more problematic with CAN. b) Setup CAN queues to be 128 bytes (as described here: https://www.klipper3d.org/CANBUS.html). c) Made sure CAN speed is at 1meg - it already was d) Reduced gear microsteps to 4 from 16. No need for the larger precision and it doesnt hurt to reduce the comms load over CAN. e) Increased TR Sync timeout to 0.05 f) Removed the forced homing to the extruder entry end stop. This is unneeded and it was a deviation caused by me in the stock config… This shouldn't be on by default, so if you have it enabled try disabling it as its unnecessary when having a dual sensor toolhead g) installed a bigger heatsink on the CM4. h) Increased klipper process priority

Things that didn't fix it on their own:

1. Reducing loading speed from 200mm/sec to 170mm/sec
2. Increasing TRSync timeout to 0.05
3. CAN queue to 128 bytes
4. Reducing micro steps on the gear motor from 16 to 8
5. Setting up a swap file to 1 gig from 100 meg.
6. Increasing klipper process priority

So it was either a) Bullseye 32 bit f) the forced homing move or g) the bigger heatsink or a combination of these three that have fixed it for me.

[moggieuk]

Sorry, late to this thread because I've been traveling.

This is a painful problem and I know it has been getting worse with a combination of things: kipper rework of "drip" homing, Linux updates in serial driver (especially 64 bit it would seem), the increased load of all the features we are adding to our Printers, Happy Hare's extensive use of homing moves both loading and unloading the toolhead.

It only takes a momentary pause in the rpi to cause a TTC but it can also be caused by too many retries send a message from MCU to rpi -- i.e. use quality cables and ferrite ring on communication cables.

I like all igiannakas other suggestions too.

Let's keep sharing ideas because there doesn't seem to be one magic fix for this. Also I'm not using CANbus and I have never had the issue on my 32bit Bullseye. Not saying I couldn't but its hard to try things without being able to reproduce the error.

[igiannakas]

To offer some feedback - after 2x 24 hour 500+ toolchange prints it seems stable for me with the 32 bit bullseye. I’ll stick with it for now. @moggieuk maybe worth putting that hint in the ttc troubleshooting guide? At least try a 32bit kernel as a step

[Deadleg]

Adding one more data point:

While printing an STL with ~500 tools changes over an expected ~20 hour print time a Timer Too Close error is always triggered during tool changes, without any invalid bytes or re transmits. I've found one factor that influences when the Timer Too Close error occurs:

• When running Happy Hare LEDs the print will consistently error 2-3 hours into the print.
• When running with variable_led_enable: False the print will error 17-20 hours into the print.

I am running a Siboor 2.4 Aug Build with a Triangle Labs ERCF V2.

The hardware consists of:

• BTT Pi V2 (previously used the BTT Pi V1 that came with the kit but it died. It had the same issues) running 64 bit armbian.
• Octopus Pro 1.0 (CAN)
• EBB2209 (CAN)
  • Cartographer (CAN)
  • 8 RGBW LEDs
  • Connected with the standard BTT CAN Bus cable.
• BTT MMU (CAN)
  • Connected with the standard BTT CAN Bus cable.
• Pi Pico (USB)
• 2 disco on a stick (36 LEDs)
• 8 Channel ERCF
  • 16 LEDs

I have tried:

• Turning off all LEDs.
• Disabling klipper-led_effects.
• Moving the disco on a sticks from the Octopus Pro to a dedicated PSU and controlled by Pi Pico.
• Running the gear in sync with and without the extruder.
• Decreasing the gear microsteps.
• Switching between toolhead entry sensor and sensorless homing.
• Optimizing klipper-led_effects which reduced idle Klipper CPU usage 10%-30%.
• Using different print settings in Orcaslicer (mostly unrelated to MMU operation other than purge volume changes).
• Running with KlipperScreen disabled.
• Increasing TRSYNC_TIMEOUT to 0.05

The timer frequency shows no trend towards failure, it just catastrophically fails (print runs from ~1:45 to ~2:45):

My gut feeling is that this is a software issue within the Klipper ecosystem. Given that klipper-led_effects is quite a busy library (even if you don't use any effects), it makes me think there's a memory leak where over time something like garbage collection or some kind of bug in the Klipper reactor code where there are too many tasks to run tippy the CPU usage over to a crash. Not sure how 32 vs 64 systems factor into that though.

I'm going to try re-write klipper-led_effects to use vectorised operations so see if that helps.

I ran py-spy early into a print during a filament unload which might provide some insights into what's happening. This might be a red herring though since (in my case at least) the error isn't entirely random.

[deathfrozen]

I bought a Raspberry PI 5 8gb, the official Raspberry 27 watt power supply, installed active cooling, a set-top box for ssd and ssd 240gb. After 12 hours of printing, this error occurs again. I installed the 64-bit Raspberry OS lite, because I thought that the bitness affects printers with a CAN bus (I do not have a CAN bus) - is this true, or should I switch to the 32-bit version?

[igiannakas]

Try the 32 bit version. Also make sure you’re not homing to the extruder end stop by forcing it to - this homing move can be problematic from my tests. Also make sure you setup your can bus with esotericals recommended settings - 1m rate, queue length and try increasing your timeout value in klippy

also at what move does it happen?

[deathfrozen]

I do not use the CAN bus in the printer - there is a full-fledged wiring to each component to the printhead. At the moment, it happened at the moment after cutting the filament, when the filament was going to the "entry" sensor in the head. I also saw a new error before "Timer too close": !! Did not complete homing move: Error during homing extruder: Unable to obtain 'trsync_state' response

[igiannakas]

Hmm that is interesting. Is the USB cable of good quality? That’s pretty much the only thing I can think off as you don’t run CAN

[deathfrozen]

I use a good shielded USB cable. The only thing is that it is quite long (meter long). I'll try to change the cable. I am already in the process of reinstalling 32 bit Raspberry OS lite.

[boer0327]

same problem for me. Just checked discussion on this channel. I think I need change my rpi 3b to a high performance device. Since this bug still no solution yet. I think it is better leave this issue ope is better. It will help to gather more useful info.

[deathfrozen]

I have installed the 32 bit version of Raspberry OS lite and a complete clean install. I replaced the USB cable with a shorter one and installed ferrite filters on it. I changed the power supply to a mean well of higher power so that there was a power reserve. But I still get the error after about 14 hours of printing. klippy.log logs_processed.zip

[boer0327]

I have tried everything above. But still same issue. I think there are definitely has a performance issue here. And it really happed when change filaments. Because it will all good, if just single color printing.

Since there are still no anyway to solve. I am plan to buy a x86 micro pc for host. At least, I can get this thing continue to work.

[deathfrozen]

Yes, printing with a single filament does not cause problems. But I don't think this is a problem with the performance of the host, because now I use raspberry 5 as a host - and it has much better performance compared to the orange pi3 lst, which I used earlier. In addition, raspberry 5 works better with peripherals and it has separate interfaces for ssd and camera. And still, despite all this, changing the host did not help me.

[boer0327]

But why host being shutdown fully? May PI5 also cannot afford this CPU cost? Anyway I have bought x86 pc. Let’s see how is x86 working for this case.

If there any other solution, I will never try this. Because it takes about a month to build ERCF v2. And try to debug and make sure everything is working. It is hard to give up this.

[nmsmith22389]

I didn't have any issues during ERCF V2 testing/tuning/config but as soon as I tried an actual print I get a mcu: Timer too close error on every single tool change (ie the 1st one at the start of the print).

I'm using MainsailOS which I kind of regret now because I'm pretty sure they use the 64-bit Bullseye.

Either way I still think these errors are kind of ridiculous... Back when I was using CAN on the Duet hardware/RRF I had ZERO problems so it's not like it's something inherent to CAN or impossible for the Klipper guys to fix.

P.S. I'm also using USB-Bridge so idk if that has any bearing.

Setup: RPi 4 -> LDO Leviathan -> splits to: Toolboard & BTT MMB

[deathfrozen]

I noticed that the LED for mmu loads my mcu very heavily (in the normal state it shows a load of 5%, when switching plastic with an active LED - 25% without LED - 5%). I recently completed a successful 19 hour print with the LED and display turned off. Now I'm waiting for the filament to be delivered to try another long print, because it might just be luck.

[JaymZZZZ]

I had the exact same issue running an unload just now. For me it occurred about 8 hours into a print. I have attached the relevant log, as well. Hopefully this can help you track down the issue. klipper.log

Model : Raspberry Pi 4 Model B Rev 1.5

[mrmultifunk]

I noticed that the LED for mmu loads my mcu very heavily (in the normal state it shows a load of 5%, when switching plastic with an active LED - 25% without LED - 5%). I recently completed a successful 19 hour print with the LED and display turned off. Now I'm waiting for the filament to be delivered to try another long print, because it might just be luck.

I noticed that too. I don't use LEDs on the MMU, but i do in the case and with the Stealthburner. I get Timer too close when probing the bed, almost always. This disappeared after removing led_effect.

[Deadleg]

I believe I have a fix:

On line https://github.com/Klipper3d/klipper/blob/6d70050261ec3290f3c2e4015438e4910fd430d0/klippy/toolhead.py#L509 change to if wait_time > 0.3 and self.can_pause:.

I say believe because even though I managed to complete a 20 hour print with 500+ tool changes, all of my Klipper related repos are dirty from me trying to adjust various settings to get rid of this error.

0.3 is a magic number that I picked from adding some extra logs to this function and seeing how much of a delay there was. Afaik this should be safe, it just handles how many extra moves are preloaded into the micro-controller.

Quick explanation

This function uses reactor.wait to stop Klipper from sending too many commands to the micro-controller. This function does not act like time.sleep, it depends on how many callbacks are registered in the reactor and how long they take to execute. So a wait of say 0.001 seconds is misleading because the reactor loop will spend more than 0.001 seconds processing callbacks before this one in the queue, so it could resume that function at say 0.1 seconds later.

In the case of drip moves the timing of each queue_step command is pre-computed and so if the wait is for too long, the microcontroller will complete its move queue and sit idle when it should have had additional moves. Then when this function sends the next set of queue_step commands, the pre-computed time has lagged behind the microcontroller clock trigger Timer too close.

In your logs you should see a dump of the serial queues, and for the MCU that has triggered the alert you should see the sequence number of the TTC match the sequence number of a queue_step command (offset by one).

Fortunately it's really easy to reproduce this wait lag behaviour. I'll get around to posting my findings on the Klipper discord this weekend.

[Squid116]

Great work digging into this, some of my logs seem to match the scenario you describe, so I am hopeful of this being a fix!

Another few of my logs show timer too close coming a few moves after the load sequence - could this be the same issue?

My build plate is clean, doing a heatsoak and will start a test running soon.

[Deadleg]

If it's still homing then yeah could be the same problem. Most of the time it's been during unloads, but I have seen it occur on loads once or twice. I think it's related to any homing move since I get TTC on xyz homing as well. Happy Hare has pretty decent logs so you should see (reverse) homing in the logs when it enters trace_filament_move which is where Happy Hare initiates the homing move.

[Squid116]

Test print failed :(

For me it seems to occur after homing, it restores the toolhead to the top of the purge block then stops. So I need to look into what happens after homing, we could have a similar situation. I wonder if changing variable_restore_xy_pos to false will help.

[deathfrozen]

Test print failed :(

For me it seems to occur after homing, it restores the toolhead to the top of the purge block then stops. So I need to look into what happens after homing, we could have a similar situation. I wonder if changing variable_restore_xy_pos to false will help.

You ran a test print with or without this change?

I believe I have a fix:

On line https://github.com/Klipper3d/klipper/blob/6d70050261ec3290f3c2e4015438e4910fd430d0/klippy/toolhead.py#L509 change to if wait_time > 0.3 and self.can_pause:.

I say believe because even though I managed to complete a 20 hour print with 500+ tool changes, all of my Klipper related repos are dirty from me trying to adjust various settings to get rid of this error.

0.3 is a magic number that I picked from adding some extra logs to this function and seeing how much of a delay there was. Afaik this should be safe, it just handles how many extra moves are preloaded into the micro-controller.

Quick explanation

This function uses reactor.wait to stop Klipper from sending too many commands to the micro-controller. This function does not act like time.sleep, it depends on how many callbacks are registered in the reactor and how long they take to execute. So a wait of say 0.001 seconds is misleading because the reactor loop will spend more than 0.001 seconds processing callbacks before this one in the queue, so it could resume that function at say 0.1 seconds later.

In the case of drip moves the timing of each queue_step command is pre-computed and so if the wait is for too long, the microcontroller will complete its move queue and sit idle when it should have had additional moves. Then when this function sends the next set of queue_step commands, the pre-computed time has lagged behind the microcontroller clock trigger Timer too close.

In your logs you should see a dump of the serial queues, and for the MCU that has triggered the alert you should see the sequence number of the TTC match the sequence number of a queue_step command (offset by one).

Fortunately it's really easy to reproduce this wait lag behaviour. I'll get around to posting my findings on the Klipper discord this weekend.

The context is just not entirely clear. I was hoping to check it out myself. But if it doesn't work, then there's no point.

[boer0327]

I am switched to 2.6, and run./install.sh. looks this version fixed this issue. But I am not sure which update fixed this issue, because I am also upgrade led_effect package.

I have test x86 and pi 3b, both working for me. But not too much time for testing. only for 6 more hour testing. For my case, old version will random throw ttc error. I will keep testing. I think you guys may upgrade and and testing.

[Marucci87]

I could kiss you Deadleg, after weeks of replacing/adding hardware, and dozens of failed prints yourn (if wait_time > 0.3 and self.can_pause:) has stoped my timer to close errors when exiting the extruder in a filament change, I would see errors in the first hour of a print or about 4 hours in but now I have 35 hours without a issue. I will be forever grateful everytime I look at my ERCF.

[d0m1n1qu3]

i yesterday updated to 2.6 and it runs good. but a print with 99 changes failed in the middle. what was your fix?

[deathfrozen]

I could kiss you Deathfrozen, after weeks of replacing/adding hardware, and dozens of failed prints yourn (if wait_time > 0.3 and self.can_pause:) has stoped my timer to close errors when exiting the extruder in a filament change, I would see errors in the first hour of a print or about 4 hours in but now I have 35 hours without a issue. I will be forever grateful everytime I look at my ERCF.

It is necessary to kiss Deadleg - this is his suggestion for correction. I also changed this parameter, but I have not yet been able to make a long enough print for verification. I'll try it later too. But it's great news that it worked for someone!

[d0m1n1qu3]

for me this was not the fix ..

On line https://github.com/Klipper3d/klipper/blob/6d70050261ec3290f3c2e4015438e4910fd430d0/klippy/toolhead.py#L509 change to if wait_time > 0.3 and self.can_pause:.

i added also 0.3 and compile all firmwares and upload to devices ..

it work much better than befor but it comes the time an klipper crashes with timer too close :-(

[Deadleg]

Small update to my fix: need to reduce the wait time as well:

            if wait_time > 0.3 and self.can_pause:
                # Pause before sending more steps
                self.drip_completion.wait(curtime + wait_time - 0.3)

I updated everything except Klipper itself over the weekend and the timer too close errors came back with a vengeance, with it occurring during homing moves and regular moves.

I don't know which component update has caused this, I can't see anything in Happy Hare 2.6 that could be an obvious call and the change to saved variables should have reduced to likelihood of a TTC.

I added a bit more logging and some potential routes to investigate are:

• I see tmc._do_periodic_check sometimes takes ~0.1s to complete which is a very long blocking call in the _check_timers loop.
• The objects/query webhook grows a fair bit with all of the extra MMU macros (resulting in many gcode_macro.get_status calls). The call itself seems fast, but the subscribers seem to be grabbing everything so the time spent serializing a giant dictionary then sending it to the socket could be enough to trigger a TTC.

[Marucci87]

well after about 40 hours it came back, I started seeing it again every hour or less. SO I had the ercf on usb trying to fix this issue since if were on the can network it would fail in the first few filament changes. Now I moved away from using btt pis to a pi5 and now its really fixed without a doubt....65 print hours and mmu back on the can network BUT! My pi was doing fine on the wifi and all of a sudden I cant get it to connect unles its 3 foot away from the router...my router is upstairs aboiut 45 foot away but after 3-4 days with no wifi issues I cant figure out what changed I can only get wifi with the pi5 about 3 foot away from the router.....I just cant win with this project.

[Marucci87]

Who here thats having the issue is using a BTT pi? After installing a Pi5 I have not seen this error at all so I tried installing a pi4 B and still no error, put in a btt pi 1.2 issue happens, put in a btt pi2 issues happens , back to pi 5 all good, so for me it apprears it has something to do with btt's pis.

[d0m1n1qu3]

i run on a rpi 3b+ and have the issue