Smooth Linear Advance (Testing)

[classicrocker883]

Description

Testing MarlinFirmware/Marlin#27710

Requirements

Benefits

Configurations

Related Issues

[dbuezas]

Things to consider when testing:

• If extruder skips, increase tau.
• Extruding moves will now use the full max acceleration & jerk, which will now not be limited by linear advance. If it was set too high or too low before you wouldn't have noticed it. Now you will
• Same applies to JD
• Best k value will likely be a bit different, particularly for high accelerations and speeds, so make sure to recalibrate.
• The biggest time savings are best done in inner walls and infills, not on outer walls (good quality/speed balance by keeping accels & jerks lower for outer walls). Obvious but it was less relevant before.
• Check your stepper driver temperatures when using high accels.
• S-Curve may or may not work correctly. This algorithm can be more easily updated to be more tightly integrated with S-Curve in the future for optimal results.

Looking forward to hear your reaction to it

[classicrocker883]

I see there is an option to sync with Input Shaping, but INPUT_SHAPING_* doesnt need to be enabled right?

and I wouldn't know what to look for whether S curve is enabled or not. another thing is with the Aquila mainboard, OLD_ADAPTIVE_MULTISTEPPING is enabled following a PR (a while ago) otherwise it would make noises with the motors. maybe this can be disabled now. I upgraded my X/Y motors to 42-40, which run cool, so I can max things out.

I'm not sure what differences this would make but do you have any ideas of like what model to test print or what would be a suggested starting value, and what to look out for as to changing them?

[dbuezas]

synching extrusion to input shaping is not required but if you use input shaping it does improve quality. This is because input shaping changes the trapezoid or s curve profile, and if extrusion is not synchronized, then the extrusion happens thinking the profile was unchanged (will over and under extrude in different parts of the profile)

This is also the case before smooth advance btw, but since it limits acceleration, the problem is less "exposed"

[dbuezas]

watch out, % is expensive

[dbuezas]

Also, if it needs to wrap around twice, the buffer is too small and taking that index will take the wrong value

[classicrocker883]

meaning uses more flash/ram?

[classicrocker883]

appears to only add 8 bytes.
I compiled using % and without by reverting void add_to_buffer() and xy_float_t lookback()

here it is using the updated with %:

RAM:   [====      ]  37.9% (used 24812 bytes from 65536 bytes)
Flash: [====      ]  42.6% (used 223488 bytes from 524288 bytes)

here it is without (originally):

RAM:   [====      ]  37.9% (used 24812 bytes from 65536 bytes)
Flash: [====      ]  42.6% (used 223480 bytes from 524288 bytes)

are there any improvements you suggest?

[classicrocker883]

what about changing to:

- delayBuffer.index = (delayBuffer.index + 1) % IS_COMPENSATION_BUFFER_SIZE; // Wrap around
+ delayBuffer.index = (delayBuffer.index + 1) & (IS_COMPENSATION_BUFFER_SIZE - 1); // Wrap around (optimized for power-of-2 sizes)

This approach is faster because bitwise operations are generally more efficient than division. However, it only works if IS_COMPENSATION_BUFFER_SIZE is a power of two

[dbuezas]

The index increments by one, so the original approach is enough imo.
The buffer size depends on the minimum input shaping frequency, which actually also limits input shaping min frequency itself, so the comment about informing the user is not really necessary (if that were to happen, input shaping itself would be failing)

[dbuezas]

Modulo takes more cpu cycles, it is as costly as division. Since the index is always incremented by 1, the cheap original solution is correct (and the fastest)

[classicrocker883]

ok I updated this, it should be like the original, and cleaned up.

[classicrocker883]

I made some updates that might improve some things. go ahead if you'd like to look through and copy over to your Marlin PR.

so some things like spacing and indentation needed fixing.
Made so it is more concise and efficient, leveraging modulo operations for circular buffer management.

---

1. add_to_buffer:

delayBuffer.buffer[delayBuffer.index] = input;
delayBuffer.index = (delayBuffer.index + 1) % IS_COMPENSATION_BUFFER_SIZE;

2. lookback:

uint16_t past_i = (delayBuffer.index + IS_COMPENSATION_BUFFER_SIZE - delay_steps) % IS_COMPENSATION_BUFFER_SIZE;

• Uses modulo (%) to calculate the wrapped-around index (past_i) directly.
• Uses modulo (%) to wrap the index around when it reaches the buffer size.
  This is a concise and efficient way to handle circular buffers.

3. Error Handling for Buffer Overflow:

• Updated:

  • Assumes the buffer size is sufficient and does not explicitly handle overflow beyond a comment (TODO: How to inform user?).

• Previously:

  • Explicitly resets past_i to delayBuffer.index if delay_steps exceeds the buffer size, ensuring no out-of-bounds access.

[classicrocker883]

Update

• Reverted/removed % changes
• Renamed t and past_i in stepper.cpp lookback() and add_to_buffer()
• Added wrap_index() function to clean up the code.