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
To download: click “Raw” then “Save As” the page. It is implemented as a kinematic implementation file. This way, you can simply put the file under
klippy/kinematics/ and change your kinematics to
kinematics: limited_cartesian. In order to activate the changes, you must restart the klipper process:
sudo systemctl restart klipper or reboot. *
RESTART gcodes are not enough.
The syntax for the axis limits are the same that the ones for Z,
Note that X and Y always indicate the cartesian axes even on CoreXY: perpendicular and parallel to the gantry, respectively.
- The resonance tester for shaper calibration expects being able to raise the acceleration limit. It does this using
M204, which means that moves for the vibration test continue to be limited by the axes limitations of these kinematics modules. This lowers the resonance amplitudes at high frequencies. This patch fixes this issue.
- Square corner velocity will be reduced on axis-limited moves by a factor of
√(limited accel / commanded accel). This can be fixed using this patch.
- See the quality warning at the bottom of this post.
The work-peraxis branch contains the
kinematics/ files and both patches mentioned above.
For optimal speedups, the primary
max_velocity should be set equal to or higher than the result of the square root of the sum of their axis configuration values, √(x² + y²). A new gcode command
SET_KINEMATICS_LIMIT has been introduced, which displays these values and the angle at which they are achieved. If not set accordingly, the acceleration will be capped at the maximums when they are reached. The next figure demonstrate how
max_accel abd `max_[xy]_accel`` interact with each other.
If the slicer lowers the acceleration by utilizing the
M204 gcode command to adjust
max_accel, the circle in the above figure may no longer intersect with the horizontal and vertical axis limits, resulting in the same acceleration being applied in all directions. This typically leads to printed features having constant acceleration, which is beneficial for maintaining extrusion consistency.
However, if you have previously fine-tuned the axis accelerations to achieve similar resonance amplitudes and smoothing in X and Y, you may want to preserve that X/Y ratio at all times by enabling
scale_xy_accel: true. This will adjust the X and Y acceleration limits by scaling
M204's acceleration / √(ax² + ay²).
For example, if you have
max_x_accel: 12000 and
max_y_accel: 9000 in your config,
limited_cartesian will limit the acceleration to
max possible acceleration = 15k on 37° diagonals.
When the slicer sets acceleration of 5000 mm/s² (
M204 S5000), effective
max_y_accel values will be the third of their config values.
The corexy version is tested as much as the cartesian version, but it should work in principle.
Unlike Cartesian printers which may have varying motor specifications for the X and Y axes, CoreXY machines use the same steppers for both axes and thus do not have any velocity restrictions per axis. However, it is still beneficial to have a lower acceleration for the Y axis as it moves the heavier gantry. Acceleration and velocity for diagonal movements are reduced to align with the available torque and speed of the recruited stepper(s).
SET_KINEMATICS_LIMIT reports the minimum acceleration and its angle. The maximum, usually aligned with the X axis, is set by
klipper_estimator should support the limited_cartesian settings out of the box, with the exception of
Note that there are print quality concerns with anisotropic accelerations and velocities. Extruder pressure and lengths of accelerating segments will depends on the orientation. In theory this could lead to dimensional discrepancies. This was the main argument for rejecting previous similar PRs.
Thus, user reports of any kind are welcome!
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. ↩︎