Smooth_linear_advance WITH s_curve_acceleration [experimental]

[dbuezas]

Description

Adds s-curve support to the lookahead function.
Note that smooth linear advance can actually track the acceleration profile, this is different than classic/rough advance, which always managed nozzle pressure as if the profile was trapezoidal.

NOTE: this PR is based upon the not-yet-merged PR #27818 (merged)

NOTE: this PR is based upon the not-yet-merged PR #27862, so all of those changes are included. The actual changes of this PR are inside the "Experimental s-curve" commit only. (merged)

Requirements

Benefits

Configurations

Related Issues

[rq3]

Strange. I have s curves enabled in configuration.h, AND smooth linear enabled in configuration_adv.h, yet I have never gotten a compile error or warning. And yes, the error line is there in the sanity check. It is just never invoked.

I also have all three axes enabled in input shaping, with the frequencies determined by an IPhone accelerometer app.

[dbuezas]

@rq3 maybe you had an older version. @thinkyhead added that sanity check at some point.

[rq3]

@rq3 maybe you had an older version. @thinkyhead added that sanity check at some point.

Nope. I get no compiler errors or warnings whether or not that line is in sanity check. Weird. Oh well, I'm off to install the latest compiled firmware.bin with your s-curve mods.

[grizzleeadam]

Is this intended to be used alongside Input Shaping, or as an alternative? Additionally, does it matter if class jerk or JD is used?

[vovodroid]

@grizzleeadam

Is this intended to be used alongside Input Shaping

Yes, it's different functions with different purposes.

does it matter if class jerk or JD is used?

Doesn't matter.

@rq3

I get no compiler errors or warnings whether or not that line is in sanity check.

Do you have line #error "SMOOTH_LIN_ADVANCE doesn't currently support NONLINEAR_EXTRUSION." in SanityCheck.h?

[dbuezas]

@grizzleeadam you may have to recalibrate input shaping and the idea is to combine all together (smooth linear advance + input shaping + s curve)

Please do post your results

[grizzleeadam]

@grizzleeadam you may have to recalibrate input shaping and the idea is to combine all together (smooth linear advance + input shaping + s curve)

Please do post your results

It looks like PR27818 was just merged. Could you possibly rebase to the latest bugfix?

[dbuezas]

@grizzleeadam Done, I couldn't test it yet, but the changes are rebased and conflicts resolved

[dbuezas]

Just gave it a test. It works.
I noted the machine crashes if i disable input shaping and try to move an axis. It's probably e-synch accessing broken input shaping delays and factors (so probably not related to this PR)

[dbuezas]

@thinkyhead, I took a quick and dirty approach in this PR to avoid interfering with motion. Do you have any ideas how to do this a bit more cleanly?
The issue are the precomputations done once per trapezoid phase, which don't save much time anyway so wondering if we could make the bezier computation not depend on the precomputed factors.

[dbuezas]

4k acceleration, 5mm/s jerk, 132mm/s .

[grizzleeadam]

It seems you're getting a bit more corner over-extrusion with S-curve enabled. I haven't had a chance to try this out yet - have you tried tweaking any other parameters to clean up the corners more? Does look like a significant reduction in ringing.

[dbuezas]

Yes, just increased k from 0.04 to 0.05 and it's fine. I think it's just that the head stays a bit longer bear the corner and the low k just depressurized there

[dbuezas]

I just remembered I had lowered jerk a lot because i was calibrating input shaping and the Klipper docs say so.

[grizzleeadam]

here’s my sample. Top is without S-Curve, bottom is with it enabled. Quality changes with height as I was calibrating JD. It seems the detail inside the triangle is much smoother with S-Curve! Speed is 100mm/s, 3000 acceleration, 0.4K with Bowden.

It seems we may need to have a branch with S-Curve and your other e-sync fix combined together - as of now I’m unable to test re-calibrating IS with S-Curve together.

[vovodroid]

Top is without S-Curve, bottom is with it enabled

But top looks much better, doesn't it?

[grizzleeadam]

Top was printed with 2 perimeters and bottom was in vase mode, which may have contributed to the difference in surface quality on the flat parts. The details in the notch are what I consider to be the biggest difference.

…

On Sat, May 17, 2025 at 7:26 PM Vovodroid ***@***.***> wrote: *vovodroid* left a comment (MarlinFirmware/Marlin#27827) <#27827 (comment)> &gt;Top is without S-Curve, bottom is with it enabled<br> But top looks much better, doesn&#39;t it? — Reply to this email directly, view it on GitHub <#27827 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A6SRTTQUJ6LP4CIQWQFSBCD267VTZAVCNFSM6AAAAAB4GPP7TOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBYG4YTSNJRGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[vovodroid]

Could you print with the same settings? Otherwise it's hard to compare.It's strange that vase produces much more ringing.

[grizzleeadam]

That’s not really ringing, more likely banding from my v-rollers. I get that no matter what speed I print at on that axis.

Here’s the other side of those same two prints. The Y’s look much more crisp on the bottom print.

[vovodroid]

As for me top-left looks much better.

[dbuezas]

They're no the same layer height, are they?

It seems we may need to have a branch with S-Curve and your other e-sync fix combined together

Ill rebase this one on top of the fixes today and ping you

[dbuezas]

@grizzleeadam This draft pr now includes the fixes from #27862

[dbuezas]

Is this always true?

Same as @robherc, I don't really know for sure. You may be right that the duration of each phase is not the exact same as the trapezoidal profile. In this PR I just piggy back on the existing calculations to compute the appropriate advance for each instant where the smooth linear advance ISR runs.

[dbuezas]

Actually, you are right! my prints are taking a less than what the slicer says. And I get less ringing.
I don't know if that wasn't the case already without s-curve. If it wasn't... NOT BAD! 😮

[vovodroid]

I've tried this PR (before conflicts appeared) and got X axis layer shift. Does S-CURVE in this PR also applied to non-printing moves, or it's just coincident?

[dbuezas]

S-CURVE in this PR also applied to non-printing moves

Yes, all moves. It could be the case that it is related. S curve reaches I think twice the acceleration in its steepest point, so if you were too close to your max accel it would be best to reduce slightly.

Btw, did you combine it with input shaping? I'm getting very clean prints with everything combined. The cleanest I've ever had

[vovodroid]

I again took a look on print - actually layer shift could happen by short (about 5 millimeters) move (whether printing or travel).

S curve reaches I think twice the acceleration in its steepest point

In this PR or always? I didn't have layer shift with S-CURVE before.

did you combine it with input shaping?

Yes.

The cleanest I've ever had

It's difficult to say on this model, also material I used (PETG) is not the best quality.

[dbuezas]

In this PR or always?

Always. This pr only changes extrusion, motion is untouched. Congrats on the non linear extrusion PR merge btw.

The layer shift must be a coincidence, smooth linear advance does not change anything motion related, only extrusion

[vovodroid]

The layer shift must be a coincidence,

Ok, I'll try again

[vovodroid]

Could you resolve conflicts to test on latest version?

[dbuezas]

resolved

[vovodroid]

S curve reaches I think twice the acceleration in its steepest point,

I was sure that it reduces vibration and frame load by gradually increasing acceleration, but not exceeds defined limit anyway.

[dbuezas]

If that were the case, acceleration would be lower on average. Here @mh-dm has very intuitive visualizations of real data: #27101

[vovodroid]

If that were the case, acceleration would be lower on average.

You bet I thought it was!

[vovodroid]

I printed with this PR - looks good, though I don't have the same object printed before to compare.
Don't you think it's ready for merging?

[dbuezas]

Don't you think it's ready for merging?

The code is crappy, need to rebase and reorganize it a bit, but functionally it is done.

I need a better way to make it coexist with the normal usage of the s curve coefficients

[dbuezas]

@thinkyhead any advice on how to reuse the bezier code without backing up variables and whatnot?

[thinkyhead]

@thinkyhead any advice on how to reuse the bezier code without backing up variables … ?

These are written in hand-coded assembler for performance, particularly vital on AVR. These routines use the hardcoded RAM addresses of the variables to bypass stack passing. If the functions were re-built around the function calling ABI with a structure pointer and member offsets that would allow them to work on more than just the one set of values. It wouldn't necessarily be faster due to the added stack manipulation. We'd have to get a profiler on that.

[dbuezas]

Ok, sounds like it wouldn't make much more sense since smooth LA most likely only works on 32 bit machines.