Independant acceleration limits for X and Y axes

Hi!

I’ve been using different accelerations and velocities limits for X and Y on my E3Pro for the past two years. Now that the code has been tested a bit by the community, I decided to share it here.

Here is the code: limited_cartesian.py
It is implemented as a kinematic implementation file. This way, you can simply put the file under klippy/kinematics/[1] and change your kinematics to kinematics: limited_cartesian. The syntax for the axis limits are the same that the ones for Z, max_x_accel, max_x_velocity, etc.

To get all the speedup benefits, main max_accel and max_velocity should be set to the hypotenuse: √(x²+y²). There is a new gcode command SET_KINEMATICS_LIMIT which will show these values and at what diagonal angle they are reached.

If you set accelerations per feature type in the slicer, and have tuned your acceleration to get similar resonance amplitudes and smoothing on X and Y, you may want to enable scale_xy_accel: true. This will scale the X and Y accelerations by the ratio M204 acceleration / config.max_accel. For example, if you have max_accel: 10000 in your config and set in the slicer an acceleration of 5000 mm/s² (M204 S5000), effective max_x_accel and max_y_accel values will be halved compared to their original values set in the [printer] config.
Otherwise, with scale_xy_accel: false (the default) they behave as machine limits, like max_z_accel and max_z_velocity always do.
Gcode velocities are not scaled per axis and stay isotropic, as long as they are not reaching max_x_velocity and max_y_velocity. This way, extrusion moves get isotropic velocities and anisotropic travels velocities are adapted to the most prominent axis.

The corexy version has not been tried and tested enough, but it should work. There is no velocity per axis since the same steppers are used for both X and Y. Whereas cartesian printers may have motors with different characteristics on X and Y (inductance, and therefore torque pull-out velocities). However small CoreXY machines still benefit from lower Y acceleration since it moves the gantry which is heavier than just the toolhead. One CoreXY, the X and Y accelerations don’t immediately translate into a torque load of the A and B motors, so the calculations are a bit more complicated.

klipper_estimator should support the limited_cartesian settings out of the box, with the exception of scale_xy_accel. I’m working on a patch.

Note that there are print quality concerns with anisotropic accelerations and velocities. This is the main reason that previous attempts to upstream something like this failed.
Thus, user reports of any kind are welcome!


  1. This is intended to help people with little knowledge of git. More advanced users may cherry-pick the commit or merge the branch and set the correct pull policy to follow upstream. ↩︎

Interesting, thanks for sharing.

Does this also allow for higher speed and acceleration depending on the movement angle of the toolhead on CoreXY printers? I.e., when the toolhead moves at 90 degrees, both motors are running, when the toolhead moves at 45 degrees, only one motor is running. Thus, 90 degrees movements should allow higher acceleration and speed, or?

Exactly!

This plot shows the speed of the motors (yellow and blue lines) as a distance from the center:


At 45°, only the motor A is running at twice the toolhead velocity. At 90, A and B are moving their belts at the speed of the toolhead. Assuming that the enclosing circle represents the limit of the motors, the printer is only reaching for their max velocity on the 45° diagonals.

The thick purple line represents the toolhead velocity when hitting max speed. It is drawn as a circle because the velocity is the same in every direction. Now if we apply the limitations of limited_corexy, we instead get:

The max velocity is more limited at 45° than at 90°. But now, when the toolhead reaches maximum velocity, there is always at least one motor working at it’s maximum rate.

Cartesian kinematics are the same story, but rotated by 45° and with the square being circumscribed instead of inscribed.

1 Like

Awesome, thanks for the explanation :slight_smile: