Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR] Adaptive acceleration support in Klipper #3026

Open
dmbutyugin opened this issue Jun 27, 2020 · 19 comments
Open

[FR] Adaptive acceleration support in Klipper #3026

dmbutyugin opened this issue Jun 27, 2020 · 19 comments

Comments

@dmbutyugin
Copy link
Collaborator

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
Copy link
Contributor

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
Copy link

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

Is this branch as updated as master?

@BlackStump
Copy link
Contributor

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

Cheers

@dmbutyugin
Copy link
Collaborator Author

@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
Copy link
Contributor

@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
Copy link

1N4148 commented Oct 10, 2020

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
Copy link
Collaborator Author

@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
Copy link

1N4148 commented Oct 11, 2020

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
Copy link
Collaborator Author

@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
Copy link

1N4148 commented Oct 13, 2020

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
Copy link
Collaborator Author

@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
Copy link

1N4148 commented Oct 14, 2020

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
Copy link

1N4148 commented Nov 5, 2020

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

@dmbutyugin
Copy link
Collaborator Author

@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
Copy link

1N4148 commented Nov 6, 2020

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
Copy link

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

@sammcj
Copy link
Contributor

sammcj commented Mar 23, 2023

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

@sumguysr
Copy link

Is Scurve-shaping ready to integrate into mainline?

@saosebastiao
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants