LIN_ADVANCE make Z axis making noise and grind

[moriamoria]

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

Hello,

When I activate LIN_ADVANCE in marlin BugFix 2.1.x my double Z, Z2 axis make noise and strange behaviour when just moving the axis.

I have a ortur 4 printer moded with following coponent :

skr 1.3 motherboard
2209 driver for X , Z, E, Z2
mks 42C for Y

I currently not activated any other optimisation. I will wait to solve this issue.

Many thanks for any support.

The difference with commit : 29/09/2024 02:30:05 [cron] Bump distribution date (2024-09-29) are :

in configuration.h

#define MOTHERBOARD BOARD_BTT_SKR_V1_3
#define BAUDRATE 115200

#define X_DRIVER_TYPE TMC2209
#define Z_DRIVER_TYPE TMC2209
#define Z2_DRIVER_TYPE TMC2209
#define E0_DRIVER_TYPE TMC2209

#define DEFAULT_AXIS_STEPS_PER_UNIT { 80, 80, 400, 420 }
#define BLTOUCH
#define AUTO_BED_LEVELING_BILINEAR
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

in config_adv.h

#define BABYSTEPPING

#if AXIS_IS_TMC_CONFIG(X)
#define X_CURRENT 800 // (mA) RMS current. Multiply by 1.414 for peak current.
#define X_CURRENT_HOME 500 //X_CURRENT // (mA) RMS current for sensorless homing
#define X_MICROSTEPS 16 // 0..256
#define X_RSENSE 0.11
#define X_CHAIN_POS -1 // -1..0: Not chained. 1: MCU MOSI connected. 2: Next in chain, ...
//#define X_INTERPOLATE true // Enable to override 'INTERPOLATE' for the X axis
//#define X_HOLD_MULTIPLIER 0.5 // Enable to override 'HOLD_MULTIPLIER' for the X axis
#endif

#if AXIS_IS_TMC_CONFIG(Z)
#define Z_CURRENT 600
#define Z_CURRENT_HOME Z_CURRENT
#define Z_MICROSTEPS 16
#define Z_RSENSE 0.11
#define Z_CHAIN_POS -1
//#define Z_INTERPOLATE true
//#define Z_HOLD_MULTIPLIER 0.5
#endif

#define CHOPPER_TIMING CHOPPER_DEFAULT_24V // All axes (override below)

Marlin.zip

Bug Timeline

new bug

Expected behavior

With LIN_ADVANCE, Z axis should move smothly

Actual behavior

The Z axis make noise and behave stragely, like griding

Steps to Reproduce

Compile marlin bugfix
change configuration ro LIN_ADVANCE
move Z + 10mm

Version of Marlin Firmware

origin/bugfix-2.1.x [cron] Bump distribution date (2024-09-29)

Printer model

ortur 4 v1

Electronics

skr 1.3

LCD/Controller

REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

Other add-ons

2209

Bed Leveling

ABL Bilinear mesh

Your Slicer

Cura

Host Software

None

Don't forget to include

• A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

No response

[moriamoria]

Hello,

Just an extra information.

On my printer i have a belt on z and z2.

I have comment usage of z2.

Thé z axis move correcly, but After starting print thé print process freeze

Regards

[thinkyhead]

@tombrazier — Could there be some strange timing interaction between LIN_ADVANCE and other axes? It's only supposed to affect the E axis, and then only when there is actual extrusion going on. What do you think would cause that?

This could be caused by any number of things, including interactions with other features. If there was a change in Marlin on a particular date that can be found to be the definite cause, that is the kind of information that can help move us forward.

Would you be able to test some bugfix-2.1.x commits to narrow this down?

The strategy is to find a commit from some point in the past where the feature works. Then, test a commit from halfway between that date and today…. And then you keep going to the commit half-way in between your "known to work" commit and your "known to be broken" commit until you find the exact day where it broke.

If you started from a point 256 commits in the past, it would take no more than 8 tests to find the exact commit that broke it.

The git bisect tool is made especially to do this, but it can be tricky for the average user, and configuration options sometimes change. But if it is a relatively recent issue then it may not be too hard to locate.

[thinkyhead]

@moriamoria — Is the attached configuration correct that your Y_DRIVER_TYPE is A4988 while the rest are TMC2209 ?

[thinkyhead]

Some extra feedback from Claude Dev :

After reviewing the code, there's no direct connection between LIN_ADVANCE and the Z-axis that would obviously cause extra noise. However, LIN_ADVANCE does affect overall stepper timing and can interact with other motion systems in complex ways. Here are a few thoughts:

1. LIN_ADVANCE increases the computational load in the stepper ISR (Interrupt Service Routine). This could potentially cause timing issues that affect all axes, including Z.

2. The advance_isr() function, which handles LIN_ADVANCE, is called in the main stepper interrupt. If it's taking too much time, it could affect the timing of Z steps.

3. LIN_ADVANCE modifies the E (extruder) stepper behavior. If your printer's Z movement is somehow coupled with extruder movement (e.g., in some delta configurations), this could indirectly affect Z motion.

4. There's a comment in the code about LIN_ADVANCE potentially causing lost steps in X and Y axes due to timing issues. While it doesn't mention Z, similar issues could potentially affect the Z axis.

5. The la_interval calculation in the isr() function could potentially interact with Z stepping intervals in ways that cause irregular motion.

To troubleshoot this:

1. Try reducing the LIN_ADVANCE K factor to see if it reduces the noise.
2. Check if the noise occurs during specific types of moves (e.g., only during retractions, only during certain layer changes).
3. Monitor CPU usage and see if enabling LIN_ADVANCE is causing the processor to approach its limits.
4. If possible, try updating to the latest Marlin firmware version, as LIN_ADVANCE has seen improvements over time.

If the issue persists, it might be worth investigating the specific hardware setup of your printer, as the interaction between LIN_ADVANCE and Z-axis noise could be due to a unique aspect of your configuration.

[moriamoria]

Many thanks for your support.

First on Y I have set an closed loop driver. This is why I have Y_DRIVER_TYPE is A4988.

After, I have follow your sugestion, try from the past a version and apply my configuration.

I have been able to have an uncomplete optimize firmware that works.

To help the comunitie and for the plaisure to answer, I will try by dichotomy to find the commit that causes the issue.

I will need some time because make changes are different from version 2.1.2.4 to 2.1.x.

Following the version and commit that works:

🔖 Version 2.1.2.4 fff0d70 Scott Lahteine thinkyhead@users.noreply.github.com 16/06/2024 03:45:26

attache my configuration and my changes.

Thanks and regards.

Marlin.zip
marlin diff.zip

[tombrazier]

Well, first off, Claude Dev is scary.

Apart from Claude's correct general advice that LIN_ADVANCE affects the stepper ISR generally, I'd need to look at the code again. There have been quite a few changes since I last looked at the stepper code.

I'll wait and see if @moriamoria can some up with a commit where the behaviour first starts.

[moriamoria]

Hello,

Sorry I was busy, I dident move a lot.

But I have following result:

With branch 2.1.2.4, moving Z axis is perfect, but when I activate LIN_ADVANCE and input_shaping, the print is shrink in y axes. also, the purge pattern react like not moving.

With latest 2.1.x the Z axis behave strangely , but when I remove LIN_ADVANCE and input_shaping , I have again Z axes making noise.

I will continue my investigation this WE.

Thanks for you patiance

Regards

[moriamoria]

Hello,

After 6 hour of checkout, cherry pik configuration, compiling and test, I have finaly found the reason of Z stepper grinding and noise.
the following commit is the cause :

🔧 Assert EDGE_STEPPING with TMC drivers (#27292)

Co-authored-by: Scott Lahteine thinkyhead@users.noreply.github.com

#define EDGE_STEPPING is creating strabge noise with 2 stepper Z and Z2.

When I use only one stepper Z, it works.

In conclusion

my problem is not releated to LIN_ADVANCE, only when using 2209 driver and 2 stepper for Z.

Tel me if you want to rename or create a new issue.

Do you want me to do test with a scope on 2209 ? I will need help to give you more information.

Regards and thanks to all

[tombrazier]

My best guess is that my new adaptive multi-stepping is causing the noise and that timing changes related to things like EDGE_STEPPING and LIN_ADVANCE may or may not trigger the noise.

@moriamoria it would be helpful if you're able to check the pulse train on the STEP pins to see whether there is any jitter. And also to try defining OLD_ADAPTIVE_MULTISTEPPING in the config and see if that changes anything.

Something to note: EDGE_STEPPING is really helpful when putting an oscilloscope on the STEP pin because it results in fairly even high/low pulses. Without EDGE_STEPPING the high pulse can be very short in comparison to the low pulse. I find this often meant my scope misses the high pulse if the time base is adjusted for the step frequency.

[moriamoria]

Hello,

I will do the test this week.

Regards

[anomalchik]

Same issue. #27341

[tombrazier]

@anomalchik Do you fancy playing around with OLD_ADAPTIVE_MULTISTEPPING to see if it is connected?

[anomalchik]

@tombrazier I'll try it tonight

[anomalchik]

#27489

As I already said in #27341 One of motors remains in something like a brake mode.

[anomalchik]

@tombrazier I couldn't try it yesterday. I'll do it today.

[tombrazier]

New issue with more accurate information opened at #27489, which, in turn, was a duplicate of #27341.