Linear advance advances

[tombrazier]

Description

tl;dr: Linear advance is now smaller, generates a cleaner pulse train, runs the E stepper more quietly and, reportedly, no longer generates causes TMC2208 stepper drivers to go to sleep.

This PR changes how E stepper pulses are generated when LIN_ADVANCE is enabled. In the original implementation, the normal pulse_phase_isr() would generate E steps at the usual rate whilst advance_isr() generated E steps at a rate related to acceleration. (Note: the actual pulses to the E stepper were all generated inside advance_isr() which incorporated the steps generated by pulse_phase_isr()). This resulted in two overlapping E stepper pulse trains. This contributed to E stepper noise and caused some TMC stepper drivers (e.g. TMC2208, TMC2225) to give up and go to sleep.

Now all steps and pulses are generated inside advance_isr() as a single pulse train. (Although pulse_phase_isr() does still record E steps that would have been generated without linear advance so that the logic can keep track of how many steps were "advance steps" and how many were just what the gcode had requested.)

The new new code uses 32 bytes less RAM and 244 bytes less flash on my AVR machine (configs.zip):
Before:

RAM:   [========  ]  75.6% (used 6197 bytes from 8192 bytes)
Flash: [========  ]  83.9% (used 213078 bytes from 253952 bytes)

After

RAM:   [========  ]  75.3% (used 6165 bytes from 8192 bytes)
Flash: [========  ]  83.8% (used 212834 bytes from 253952 bytes)

It spends marginally more time in the stepper ISR, e.g. G1 I1 E2 F1800 spends 225ms in the ISR before the change and 230ms after the change. However with the recent arc and planner optimisations, the planner queue remains full throughout.

The extra processing is a consequence of removing the FORCE_INLINE from calc_timer_interval() which is now called from three extra places. Cumulatively inlining adds 1k of code to flash. If the FORCE_INLINE is kept, then the new linear advance code runs faster (220ms) than the old code but, as I say, costs an extra 1k of flash.

The code change also opens the way to integrating S_CURVE_ACCELERATION with LIN_ADVANCE. All that is needed is for Stepper::_eval_bezier_curve() to calculate acceleration as well as speed. This would add a few multiplications but is not excessively expensive. Since Stepper::_eval_bezier_curve() is written in highly optimised assembler, this is work for another day.

In the course of implementing this, it was also found that there was an incorrect extra delay in the first step generated for each segment. This is resolved in aaf7d0e.

Requirements

Cleaner pulse train for any E stepper, but especially beneficial.

Benefits

TMC steppers no longer go to sleep.

Related Issues

#16076
#22547

[Farva42]

I've tested these changes on a Creality 4.2.2 board with TMC2208's in standalone, no issues with the extruder stepper shutting off like with the current implementation where the extruder will shutdown within 30 seconds of starting a print. It also sounds less harsh at higher K values then the current implementation but that might be a little subjective.

The only downside I've found is I've needed to re-tune flow rate. my prior setup before implementing the changes was at 1 now it's around .92.

I've also tested this on a Creality 2.2 board with A4988 drivers with no issues beside the mentioned flow adjustments.

I have only been able to test the below commits. I'll try and test the rest of the commits to see if they flow issue is resolved
820153b
092b84a
de35fbd
4f3c183
0242cfb
88bb808
aaf7d0e

[tombrazier]

Commit a55f315 should resolve the flow issue.

[thinkyhead]

Some changes applied:

• Moved the methods to cpp file for a neater class header.
• Replaced loops pointer with reference, as code was originally C.
• Since step_rate is already compared to min_step_rate the logic can be optimized for the <= case.
• Some uint16_t are replaced with uintptr_t where appropriate.
• Fixed some gcode/ includes of stepper.h that should have been changed to planner.h a while ago.

[x40-Community]

Is it possible to integrate the patch?

The most straightforward way is to ask the manufacturer to rebuild the FW with newer Marlin version. Have you tried that? Also, there is a chance they will give you firmware source code, may be after NDA signing. Then you will be able (after some work) to switch Marlin version keeping propiertary UI.

Weedo is a small manufacturer that hasn't made any improvements for two years. Luckily we have the source code and have already been able to integrate some bugs into improvements.
All we really need is a bug fix to make Linear Advance work.
We would also pay money if someone integrated the patch Workable for us!

[Nikolay-Po]

All we really need is a bug fix to make Linear Advance work.

May be it will be not so hard to integrate proprietary display and UI into current Marlin? Usually, proprietary user interface is working separately of Marlin and just sent G-codes to Marlin code. IMHO, as first step, it worth to configure current Marlin for your printer without a UI by creating separate pins.h and appropriate configuration and configuration_adv.h files. Then, after printer operation through serial port (USB connection) is confirmed, try to implement proprietary UI and SD card interface (if applicable), using 2.0.8 source code as a reference.
I think current 2.1.x is quite different after several movement improvements. But the last word is for patch author. I can mistaken.

[tombrazier]

I think @Nikolay-Po is on the right track. A short term backport of the LA fix might conceivably be easiest right now but if you want all the goodness of Marlin as it evolves you're eventually going to want to move the UI code and appropriate pins config into Marlin proper.

To answer the original question, I had a go at applying this PR to 2.0.8 but it's not trivial.

[thisiskeithb]

Is it possible to integrate the patch?

---

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

• Marlin Documentation hosted on MarlinFW.org
• Marlin Forum hosted on RepRap.org
• Marlin Firmware Facebook Group
• Marlin Firmware for 3D Printers Facebook Group
• Marlin Configuration on YouTube
• Marlin Firmware Discord server

[x40-Community]

I compared the Weedo X40 firmware (Idex printer) against the Marlin 2.0.8. A lot has changed in the Weedo firmware. I don't think the changes can easily be integrated into a newer Marlin version.
It's a pity really, then I'll probably have to deactivate Linear Advance and tick it off.

[ttyusupov]

I see related #16076 is applicable to Marlin 1.1.x, any plans to backport this fix into bugfix-1.1.x branch?

[thisiskeithb]

I see related #16076 is applicable to Marlin 1.1.x, any plans to backport this fix into bugfix-1.1.x branch?

@ttyusupov: No. Short of making some small updates to allow some older versions of Marlin to use newer PIO / pin platform & library versions, 1.1.x won't receive any more updates. You'll need to migrate to 2.1.x.