Hi,
While debugging an unrelated problem (parsing of scientific notation in gcode), I added a check to itersolve.c:itersolve_gen_steps_range to make sure it wasn’t trying to instantaneously change a stepper’s position by more than a few steps. That check sometimes fails.
While debugging that, I noticed that itersolve_gen_steps_range sometimes is called with an abs_end time before the abs_start time. Is that supposed to ever happen? The limit checks inside the function don’t seem to explicitly forbid it, but it seems like a strange thing to request.
FWIW, I don’t recall if that is by design or not. The caller (itersolve_generate_steps()) is fairly complex, so it is possible I relied on proper handling in itersolve_gen_steps_range() to avoid extra boundary checks in the caller.
Hi Kevin,
I’ve done some more testing and it looks like allowing itersolve_gen_steps_range() to be called with end < start can result in steps being generated with zero delay between them (i.e., infinite acceleration).
I prepared a small change that raises an error if itersolve_gen_steps_range() is going to try to generate such steps. And it looks like calling itersolve_gen_steps_range() with end < start can trip that check. Can you take a look at the diff and see if it’s worth developing in to a pull request?
The history of this issue that I accidentally generated g-code with scientific notation, like “G0 E3.5e-5”. That caused an error to be thrown in stepcompress. Debugging that showed that itersolve_gen_steps_range() was generating steps with no delay between them. Debugging that showed that itersolve_gen_steps_range() was trying to instantaneously change the stepper position.
Can you provide a gcode file along with the resulting klipper log file (running the pristine klipper code) showing the error? If I can reproduce the error in “batch mode” it makes it easier to trace the issue ( Debugging - Klipper documentation ).
I just tried playing around with vanilla gcode and a pristine klipper in batch mode and I can’t reproduce the fast stepping so far.
In my fork I added a g-code command to explicitly and independently control acceleration of extruder and toolhead (I’m looking into extruder flow modelling and explicit control makes experimenting easier) and the test gcode I’ve been generating uses that new gcode, so it’s hard to generate equivalent vanilla g-code.
I’m fine with sitting on the change until I can reproduce it in mainline klipper or something close to mainline.
As a side note, I sometimes toy with adding some notion of invariant checks to klipper, maybe that only run in a “debug” mode. It’d be handy, partially as documentation, and partially to see if klipper is behaving in unexpected ways (eg trying to take steps infinitely fast, or moving backwards in time). Might be especially useful in the more complex code, like itersolve_generate_steps() and the toolhead:MoveQueue:flush() code.