Configuring velocity/acceleration for X & Y axes independently?

[dstulken]

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 _maxvelocity and _maxaccel both operate on the X & Y axis as a pair, and _max_zvelocity and _max_zaccel 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.

[KevinOConnor]

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

-Kevin

[dstulken]

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?

[bruce356]

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

[Papsnoek]

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...

[dstulken]

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.

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.

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...

[KevinOConnor]

@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

[dstulken]

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.

[KevinOConnor]

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

[povlhp]

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.

[KevinOConnor]

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

-Kevin

[gerleimarci]

I'm still missing the velocity/steprate limit for X and Y stepper on cartesian. I mean if your steppers can do e.g 500mm/s, then now can only limit the printhead speed to 500mm/s while the motors could go faster on diagonal moves. So if we can set the X and Y max velocity limit to 500mm/s then we can get up to 707mm/s on a 45° diagonal move.

[LeLocTai]

Regarding why max speed is relevant, stepper torque usually reduced with speed: https://www.google.com/search?q=nema+17+torque+curve&tbm=isch

I'm a Marlin user transitioning to Klipper. My use case for different x y velocity limit is to be able to do faster travel move. My bed can go up to about 140mm/s, which is faster than most hot end can handle, but being able to do travel move faster would reduce print time and oozing. I have no test to show at the moment, but I have been using this setup in marlin for a long time and have not notice any problem. I don't consider this feature isn't a priority, just want to provide a case where it would be useful.

[Pun-e]

@KevinOConnor Hey mate, in this thread you seem pretty confident that discrete accelerations for X&Y axes would be of no value, but I'd just like to point out that the input shaper does have separate X&Y controls, similarly the "ringing tower" test print was designed to allow independent analysis of the X&Y axes.

For example, my own recent test showed my x-axis to be good up to ~9,500mm/sec^2 where my y-axis was struggling at 3,000mm/sec^2. At present you just need to look at both and use your overall worst, which is leaving performance on the table.

I also find it strange this issue has been marked as closed when it is has not been handled to anybody's satisfaction. How will willing devs know there's an outstanding issue they can tackle? By trawling the closed tickets?

[cyounkins]

@Pun-e I'm subscribed to this thread because I agree with you and the OP that this would be a nice feature to have. Thank you for your test data!

I like your post until the 3rd paragraph. As a developer (not on Klipper), reading the last part of your post would really turn me off from helping. Kevin, the creator and core developer, closed the ticket and so it was handled to his satisfaction. As of this writing there are 28 open issues that may require attention with more in developers' brains.

If you are so inclined, submitting a patch for this feature request would be incredibly helpful. Additional test data demonstrating that this would be a performance improvement would also help. Otherwise, let's remember that this is free software, arguably the best printer firmware available, and be thankful to Kevin and other developers for allowing us to use it. :-)

[mulder999]

Going back to Marlin until this is eventually implemented. It will never match speed and quality without this feature in place on my cartesian printer since the optimal values are in 2:1 ratio for me.

[RyushoYosei]

Really? Klipper doesn't have split accelerations? I would be able to print faster overall just because of how fast the X can move compared to my heavy weight glass bed, because above certain accelerations, my bed steppers skip for the Y because of the weight, but the X doesn't care at that level, and could go far higher, and faster accelerating, but it's going to force me to tie the two together because of how they are not able to be done independent.

[Daede-Fabrications]

Also subbing to this thread because this would be an excellent addition to klipper.

[PeggyFree]

I am also looking for this feature

[berkus]

Same here. Having separate acceleration profiles would be nice.

[danoveb]

This would be a nice feature, but separate acceleration on moves should be a higher prio. I have a heavy y-board and print mostly in PETG, and faster moves helps a lot. I have solved this for now by a post script which work and is easy to integrate with prusaslicer/superslicer/slic3r but need manually execution with Cura...

[danoveb]

...realized that this is actually is supported in Cura. Cura makes M204 Sxx lines if you set different acc on moves...

[mulder999]

...realized that this is actually is supported in Cura. Cura makes M204 Sxx lines if you set different acc on moves...

Cura generates gcode but it is still limited to whatever firmware can do. Having different accelerations on X and Y axis can only be solved with M204 for lines exactly parallels to the axis. Unless we print only aligned rectangles, we need more than that.

[danoveb]

Correct, the feature I found in Cura also exist in prusaslicer and superslicer... I should learn the slicer before making my own post processing scripts...

[aforww]

I would like to see proof that you folks running Marlin are in fact getting different accelerations. I'm fairly confident that even if you're setting the max of Y to 3k and X to 7k, you're only going to see that on straight lines in that direction and anything requiring them to be matched (circles as an example) is slowing down accel values automatically making anything other than rectangles moot.

[mulder999]

This is not all about printing but also traveling. Anyway Marlin implementation is fine with me in this regard.

[geoffpotter]

In the case of a circle, yes, the acceleration/speed would need to be limited to the slower axis for a decent amount of the circle. In the case of an oval with, say, a ratio between it's height and width equal to the ratio of your machine's capabilities in that respective axis, then instead of being limited by the slower axis you could speed up based on the angle you're traveling and the ratio that angle represents between the two max values.

With a single value for speed in both X/Y all we can describe is a circle around the nozzle that our printer is capable of moving the nozzle to in the next second(or whatever unit of time). With a separate limit for X and Y we could give klipper an oval instead. I've got a ~10k difference between the suggested max accel between my axis, that's a lot left on the table if I go with the slower axis in all directions.

If you're printing a 45 deg diagonal line and the Y axis can move 10 mm/s, but the X axis can go 100, then only the Y axis part needs to be limited to 10, since you're moving at an angle the print head itself can be moving faster than 10mm/s, 14.1 in this case.

[garyzz]

I am also looking for this feature for my bed slinger.

[nefelim4ag]

https://klipper.discourse.group/t/independant-acceleration-limits-for-x-and-y-axes/3831

[piter-pit]

I can also put my two cents, I'm trying to print quite tall and thin object and since I have glass moving bed, the element wobbles with high accel on Y axis, while fast moving X axis is not an issue

[Red-M]

I've been running the patch by Piezo on my Voron 2.4 and I'm not seeing anything adverse even while I push up the accelerations to the values suggested by input shaper and make sure my slicer is trying to go as fast as possible.

It does greatly reduce print time to put wide objects on the much faster X axis because at least on my machine, its able to go 3 times as fast.