Klipper: Configuring velocity/acceleration for X & Y axes independently?

Created on 21 Sep 2018  路  10Comments  路  Source: KevinOConnor/klipper

Hello! Is it possible with Klipper to specify the velocity and acceleration parameters for the X & Y axis independently?

In the [printer] section of the config file, it appears as though _max_velocity_ and _max_accel_ both operate on the X & Y axis as a pair, and _max_z_velocity_ and _max_z_accel_ then operate on the Z axis.

I'm sure I'm not alone in this, but my descending-bed cartesian (non-CoreXY) printer has substantially less moving mass and mechanical complication on the X-axis than the Y. As a result, I have to configure the speed parameters to the lowest maximums - the highest values the Y-axis can tolerate - leaving a fair amount of potential performance capability wasted in the X-axis.

I would think that machines with a horizontally moving bed as the Y-axis would have an even larger mass difference, and could in their own way benefit from separate X/Y acceleration values for print stability reasons.

Is there a hidden configuration option I am missing, or are there perhaps technical reasons why these speeds are linked?

Thanks in advance.

Most helpful comment

Imagine what bad results that will give...

Luckily we don't _need_ to imagine, because Marlin, RepRapFirmware, Smoothieware, Sprinter, Teacup, and Repetier-Firmware all support independent X/Y speed and acceleration values. (Every firmware I checked did.) So we can just load one of those, run some tests, and see what happens.

Spoiler: In practice, dissimilar speeds are no problem at all. :-)

I made a quick 50mm cylinder in OpenSCAD (2018.03.07):
cylinder(20, 50/2, 50/2, false, $fn=120);

... then reloaded Marlin 1.1.8 on my FT-5, and printed a reference print with matching X/Y speeds and matching X/Y accelerations. G-Code was sliced using Cura 3.4.1, spiralizing the outer wall so it prints as a single continuous line with smoothed continuous Z-movement. (I used a brim for stability, so please ignore the bottom few layers in each test piece.)

I then iterated through a number of changes... firmware, slicer settings, etc, until I thought I had a good example of a clearly unbalanced X/Y print. I have included photos of the test print set, as well as the first and last together. They are almost indistinguishable in person, so I had to label them.

img_1095 - resized

I have also included a short video of number 6 printing, so that you can see and hear the speed ramp up and down as the extruder whips around the two X-axis runs of the circle.
IMG_1086 - Resized.mov.zip

Number 6, with the unbalanced X/Y speeds, is the best print of the batch. I'm lucky there is a tiny nick where the top layer extrusion ended, otherwise it would be impossible to tell how the print had been oriented on the print bed, or which sections had been printed fast vs slow. There is NO perceptible impact in the print quality from the unbalanced X/Y speeds, other than a slight change in glossiness which I attribute to the fact that I was printing these a bit cold to avoid having sags from single perimeters with the short layer time.

img_1109 - resized

If you take a step back, you will see that our printers change speeds all the time when printing different shapes. Synthetic tests like circles, squares, and stars, and everything irregular or organic. Large shapes that let the extruder ride the max speed for long stretches, and shapes small and complex enough that it doesn't ever have the room to get up to full speed. It's not a problem. :)

Hopefully this helps dispel some of the concerns...

All 10 comments

This looks like a duplicate of issue #256 (the same concern with different maximum velocity would apply to different acceleration).

-Kevin

Thanks Kevin. I agree that I am asking the same question as #256, but still believe there are a number of reasons why separating the axes would add value to Klipper and benefit its users.

I'm tied up with work today, but would you be willing to keep this issue open for a short while, for me to present a justification?

Hi, if it were possible and not too difficult to implement this feature I think the option would be a good one.
In most Cartesian printers the Y axis is much heavier than X axis, so at any given speed ringing is always more evident on the Y axis. If the printer could be slowed down for Y only, ringing could/would be reduced or eliminated.
Just my view on this subject.
Thanks and regards - bruce

I think you guys are missing the actual reason why this is not a good idea.

Imagine trying to draw a round circle on a piece of paper, but all Y moves are slower that X moves. It would make for a horrible looking circle, and added that the Filament extrusion now needs to go "fast and slow" around this circle, Imagine what bad results that will give...

Imagine what bad results that will give...

Luckily we don't _need_ to imagine, because Marlin, RepRapFirmware, Smoothieware, Sprinter, Teacup, and Repetier-Firmware all support independent X/Y speed and acceleration values. (Every firmware I checked did.) So we can just load one of those, run some tests, and see what happens.

Spoiler: In practice, dissimilar speeds are no problem at all. :-)

I made a quick 50mm cylinder in OpenSCAD (2018.03.07):
cylinder(20, 50/2, 50/2, false, $fn=120);

... then reloaded Marlin 1.1.8 on my FT-5, and printed a reference print with matching X/Y speeds and matching X/Y accelerations. G-Code was sliced using Cura 3.4.1, spiralizing the outer wall so it prints as a single continuous line with smoothed continuous Z-movement. (I used a brim for stability, so please ignore the bottom few layers in each test piece.)

I then iterated through a number of changes... firmware, slicer settings, etc, until I thought I had a good example of a clearly unbalanced X/Y print. I have included photos of the test print set, as well as the first and last together. They are almost indistinguishable in person, so I had to label them.

img_1095 - resized

I have also included a short video of number 6 printing, so that you can see and hear the speed ramp up and down as the extruder whips around the two X-axis runs of the circle.
IMG_1086 - Resized.mov.zip

Number 6, with the unbalanced X/Y speeds, is the best print of the batch. I'm lucky there is a tiny nick where the top layer extrusion ended, otherwise it would be impossible to tell how the print had been oriented on the print bed, or which sections had been printed fast vs slow. There is NO perceptible impact in the print quality from the unbalanced X/Y speeds, other than a slight change in glossiness which I attribute to the fact that I was printing these a bit cold to avoid having sags from single perimeters with the short layer time.

img_1109 - resized

If you take a step back, you will see that our printers change speeds all the time when printing different shapes. Synthetic tests like circles, squares, and stars, and everything irregular or organic. Large shapes that let the extruder ride the max speed for long stretches, and shapes small and complex enough that it doesn't ever have the room to get up to full speed. It's not a problem. :)

Hopefully this helps dispel some of the concerns...

@dstulken - Thanks. If there's interest in doing this, someone would need to write the code in Klipper to support it, and then perform some tests with Klipper printing real world objects demonstrating noticeably reduced overall print time with the same (or better) print quality.

If someone wants to implement this and can demonstrate it provides real world benefits, then that's great. It's not something I plan to work on. I own a "bed slinger" myself and earlier tests with different accelerations led me to believe it would not work well.

-Kevin

Thanks @KevinOConnor.

I'd be willing to give it a try (both code and validation tests). Would the code changes be limited to the relevant kinematics file, i.e.: klipper/klippy/kinematics/cartesian.py? Or would I have to make modifications in other locations as well? (toolhead.py?)

Without spending too much time on it, any quick pointers you have to start me off, relative to what is where in the code or how you would like to see the changes made, would be much appreciated.

Thanks again.

I have the same development advice given in issue #256 - update klippy/kinematics/cartesian.py:check_move() - the code to slow down the X/Y would be similar to the existing code there that slows down the Z.

As for validation - I think a print with a mix of smooth curves and angles would be important (a cylinder itself generally wont have significant acceleration between segments). Using a config with a well calibrated pressure advance setting would also be important.

-Kevin

Want this as well. Even on the Ender-3 printhead and bed has different mass. And thus needs different acceleration to transfer the same force to the printer.
Had different X and Y jerks on my MeCreator 2, and different acceleration as well.

Not sure why different max speeds would be relevant. F=m*a, not speed here.
This only if I went higher than lowest max speed for the print in the slicer. Say picked 120mm/s, and slowest axis was 90mm/s.

For people playing on the edge, it would make sense to decrease acceleration of the bed when it gets heavier. Depedning on mass deposited. But would likely not be relevant for many. I would not use it.

I'm going to close this for now. I am interested in seeing results of any tests though.

-Kevin

Was this page helpful?
0 / 5 - 0 ratings

Related issues

amaximchuk picture amaximchuk  路  6Comments

ChiliApple picture ChiliApple  路  4Comments

LazaroFilm picture LazaroFilm  路  6Comments

KevinOConnor picture KevinOConnor  路  5Comments

smokez89 picture smokez89  路  4Comments