Well, 400_000_000 is a timer resolution from the log. i, and a are also in the same type of numbers (ticks). Interval of steps, Count of steps, Add (per step) this amount to the interval, per step.
We talk about the same MCU there, so STM32H7.
If I know the available ticks per second and the expected interval of steps at the same time, I can estimate the steps per second value from the queue data.
And it is available in the docs:
To explain my estimations, there is just too much context to add to be able to explain.
This one Klipper 400MHz limitations - #17 by nefelim4ag
Maybe useful, also, there is a GH link above, there is also plenty of related information.
It should be enough. MCU only stores less than 300 ms of future data.
PWM and GPIO use even less, probably 1 item per 300ms interval.
Link to the docs: It is the responsibility of the host to ensure that there is available space in the queue before sending a <mark>queue_step</mark> command. The host does this by calculating when each queue_step command completes and scheduling new queue_step commands accordingly.
If you want to invest time here, it will make sense that you do that on a pristine firmware or at least without disabled sanity checks.
Most probably, you will get “Stepper too far in the past”.
Now, you probably want to update (as suggested above), compile, and disable the TMC’s step on both edge optimizations.
[ ] Optimize stepper code for 'step on both edges'
That should make it fast enough.
Then, if you are still seeing that “Stepper too far in the past”.
(I doubt that)
[printer]
kinematics = cartesian
max_velocity = 1500
[stepper_x]
microsteps = 16
rotation_distance = 3.2
step_pulse_duration = 0.0000002
1500 / 3.2 = 468.75 rot/s
200 * 16 * 468.75 = 1_500_000 steps/s
For diagonal moves: 1_500_000 * 2 * 0.707 = 2_121_000
I think the currently available performance should be enough.
There are some additional things, that can be done and which are not yet merged.
Hope that helps.