Module: Toolhead, implements independent X-Y axis acceleration

[jasonhamilton]

Adds the ability to allow for independent x-y axis acceleration. This allows for bedslingers or printers with different resonance characteristics on the X and Y axis to further improve print quality/speed.

Signed-off-by: Jason Hamilton jasonscotthamilton@gmail.com

[KevinOConnor]

See the discussion at #4661 .

-Kevin

[jasonhamilton]

Oh wow. I should have looked there first!

[KevinOConnor]

Okay. My feedback is the same as in that PR - if someone wants to gather lots of test results and demonstrate the impact of tuned X vs Y accel then I'd definitely be interested in seeing those results.

-Kevin

[jasonhamilton]

I’m happy to run some tests on my printers for some data points. Is there a specific model, slicer settings, etc that would make comparing tests easier?

[KevinOConnor]

Good questions, and I don't know the answer to them. Figuring out all that stuff is part of the work that I think someone would need to do.

-Kevin

[JRHeaton]

I think I speak for a lot of people with bedslingers running Klipper who are, whether it's an ideal build or not, limited in our max acceleration to what our insanely heavy Y axis can handle. This and previous attempts to address per-axis treatment of accelerations I believe to have been and be being blown off while requesting a nebulous test/documentation goal must be reached, and somewhat ignoring the inherent good this would do to machines with such weight disparities across X/Y axes. What's more, the other two primary recognized production 3d printer firmwares in the industry support independent control over acceleration on this granular of a level. Lastly, why is(was) it seen as inherently beneficial to separate out Z accel/velocity limits from X/Y in Klipper? I submit that the same principle applies, your bed slinger axes may be weighted Z > Y > X, and frankly the Y will be more important to your print moves, so it feels odd that we cannot control each.

People in the SpeedBoatRace discord channels and on YouTube have been making private/personal forks in order to achieve the speeds you're seeing on video. There is demonstrated merit to this on those mediums. What I think we need are clearly defined documentation goals and a testing strategy for demonstrating whatever data is required to show this merit and that it is going to make this provably "non-problematic" to existing features or UX. Just saying "Good questions, and I don't know the answer to them. Figuring out all that stuff is part of the work that I think someone would need to do." (@KevinOConnor) is correct in 99% of OSS circumstances but who else with knowledge your equal(if anyone) opposes this change or or its needs for submissions? It likely need be you that define the barrier-to-entry. Again maybe not for 99% of submissions but for something that you are claiming to have such a widespread reach on the rest of the performance, we're not all as expertly familiar with Klipper as you and so from our perspectives just need to be told "how to pass the bar" and get a feature which is conceptually helpful to the majority of budget printer owners merged upstream. It is only out of admiration and wishfulness to continue advancing the field, I'm sure, that people want to contribute this :)

Here is a fork currently being used(it looks like by a participant on the linked-to discussion of old) here: https://github.com/Piezoid/klipper/blob/work-peraxis/klippy/kinematics/limited_cartesian.py and discussion around this and others is that is is a necessary evil at the moment to use a potentially less trustworthy fork like this to achieve the performance we want out of the modern "speed printing era." As a developer myself I see more potential harm and confusing support on Klipper's end if an unexperienced person resorts to using one and then having that code potentially NOT meet your rigorous standards (which I respect of this project) yield them unexpected behavior for which they may come submit an issue here not knowing whether it's a core Klipper issue or a fork issue, etc. I have seen it before; I think SuperSlicer is a good example of an OSS project where it started as something we all loved (PrusaSlicer), then the community needs outpaced/misaligned with Prusa and so it was effectively supplemented/superseded by community authors, and now SuperSlicer offers more features, but at the expense of stability, spelling-correctness, documentation, etc. A parallel to this situation. I personally would really not like to see any more dividing of our limited efforts or diverged project states in this space.

[jasonhamilton]

I can appreciate the need for simplicity and ease of troubleshooting. I think this philosophy makes Klipper great. Based upon my testing I did see some speed improvements without sacrificing print quality. For example a model I printed at 1500 acceleration on x/y took 1:42:10 (1hr, 42min) vs 2700/1500 which took 1:27:25, which is a somewhat significant ~15% improvement in print time.

I do think there are more elegantly-coded solutions than mine such as the module in #4661 or the one referenced by @JRHeaton .

Perhaps a solution to the issues raised could be after some basic testing of code (whatever implementation is deemed the best) it can then be merged into mainline with the documentation clearly indicating the feature as experimental? I think implementing a new module/printer which extends the Cartesian printer type would keep any issues isolated to those knowingly using an experimental module. This would also allow for broader testing and data collection without impacting other users.

Honestly it’s not something that’s hugely important to me and my hacked up fork serves me well, however it does seem like something a decent amount of other people would like to see implemented. I’m happy to help in any way, however closing this merge request since there are better implementations for merge candidates.

[JRHeaton]

As was stated, this is definitely something that many cartestian users want implemented. I guess I am asking what specifically needs proven and in what way, @KevinOConnor, as to satisfy your requirements for it to be "valid?" Otherwise we are left hanging for the nth time and with disparate forks implementing varieties of this features with different levels of success. The community is willing to do the work, clearly, but we need you, the maintainer, to lay out the requirements.

[dewi-ny-je]

@JRHeaton using Marlin pick 3 models (for example one simple box, one large cylinder, and a figurine), then print them at acceleration equal in all axes (use the lowest acceleration of the two axes), and provide print time and photos of the result.

Then keep one of the accelerations constant (Y I guess), and increase the other one (X probably). Provide print time and photos of the result.

Then we can see if there is an actual speed advantage. Be aware that even if there is one, someone has to write the code to implement it: the current developers work on whatever they find interesting (except for fixing bugs, obviously), not on call. If it's not too complex to code probably someone will be willing to implement it for you for a couple hundred Euro/dollars (which is less than what it would be the regular pay, but likely enough to get the interest of someone doing it for fun).