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

[DummyBot]

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)”.

    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.

[nefelim4ag]

@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

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?

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.” [image] I tried to implement the convex hull approach from this paper, 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.