This is a set modifications to the kinematics parameters that I developed on my printer. The end goal is to allow the printing time to be dynamically changed while preserving the distances over which the toolhead accelerates, cruises, and decelerates.
I make this topic for judging interest and to discuss the naming, compatibility and user experience issues.
It is a bit of a misnomer with the current Klipper implementation.
max_accel is not a upper bound on acceleration but the acceleration of every accelerating segments. Only cruising segments have lower acceleration, equal to 0.
Another surprising fact to newcomers is that the value set with
[printer] max_accel: in the config, the value set by
SET_VELOCITY_LIMIT ACCEL=, and the value set by the slicer through
M204 are all assigned to the same internal parameter.
The issue is that, when using dynamic acceleration settings in the slicer, it’s is not possible to adjust the acceleration during the print on the fly from the front-end. It would be useful to have an acceleration override factor similar to the Speed factor override
M220 S<percent>. 
max_ prefix is a bit superfluous. But more importantly, this feature is often misunderstood, as evidenced by the fact that the mainsail front-end labeled it “Deceleration” for a long time.
It has nothing to do with a counterpart of the acceleration for the deceleration of the tool head. Instead, the smoothed look-ahead feature of the motion planer uses this parameter to lower the maximum velocity reachable by a set of moves accelerating together. When
max_accel_to_decel < max_accel, it enforces that a portion of the distance is traveled at cruising velocity before deceleration. For example, if
max_accel_to_decel = (3 / 4) * max_accel, it ensures that at least 1/4 of the distance covered by a trapeze is traveled at cruising speed.
Viewed this way, It is clear that the effect of
max_accel_to_decel is relative to the value of
max_accel. Most users of dynamic slicer acceleration use an overloaded
M204 macro that sets both
max_accel_to_decel, keeping the proportion. While this works, the ratio can’t be changed on the fly. I’d rather have something like:
This tells explicitly that 25% of the distance of a group of moves accelerating together is cruised.
max_accel_to_decel is set to 75% of the acceleration, regardless of its value.
0% is an obvious value to disables this feature.
This sets the toolhead velocity when cornering at a 90° angle.
The default value of 5 mm/s is recommended for entry level level printers. On the worst printers, exceeding this value would skip steps on the steppers if Input Shaping is not enabled. When IS is setup, this would result in smoothing, unacceptable for extrusion moves.
However, with IS, the cornering velocity of travels can be set much higher (I use 20-25 mm/s on my ender 3). Smoothing is not an issue with a reasonable “travel avoid distance” set in the slicer. The suggestion here is to scale the square corner velocity proportionally to √accel. With dynamic acceleration set in the slicer this would allow the travels to corner much faster, while preserving the extrusion move from smoothing, with special care for the outer walls.
This is in fact what old versions of Klipper were doing. The junction velocities were set by a
junction_distance parameter and a max centripetal acceleration equal to
max_accel. It was proved difficult for the users to relate this to actual cornering velocity.
square_corner_velocity was added and KLipper solves for the
junction_distance that would result in a 90° cornering velocity at the current acceleration setting.
A side effect of this is that acceleration changes from the slicer now affect the junction distance. I’d argue that the junction distance is the real machine dependent parameter here, and that it should be derived from the maximum acceleration set in the config instead of the dynamic one. This is equivalent to scaling
square_corner_velocity proportionally to the square root of dynamic acceleration, as suggested above.
Given a factor
k, if you scale:
- The gcode velocities by
max_accel_to_decelby a factor
square_corner_velocityby a factor
Then you’re scaling the print time by
k while preserving the distances over which the toolhead accelerates, cruises, and decelerates.
Users often find surprising that cranking up the “speed override factor” (
M220) doesn’t increase the print speed. This is because the acceleration is too low for reaching the increased requested velocity. If the accelerations are set by the slicer, there is currently no way to increase them on the fly.
Well, first I want to thank you if you’ve made it this far
I have all the behaviors suggested in this post implemented and working reasonably well on my printer.
Now, it is unclear to me how to implement the user facing aspects of this proposal:
M220be replaced with the “global speed control” or should a separate control be introduced?
- How to manage the derived kinematics parameters without introducing “hidden behaviors” that would be confusing for newcomers?
- Many problems that I did not foresee.
I’m already using something similar where the actual acceleration is equal to
<slicer accel> * <SET_VELOCITY_LIMIT's accel> / <config's max_accel>, with two separate variables, one set by the the slicer with
M204and one set by the front-end with
SET_VELOCITY_LIMIT. Thus, in the front-end the “Acceleration” value is unaffected by the slicer dynamic acceleration and modifying it scales the acceleration accordingly. ↩︎