[FR] Adaptive acceleration support in Klipper

[dmbutyugin]

Adaptive acceleration control can reduce acceleration of the toolhead on short moves and increase it on long moves. One possible implementation uses 'jerk-limiting' to control acceleration (implemented in scurve-shaping and scurve-smoothing branches). It seems to additionally reduce vibrations vs plain input shaping or smoothing - at the expense of slowing down the prints to some degree - and might be beneficial at least to some users.

This is a dedicated ticket to discuss this feature instead of #57, which got too large to manage.

[BlackStump]

scurve-smoothing is my go to branch for normal printing. It has been for some time. scurve-shaping looks promising on the test prints at least.
When I have a need to print something it is generally set to scurve-smoothing, I will change to scurve-shaping for normal printing to see how it compares on general usage.

[DroneMang]

scurve-smoothing is my go to branch for normal printing.

Is this branch as updated as master?

[BlackStump]

@dmbutyugin
Is it possible to update the scurve-smoothing branch to current master?

Cheers

[dmbutyugin]

@BlackStump Well, input_shaper was integrated into the mainline Klipper. smooth_axis feature is sort of incompatible with it. I would suggest you to use scurve-shaping branch instead. Is there a reason you cannot use that one?

[BlackStump]

@dmbutyugin I have been using Mainsail webui and wanted to merge that with your scurve-smoothing and found it conflicted with the mainline. I still wanted to swap back and forth between scurve-shaping and scurve-smoothing but if that is not possible I will stick to scurve-shaping.
I have not found any reason to not use scurve-shaping over scurve-smoothing.

[1N4148]

Is there still any further development for scurve? Had some prints failing with scurve enabled. Klipper threw an "Logic error: velocity jump from 112.019817 to 111.728440" somewhere in the middle of the print, stopping (regardless of using input shaper, too). Doesn't happen with no scurve.
With input shaper only my Ender 5 I'm still limited in acceleration.

[dmbutyugin]

@1N4148 The branch is kept alive, and I re-sync it fairly regularly to the latest mainline. Please attach klippy.log and the gocde you tried to print, I will take a look.

[1N4148]

Thx in advance! Please see the attached log & gcode. Problem persists when using ACCEL_ORDER=4 or 6, not with ACCEL_ORDER=2.

ender3.zip
m2.zip

[dmbutyugin]

@1N4148 Thanks, I took a look at the failure. Well, you do seem to have run into a bug in the planning algorithm, where apparently it finds the suboptimal point to flush the previous set of moves

Warning: impossible to reach the committed v2 = 12548.439, max velocity = 12286.162, fallback to suboptimal planning, decelerate to 4267.233

which I honestly thought should be more or less impossible now.

Now, in principle the algorithm should be able to recover from this event, but it seems there is a bug somewhere which results in incorrect assumptions during recovery. Unfortunately, it will likely take me some time to find the exact root cause and fix it.

[1N4148]

Thx for your quick analysis :-)

In the meanwhile I'll try some tests with the new ADXL345 maybe I can domesticate my Ender 5 with it. Do you know if the secondary mcu is limited to a Raspberry? I'm running both Klipper/Octoprint instances for my Enders on the same Odroid. Or is there a solution for connecting the ADXL345 to a Raspberry while still running Klipper on the Odroid?

[dmbutyugin]

@1N4148 ADXL345 support is no longer limited to RPi now. It seems even some (many?) MCU boards can be used to connect ADXL345 to. As long as Odroid has SPI interface, it should work. But you'll need to refer to Odroid documentation for the pinout. As the docs describe, you'll need 3.3V (some ADXL345 boards can accept 5V if they have built-in voltage regulator, you can check, and which pin to use then), ground, MISO/MOSI, CLK and CS pins.

[1N4148]

SPI and ADXL345 on Odroid is no problem, got this already running. I just was unsure if klipper_mcu is using /dev/spidev0.0 or anything else. Will share my experience in the ADXL thread.

[1N4148]

Any update on scurve branch for this bug? At least a merge with current Klipper updates? :-)

[dmbutyugin]

@1N4148 I updated the branch. Unfortunately, I couldn't dedicate much time to this bug lately, so no progress yet. I'll post an update once I nail it down.

[1N4148]

Yes, I've seen. Thank you for updating the branch, Until it's printing fine bit I've changed acceleration settings. Cannot say if this is relevant for the bug but I'm willing to retest the problematic gcode on your request :)

[Sugaroverdose]

it's a shame that such powerful feature is outside of a mainline

[sammcj]

Has anyone come up with any updated solutions / workarounds for this?

[sumguysr]

Is Scurve-shaping ready to integrate into mainline?

[saosebastiao]

I know this branch has been open for quite some time and it's probably worth merging as it is, but I just wanted to point out this great library for motion control:

https://github.com/pantor/ruckig

It is an efficient multi-axis jerk-limited trajectory generator, which also produces extremely high quality solutions. I think it would be worth exploring for the same use cases as scurve shaping.