Hi there,
I started reverse engineering the input shaper implementation the other day and I think I found a bug in resonance_tester.py in the run_test function. Basically, if I am not mistaken, the frequency in the while loop, where you iterate through it is not reached by the movement, but something off by factor 1/sqrt(2).
It is a bit hard to fully explain it in detail here, but basically, you calculate L so it would reach v_max in 1/(4 f) with constant acceleration. You want that movement to last 1/ (2f). Now looking at how the movement is actually executed by klipper, it will accelerate half of the time and then decelerate. This results in a movement time of 1 / ( sqrt(2) 2 f ).
I did a small video on the derivation I did:
Someone on our discord probably came up with the solution:
the first movement is to the right, then we move back to center and in the next loop to the left.
Assuming the loop is fast enough for the movement queue to not dry out, it should than put those two movements together to a constant acceleration. So the frequency is something like f= f/2+(f+df)/2 which is very close to f.
So we constantly accelerate from x+dx to x and constantly deaccelerate from x to x-dx and this gives us the full cirlcle, thanks to the look ahead seeing it going into the same direction.
Is this right? If so, there is no real bug, only the unnecessary max_v calculation.
Yep, I believe there is no bug. It is pretty much as MarschallMarc explained. t_seg is 1/4 of the full period, and the movement goes from, say, X-L at 0 velocity to X at max_v, then decelartion to 0 at X+L, then the same cycle from X+L to X-L, and so forth. It can be confirmed with graph_accelerometer.py -s which shows the spectrogram in time, and one can see that the frequencies are reached when expected. And yes, max_v is, in principle, constant, equal to accel_per_hz / 4. It is calculated every time just for the sake of code readability.
