Yes! Thank you for running these tests and providing the detailed analysis.
I agree we should change Klipper so that it does not flush the lookahead queue on simple SET_PRESSURE_ADVANCE commands. (Indeed, Dmitry has submitted a PR and we should be set to merge it in a few days.)
Just for my understanding, when you say “adaptive PA” you are referring to issuing SET_PRESSURE_ADVANCE commands between moves? (That is, not Klipper code modifications that automatically alter the PA value according to acceleration/velocity.)
That is correct Kevin- it’s just a feature name for using the slicer to send PA commands during the print (depending on feature volumetric speed, acceleration & type).
And thank you both for making this work on klipper - this is an exciting area to experiment in
It emits the new PA based on certain conditions and overrides - eg if the new PA differs from the existing it emits a PA change command. Similarly if that line segment belongs to an external perimeter and the flow change happened because of an overhang, it checks whether the user wants the PA adjusted for that feature type and emits it accordingly. Lastly if it’s a bridge, it reverts to a fixed value etc.4.
The PCHIP interpolation method was selected as it always has 0 error vs the calibrated values and it avoids oscillations and trend line deviations that can happen with cubic or spline or similar. (Eg notice below that some models vary significantly from the calibrated values and others, like the cubic model, do a “dip” before rising up to the final PA value). The PCHIP interpolation simply creates smoother slopes in those areas by definition.
Any plan of pushing a PR to have dynamic PA calculated in firmware, which is the component which knows best the current acceleration and speed, instead of relying on continuous GCODE commands to change the PA settings?
