General comments:
- It is preferable to do iterative changes, piece by piece.
- Do not mix the refactoring with functional changes.
It is harder to grasp. Just imagine, if Kevin, for example, with comparable changes in the raw line count, just squashes it: Centralize host motion flushing by KevinOConnor · Pull Request #7014 · Klipper3d/klipper · GitHub
This is a part of the task: write commits and change the code in a way that would be readable to others.
About the motion subsystem, general rule - there should be no speed jumps or infinite something. This is part of the reason why there is an integration logic - to smooth.
About the performance, I would suggest you do the testing with the Klipper batch mode:
At least like that:
# It is enough to disable not used things, make a dummy MCU dict (just compile your MCU)
# Also set G28 at the start of the file, or SET_POSITION...
time python3 klippy/klippy.py rp2040_printer.cfg -a /tmp/klippy_uds -i ./Cube_0.1mm_PLA_19m36s.gcode -d out/klipper.dict -o /tmp/dummy.serial
That will give you a rough idea of how fast/slow it is.
About the testing, you can take a look at:
# Record the data:
./scripts/motan/data_logger.py ~/printer_data/comms/klippy.sock /tmp/stepcompress_patched
# View the data:
./scripts/motan/motan_graph.py -g '[["deviation(angle(mt6826s),stepq(stepper_x))"],["deviation(angle(mt6826s),kin(stepper_x))"],["adxl345(adxl345,x)"],["adxl345(adxl345,y)"],["derivative(stepq(stepper_x))"],["step_phase(tmc5160 stepper_x)"]]' ./stepcompress_patched -s 0 -d 10
Also, it could help you:
- Modification of Pressure Advance for high speed Bowden printers - #13 by dmbutyugin
- Pressure_advance_smooth_time skews pressure_advance
(Generally, there is code somewhere, as in the above case for PA simulations).
Hope that helps.