cartesian: Initial implementation of independent X/Y accel/velocity

[rdbahm]

Extend the existing Z acceleration/velocity limits to work on the other axes as well, allowing the user to independently control the maximum acceleration and velocity of each axis. This was driven in large part by a desire to push my bed slinger further - testing on a resonance tower showed that X acceleration could be pushed much further than Y acceleration. While Input Shaper can largely deal with the non-uniform axes, being able to tune acceleration on each axis individually should allow users to achieve greater speeds without sacrificing quality.

Testing has shown that it functions as expected, allowing independent accelerations on each axis. I think the biggest challenge will be seeing if users are able to make good use of the option.

I targeted this initial implementation at the cartesian kinematic since that covers the common bed slinger design, which is likely to have the most asymmetrical acceleration constraints. From a glance at the code, it looks like it would be relatively trivial to implement in most other non-delta kinematics - CoreXY, CoreXZ, Hybrid CoreXY, andd Hybrid CoreXZ all use the same (or nearly the same?) check_move code.

New parameters have been added to the docs.

[Piezoid]

I've made some figures for torque/velocity limiting on CoreXY, and a draft implementations for [corexy](https://github.com/Piezoid/klipper/blob/work-peraxis/klippy/kinematics /limited_corexy.py) and cartesian kinematics. These are single python files that provides new kinematic names to use in the config.

[KevinOConnor]

Thanks. As high-level feedback, I think this change would need to come along with documentation describing how to tune these new variables and testing results from a variety of printers demonstrating its utility.

FWIW, in initial versions of Klipper (before even its first release) using separate acceleration/velocity limits was possible and I got poor results with it on the Makergear M2 bed-slinger that I owned. It took me several days to figure out what was going on, and when I did finally track it down I concluded that the ability to specify independent xy acceleration/velocity was highly prone to misconfiguration. Specifically, when there are separate limits, every diagonal move (and thus every curve) effectively has a different acceleration and velocity. This results in surprising behavior - every move has a different flow rate, every move has a different pressure advance behavior, alternate layers have different infil print times, etc. I also concluded that the critical printer interaction is between nozzle and print - the stepper motors typically have oodles of torque and tuning to them generally does not make sense.

I'm leery of adding config options that make it "very easy" to obtain poor quality. (To wit, I'm leery of adding "landmine options".) That said, if there is a significant number of users with printers that can improve quality with these options then that's great. That is, showing a level of print quality in significantly less time, which can't be obtained without these options, would be a very convincing demonstration.

Thanks again,
-Kevin

[rdbahm]

I can appreciate avoiding configuration footguns. While I had considered the possibility of diagonal moves having different velocities/accelerations at every different angle, I had not considered the effects of the non-uniform acceleration on other features, like pressure advance. Thoughtful documentation to demonstrate how to use this capability conservatively would be important.

This feature isn't a hill I need to die on, and I simply don't have the variety of printers required to prove if the concept has merit. I'll leave some info on my findings here in case someone in the future thinks that independent acceleration is the hill they would like to die on. :)

On my project printer (Geeetech A10, an Ender 3 clone, modded half to death), I found that the independent accelerations let me achieve an additional 500mm/s/s (5700 to 6200) on my X axis due to the heft of the Y axis with no impact to print quality. This was also nice because it prevents my printer from flinging things off tables when the Y axis gets going. It worked nicely in combination with accelerometer-measured resonance compensation, since RC outputs suggest max accelerations for each axis and algorithm.

More comprehensive testing would be required - I was largely testing for functionality of the change, not for "is this a thing that people should do?" If you're working on independent axis accelerations in the future, reach out to me if you'd like someone to run some additional validations.

[KevinOConnor]

Okay. Just to be clear, I'm not against exploring this change; I do think more documentation and testing is necessary before merging though.

Just as context, the Klipper S-Curve acceleration branch went through discussions for a few years (eg, #2030, #1776, #57, #3026, etc.). Some people saw improvement with the support, while some people saw a degradation in quality. Ultimately we ended up merging input-shaping (#3025). So, if this change can be shown to notably improve quality then that would be great.

In any case, thanks for working on this.
-Kevin