Marlin: [BUG] Z_STEPPER_AUTO_ALIGN - compensate in wrong direction

[gucio1200]

Description

G28
G34
Start measuring , and compensating in wrong direction - opposit

Configs

Configuration.zip

[gucio1200]

Temp solution is to switch Z and Z2 cables.

[AnHardt]

Swap either motors or endstops.

[RudyBenner]

You have 2 Z steppers but are configured for 3.

_Try this_

/**
 * Z Steppers Auto-Alignment
 * Add the G34 command to align multiple Z steppers using a bed probe.
 */
#define Z_STEPPER_AUTO_ALIGN
#if ENABLED(Z_STEPPER_AUTO_ALIGN)
  // Define probe X and Y positions for Z1, Z2 [, Z3]
  #define Z_STEPPER_ALIGN_X { **25, 275** }
  #define Z_STEPPER_ALIGN_Y { **150, 150** }
  // Set number of iterations to align
  #define Z_STEPPER_ALIGN_ITERATIONS 3
  // Enable to restore leveling setup after operation
  #define RESTORE_LEVELING_AFTER_G34
  // Use the amplification factor to de-/increase correction step.
  // In case the stepper (spindle) position is further out than the test point
  // Use a value > 1. NOTE: This may cause instability
  #define Z_STEPPER_ALIGN_AMP 1.0
  // Stop criterion. If the accuracy is better than this stop iterating early
  #define Z_STEPPER_ALIGN_ACC 0.02
#endif

I have it set for 12 iterations right now,
I am considering increasing the amplification factor slightly.

I have a script I use as required:

G28              ;Home
M190 S60    ;bed heat on
G34              ;Auto Z Level
G29              ;Bed Levelling
M190 S0      ;bed heat off
G28 Z
M420 P1 Z2 ;turn on mesh and fade height
M500           ;write to eeprom

Works very nicely with Repetier Host

[bjbeare]

See: https://github.com/MarlinFirmware/Marlin/pull/13240

[thinkyhead]

Please test the bugfix-1.1.x and/or bugfix-2.0.x branches to see whether it helps. If the problem has been resolved then we can close this issue. If the issue isn't resolved in either of those branches yet, then we should investigate further.

[Minims]

Z Auto Align does compensate the probe position in bugfix-2.0
My Probe is X -34. I probe my first point in X+10. Currently the nozzle goes in X+10 instead of the Probe. It was OK with the version I was running 2 weeks ago. I've update to last commit, and this problem appears.

[556duckvader]

I have downloaded the latest 2.0 version and it still appear to be not working. I run G28 and G34 and it goes to my probing points and it still only moves my right side down each time. It will not move the bed up at all. I have even aligned the Z steppers by hand and it still moves the bed down each time I run G34 to the point it completely out of alignment.

[gloomyandy]

Are you sure you just don't have the two Z axes the wrong way around? Have you tried swapping them over by simply exchanging the two Z cables? I've been using G34 with no problems with 2.0.x, I originally had the drives the wrong way around and had the same problem you are describing.

[RudyBenner]

/**
 * Z Steppers Auto-Alignment
 * Add the G34 command to align multiple Z steppers using a bed probe.
 */
#define Z_STEPPER_AUTO_ALIGN
#if ENABLED(Z_STEPPER_AUTO_ALIGN)
  // Define probe X and Y positions for Z1, Z2 [, Z3]
  #define Z_STEPPER_ALIGN_X { **40, 180** }
  #define Z_STEPPER_ALIGN_Y { **110, 110** }
  // Set number of iterations to align
  #define Z_STEPPER_ALIGN_ITERATIONS **12**
  // Enable to restore leveling setup after operation
  #define RESTORE_LEVELING_AFTER_G34
  // Use the amplification factor to de-/increase correction step.
  // In case the stepper (spindle) position is further out than the test point
  // Use a value > 1. NOTE: This may cause instability
  #define Z_STEPPER_ALIGN_AMP 2   /1.6
  // Stop criterion. If the accuracy is better than this stop iterating early
  #define Z_STEPPER_ALIGN_ACC 0.02
#endif

[AnHardt]

Maybe a negative Z_STEPPER_ALIGN_AMP could also do the job.

However. The used algorithm is probably not the best possible one.
Instead of a fixed factor one could calculate that from the difference between two sets of probings. Like in a 'Newton Approximation'. That is likely to converge much faster and would correct the factors sign automatically.

[556duckvader]

/**
 * Z Steppers Auto-Alignment
 * Add the G34 command to align multiple Z steppers using a bed probe.
 */
#define Z_STEPPER_AUTO_ALIGN
#if ENABLED(Z_STEPPER_AUTO_ALIGN)
  // Define probe X and Y positions for Z1, Z2 [, Z3]
  #define Z_STEPPER_ALIGN_X { **40, 180** }
  #define Z_STEPPER_ALIGN_Y { **110, 110** }
  // Set number of iterations to align
  #define Z_STEPPER_ALIGN_ITERATIONS **12**
  // Enable to restore leveling setup after operation
  #define RESTORE_LEVELING_AFTER_G34
  // Use the amplification factor to de-/increase correction step.
  // In case the stepper (spindle) position is further out than the test point
  // Use a value > 1. NOTE: This may cause instability
  #define Z_STEPPER_ALIGN_AMP 2   /1.6
  // Stop criterion. If the accuracy is better than this stop iterating early
  #define Z_STEPPER_ALIGN_ACC 0.02
#endif

I applied this to my config and it still moves the right side down when I run the G34 command. I have attached link to a video of what it is doing.
https://www.youtube.com/watch?v=nsRCGrNgHiE

[556duckvader]

Just for fun I decided to swap the motors connections and it started working. I am not sure what swapping motor connections did but it works now.

[boelle]

@gucio1200 still with us?

[gucio1200]

Yup

[Aurawin]

After experiencing some problems with this issue I can say that with my dual z-axis wire orientation is verified (Z1->R (right), Z2->L (left)) I indeed (consistently) get a cumulative error.

I used calipers to verify that the left axis was indeed misaligned. I ran the alignment method and checked again but found the alignment method just added to the error making it twice as bad. And infect the more I ran auto-align the more it lowered my L axis causing stress on the lead bushing. Manually aligning the bed and running auto-alignment yields a very small error but it is again on the left side. My guess is if I kept running it the compiled error would be in the MM.

If I swap at controller board Z1->Left, Z2-Right it appears to help but there is still something wonky - if you use calipers. The swap results in a more level bed however, R was "lowered" compensate for the error that was on the left side instead of raising L at normal orientation.

I have disabled this feature for now.

[RudyBenner]

Z1 is left, Z2 is right.

You did not include your config files.

Works just fine here.

[Aurawin]

Z1 is left, Z2 is right.

You did not include your config files.

Works just fine here.

Umm - that depends on your setup. Z1 could be right or left. LOL.

define Z_STEPPER_AUTO_ALIGN

if ENABLED(Z_STEPPER_AUTO_ALIGN)

// Define probe X and Y positions for Z1, Z2 [, Z3]
#define Z_STEPPER_ALIGN_X { 25, 248 }
#define Z_STEPPER_ALIGN_Y { 150, 150 }

// Set number of iterations to align
#define Z_STEPPER_ALIGN_ITERATIONS 3
// Enable to restore leveling setup after operation
#define RESTORE_LEVELING_AFTER_G34
// Use the amplification factor to de-/increase correction step.
// In case the stepper (spindle) position is further out than the test point
// Use a value > 1. NOTE: This may cause instability
#define Z_STEPPER_ALIGN_AMP 1.0 // <<<---- tried tweaking this
// Stop criterion. If the accuracy is better than this stop iterating early
#define Z_STEPPER_ALIGN_ACC 0.02

endif

[Aurawin]

I was wondering - even with ABL, how DOES marlin know which stepper to lower and or raise? With single z-axis it's indifferent. With dual and triple Z it would be an entirely different matter.

Which brings me to the thought that there may be some assumptions made with Marlin to leveling and adjusting of axis and or build-pate.

Maybe there should be a section inside the configuration.h that clearly requires attention by end-users to provide marlin with the layout to which stepper is at X,Y(R) and X,Y(L)

This may effect ABL and Z-align

[sjasonsmith]

I am seeing the same issue on a printer with 3 Z motors. I am quite sure that I have verified that the order of the probe points matches the motor order. I will double-check this tomorrow to remove any doubt.

Unlike a 2 motor machine, I cannot reverse the probe order, because "reversing" a correction would require moving two other motors, not just one.

I have modified the G34 code to invert the correction direction, and I have successfully auto-aligned my bed with this change.

I can create a pull request to fix this, but it will break everybody who has worked around this for a 2-motor machine. I doubt any 3-motor users have been using this successfully, but I would love for somebody to prove me wrong!

Does anybody have a suggestion for how to fix this without breaking existing users, or to at least break them at compile time and not when they crash their print heads?

[AnHardt]

or to at least break them at compile time and not when they crash their print heads?

Option renaming. Sanity check for the old name giving instructions.

[AnHardt]

The algorithm is crap anyway.
Try a Newton approximation. Measure n_axis points, move the spindel with the largest error by a small amount (for example half the error), * measure again, calculate the change of differences and how much to go in next round to be right (approximate by assuming linearity Right could be the closer of the other points). Move the spindel with the highes error by the calculated way. Repeat from * until exact enough or not improving anymore.
If the sign of the initial move was wrong this is corrected in the first approximation..

[sjasonsmith]

I am quite sure that I have verified that the order of the probe points matches the motor order. I will double-check this tomorrow to remove any doubt.

I checked again and actually did have my motors in the incorrect order. The wiring in this printer is hard to access, and my initial method of verifying the order was flawed. With the order fixed I am seeing moves in the correct direction with the current code.

[RudyBenner]

Excellent.

[sjasonsmith]

I have spent a lot of time with Z_STEPPER_AUTO_ALIGN in my work to improve my triple-Z behavior. This includes testing with my printer only using two Z motors.

I am of the opinion that if this particular bug was an issue, it has since been fixed, and this bug should be closed.

[InsanityAutomation]

I agree, every case of this I have seen was steppers reversed from expected ordering. I intend to make this configurable at some point.

[boelle]

@gucio1200 is this still a problem for you?

[InsanityAutomation]

@boelle No, this should be closed

[aaronmrosenthal]

I have been having issues with G34 3 steppers...

1. I don't know if the order is correct.

define Z_STEPPERS_ORIENTATION 2:

//this is the stepper order, back right is Z0
2-1
-3-

I see lots of errors when I run G34.

1. I can't cross my plane without throwing invalid probe

// The size of the print bed

define X_BED_SIZE 610

define Y_BED_SIZE 425

// Travel limits (mm) after homing, corresponding to endstop positions.

define X_MIN_POS -140

define Y_MIN_POS -10

define Z_MIN_POS 0

define X_MAX_POS 600

define Y_MAX_POS 525

define Z_MAX_POS 1800

If I try and align near the steppers I get invalid probe. I can only use the range below without compiler error.

define Z_STEPPER_ALIGN_XY { { 10, 150 }, { 150, 10 }, { 250, 150 } }

Ideally I'd try below but can't get around this invalid probe issue.

M422 S2 X240 Y20
M422 S0 X500 Y400
M422 S1 X20 Y400

Thanks for any help with this! Trying to manually level 400x550 belts is bloody hell.

[thinkyhead]

@aaronmrosenthal — We just merged a G34 patch today. Please give the latest bugfix-2.0.x a try.

We don't do any kind of support to help out end users here. So if you need additional help with configuration please take advantage of these helpful resources:

• MarlinFW.org Marlin Documentation
• RepRap.org Marlin Forum
• Tom's 3D Forums
• Facebook Group "Marlin Firmware"
• Facebook Group "Marlin Firmware for 3D Printers"
• Marlin Configuration on YouTube
• Marlin Discord server. Join link: https://discord.gg/n5NJ59y

[github-actions[bot]]

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.