LIN_ADVANCE make Z axis making noise and grind
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)
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
- [X] A ZIP file containing your
Configuration.handConfiguration_adv.h.
Additional information & file uploads
No response
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
@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.
@moriamoria — Is the attached configuration correct that your Y_DRIVER_TYPE is A4988 while the rest are TMC2209 ?
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:
-
LIN_ADVANCEincreases the computational load in the stepper ISR (Interrupt Service Routine). This could potentially cause timing issues that affect all axes, including Z. -
The
advance_isr()function, which handlesLIN_ADVANCE, is called in the main stepper interrupt. If it's taking too much time, it could affect the timing of Z steps. -
LIN_ADVANCEmodifies 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. -
There's a comment in the code about
LIN_ADVANCEpotentially 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. -
The
la_intervalcalculation in theisr()function could potentially interact with Z stepping intervals in ways that cause irregular motion.
To troubleshoot this:
- Try reducing the
LIN_ADVANCEK factor to see if it reduces the noise. - Check if the noise occurs during specific types of moves (e.g., only during retractions, only during certain layer changes).
- Monitor CPU usage and see if enabling
LIN_ADVANCEis causing the processor to approach its limits. - If possible, try updating to the latest Marlin firmware version, as
LIN_ADVANCEhas 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.
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 fff0d703610199f1133ff1073ee21ef2269ebab7 Scott Lahteine [email protected] 16/06/2024 03:45:26
attache my configuration and my changes.
Thanks and regards.
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.
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
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 [email protected]
#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
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.
Hello,
I will do the test this week.
Regards
Same issue. https://github.com/MarlinFirmware/Marlin/issues/27341
@anomalchik Do you fancy playing around with OLD_ADAPTIVE_MULTISTEPPING to see if it is connected?
@tombrazier I'll try it tonight
https://github.com/MarlinFirmware/Marlin/issues/27489
As I already said in https://github.com/MarlinFirmware/Marlin/issues/27341 One of motors remains in something like a brake mode.
@tombrazier I couldn't try it yesterday. I'll do it today.
New issue with more accurate information opened at #27489, which, in turn, was a duplicate of #27341.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.