# If I need a shorter action time, avoid mistakes like "Timer too close"

**URL:** <https://klipper.discourse.group/t/if-i-need-a-shorter-action-time-avoid-mistakes-like-timer-too-close/23083>\
**Category:** Developers\
**Created:** [April 19, 2025, 7:56am UTC](https://klipper.discourse.group/t/if-i-need-a-shorter-action-time-avoid-mistakes-like-timer-too-close/23083 "2025-04-19T07:56:23Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![DummyBot](https://avatars.discourse-cdn.com/v4/letter/d/e47774/32.png) [@DummyBot](https://klipper.discourse.group/u/DummyBot)\
**Post date:** [April 19, 2025, 7:56am UTC](https://klipper.discourse.group/t/if-i-need-a-shorter-action-time-avoid-mistakes-like-timer-too-close/23083/1 "2025-04-19T07:56:23Z")

</div>

I’m using klipper for an ink-jet 3D printer.

Because the platform moves very fast,at the same time, the two inkjet printing heads are very close to each other, so I need to set a very short time to ensure that the images of the two inkjet printing heads can be accurately aligned.

I need to set the ink-jet action in a very short time by “self.reactor.register\_callback(call\_back, target\_time)”.

```auto
    def cmd_JET_ENABLE(self,gcmd):
        delay_time=gcmd.get_float('DELAY_TIME')
        current_time = self.reactor.monotonic() 
        target_time = current_time + delay_time
        
        for channel in self.channels:
            call_back=lambda e, s=self, ch=channel: s._jet_task(ch)
            self.reactor.register_callback(call_back, target_time)
            target_time=target_time+ delay_time

```

What areas (both hardware and software) can I improve?  
I have some thoughts:

1. Will usb and canbus have different effects on the short time setting of reactor?
2. Can the accuracy of time setting be improved by using stronger stm32?
3. Other things I hadn’t thought of.

---

<div class="post-metadata">

**Author:** ![nefelim4ag](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/nefelim4ag/32/2387_2.png) [@nefelim4ag](https://klipper.discourse.group/u/nefelim4ag)\
**Post date:** [April 19, 2025, 2:16pm UTC](https://klipper.discourse.group/t/if-i-need-a-shorter-action-time-avoid-mistakes-like-timer-too-close/23083/2 "2025-04-19T14:16:58Z")

</div>

> [@DummyBot](#):
>
> Will usb and canbus have different effects on the short time setting of reactor?

AFAIK, USB2CAN has the lowest latency: [Klipper: communication bus tests](https://klipper.discourse.group/t/klipper-communication-bus-tests/18781)

But there is no such thing as the shortest time. Klippy works in the future and schedules commands to the MCU, in the future.  
The shortest time what you probably would get:  
MCU sends a command to the host: the thread for that MCU gets the command and does some work.  
An example is how the ADC + PWM is done. But PWM is scheduled +300ms ahead, you probably could get as low as 100ms in a tight environment.

So, basically, TTC happens, when you schedule cmd too close to the actual MCU time.  
So, they are arrived in the past.  
This is why, you mostly can’t get away from the time schedule +Nms offset.

> [@DummyBot](#):
>
> Can the accuracy of time setting be improved by using stronger stm32?

IIRC, Reactor uses the host MONOTONIC\_RAW for internal scheduling.  
And the schedule cmds to the MCU according to the MCU’s expected clock speed.

> [@Does it make sense to actually sync mcu clock speed?](https://klipper.discourse.group/t/does-it-make-sense-to-actually-sync-mcu-clock-speed/21468):
>
> Disclaimer: There is no problem, it’s just my curiosity and maybe a little perfectionism. I spent some time looking at the clock sync. My initial thought was, “I see a time deviation on the graph. Can I improve that deviation? Maybe different clock synchronization will make it better.” I tried to implement the convex hull approach from [this paper](https://www.researchgate.net/publication/3958812_Clock_synchronization_algorithms_for_network_measurements), and it does not provide any benefits, which confused me. Then after some digging, I realized there is no “synchronization” underneath and…

So the real question is, what sort of accuracy do you want?  
With all the scheduling, it should be possible to sync events at sub-millisecond accuracy between MCUs.  
On one MCU, all time-critical things are done one by one.  
Like, steps for 2-steppers (XY) are interleaved. So, you see them spinning “simultaneously”.  
So, those would really depends on what sort of things do you do.  
More powerful MCU, just can do more things per time slice. That is it.

Hope that helps.

* * *

Ah, yes, if you really want “tight” timings across the board, you probably want to have all MCUs running from the same clock source (and SBC).  
I suspect this is a tightest time setup that you could get.