Force steady speed segment in accelerate-decelerate moves to reduce vibration and facilitate input shaping

[T3P3]

Also means input shaping can be applied to the short segments see "Input shaping with short moves"

https://forum.duet3d.com/topic/27840/input-shaping-why-not-effective-on-some-parts-at-all/17?_=1682277139833

[dc42]

This potentially comprises two parts: (a) if the move is long enough that input shaping is desirable, reduce the top speed so that input shaping can be applied; and (b) if the move is too short to sensibly apply input shaping (e.g. for short zigzag infill moves) or if input shaping is disabled, optionally reduce the top speed so as to reduce vibration at the expense of speed.

[tombrazier]

@dc42 Short zigzag moves are the ones that most need input shaping. There is a common misunderstanding that it is just acceleration and deceleration ramps which cause layer shifts and ringing artifacts. The other major cause (which can be a lot worse than accel/decel) is the sudden change of velocity when cornering. (What is sometimes called "jerk", not to be confused with the "jerk" that is the derivative of acceleration.) And when step velocity changes happen in combination with acceleration/deceleration it is even worse. And the very worst is when it all happens repeatedly in quick succession at a frequency close to the resonant frequency. That's what short zigzags or short start-stops do.

This is why input shaping needs to be applied to the entire movement sequence as a convolution with a series of impulse functions. Or, in less technical language, scaling and time shifting multiple copies of the movement sequence and adding them together.

[dc42]

@tombrazier I take your point about jerk (in the sense of instantaneous velocity change) affecting input shaping. However, RRF only applies jerk when there is a change in direction with continues extrusion, and we have always recommended that jerk be set as low as possible while being able to print curves smoothly. Where jerk is applied, it is always between moves, so the IS in RRF could be extended to take account of it too. The disadvantage of using a continuous convolution that extends across moves is that it causes the tool head to no longer follow the requested path, which is why we have resisted it. Nevertheless, we are keeping this under review. Meanwhile, we have implemented input shaping on accelerate/decelerate moves.

[dc42]

IS is now implemented on many accelerate/decelerate moves in the 3.5-dev source. Results on toolchanger with Hemera tool are looking good. Further testing is needed. Limiting top speed for vibration reduction when no IS is applied has not yet been implemented.

[tombrazier]

The disadvantage of using a continuous convolution that extends across moves is that it causes the tool head to no longer follow the requested path, which is why we have resisted it.

Indeed. And linear movements can become curves, which has its issues for implementation.

However in terms of the physical dynamics of the printer, the print head diverges from the requested path regardless of whether input shaping is applied to corners. Without IS the trajectory will always overshoot on corners (unless movement comes to a complete stop which causes problems with extending print time and creating blobs). On the other hand, IS will instruct the print head to cut corners. With the two effects combined they somewhat ameliorate each other (although generally they do not exactly cancel each other). And both effects scale with the jerk and acceleration, so there is more overshoot from inertia on exactly the same corners where there is more undercut from IS.

In practice, I find that input shaping results in better conformity to the model than printing without input shaping.

[AndyEveritt]

Testing with this print object that has various short move lengths shows an improvement but there is still significant ringing following a short move.

For both images, the top part is using 3.5.0-b4, bottom part is using 3.5.0-b4+ with the changes