Independant acceleration limits for X and Y axes

Hello, I made this PR before realizing this thread existed: Kinematics/Cartesian: Add Max X, Y Velocity by your-friend-alice · Pull Request #6225 · Klipper3d/klipper · GitHub

They were rejected because of lack of evidence that orientation dependent accelerations don’t harm extrusion and print quality.

Personally I wouldn’t mind having the option to improve speed at the expense of quality, it seems like one of the big benefits of klipper is exposing the nuts and bolts of that exact trade off to the user.

Could i ask you something? I noticed a little flaw here actually while printing and i believe its the exact reason youd lose some quality during this code but you dont use axis specific deceleration which is the entire thing that avoids skipping while acceleration is also part of the battle and if you know this code as well as i see you do would it be possible to add max_x_decel and max_y_decel ? It would be extremely useful in the purpose of a cartesian and im pretty darn sure its also relevant to core xy

I commented what i did because as of watching my x axis which can accelerate much faster has no choice to use the y axis deceleration speeds which are quite low to what they could be doing in general

What deceleration are you referring to?
max_accel_to_decel is not a deceleration, it act like as velocity limitation on short moves.
There is no API to change this value on individual moves.

How do you actually get the patches as code? I can’t find anyway to download them - it just shows the coding/script in GitHub. I see one is named toolhead.py and the other resonance_tester.py
Are these two file patched versions already in the Klipper install that your Github has?
And I guess that seeing they are files that already normally exist in Klipper, that if you update Klipper it could replace those patched versions?
Thanks

Just wanted to say thanks for making this @Piezo it has made my bedslinger with very lopsided accels churn out prints that were taking over 24 hours in about 12. On my Sovol SV04 I can reliably do 9k accel on X but only 3k on Y so it has been a huge benefit to me with no noticeable decrease in print quality related to the change.

1 Like

hey @Piezo I just tried to implement this on my printer and I received an error:

Internal error during connect: ‘void(*)(struct trapq *, double, double)’ expects 3 arguments, got 2

Once the underlying issue is corrected, use the “RESTART”
command to reload the config and restart the host software.
Printer is halted

Do you have any insight on this?