Z_tilt_adjust --> store Z adjustments

General Discussion
1

Basic Information:

Printer Model: coreXY with 3 Z-steppers
MCU / Printerboard: SKR pro

Hi,
after checking all klipper documentations I could not find an answer to this simple (?) question:
Z_tilt_adjust is working fine together with BLtouch. But: The printer is loosing the z_adjustments after homing. I’d like to store this Z adjustments so that they will be added to each z-axis for every print job.
→ I have good accuracy optical endstops on all 3 z-axis. The reference is fine. It is just somehow hard to finde the perfect adjustments for echa axis manually. Z_tilt_adjust is ideal for that, but I dont see how to make this adjustment permanent.

Thank you for any hints, maybe I am just missing something
regards
Andy

2

Standard x,y,z machine. My understanding is the z tilt levels the x axis and is done. There isn’t anything to save. The abl will correct for any small error.

3

You may use a different start procedure.

I do it this way:

G28    
M140 S[bed_temperature]
M109 S[first_layer_temperature_0] T0
Z_TILT_ADJUST                                             
G28 Z
BED_MESH_PROFILE LOAD=trex3

Saving the values makes no sense because the positions of the 2(,3 or 4) Z steppers can differ too much after shutting power off. Micro-stepping for adjustment and jumping back to full step after power off.

4

@ manac
Sorry, I didn’t get the point. Z tilt is adjusting independent multiple z axis motors.

@EddyMI3D
My setup has an endstop on all 3 z axis. So, g28 will bring all 3 z axis to a well defined position. But I would have to fine adjust each z axis to get the bed perfect leveled. This fine adjustment could be calculated once by z tilt and this values could be added to each z axis again after g28

Edit:I would also store that manually but I am not sure where I could store offsets for each single z axis

5

This will be different every time. Believe me. You can not get 100% the same position every homing. It’s about 0.01 of a millimeter. That can be changed by ambient temperature and other things.

If it would work like you say, Z_TILT_ADJUST would be obsolete.

6

hi,
to be honest: My bed warpage is far away from beeing below 0.01mm but practically good. (what I want to say with that: endstop accuracy of ±0.01 is totally fine for me but could maybe even improved with endstop phase implementation)
What I am currently doing successfully is adjusting the 3 z endstops so that my bed is leveled (bringing nozzle near the related z axis and level with a feeler gauge). But z tilt adjust can middle the complete bed and can find a compromise over the complete bed.
Z tilt is adjusting the z axis ~z -0.05, z1 -0.07, z2 +0.02 (by the way very consistently each time)
Now I have 2 possibilities:

  1. My current workaround plan is to note each z adjustment and adjust each endstop manually as they can be adjusted with a M3 screw
  2. Store the z adjustments as z, z1, z2 offset and add them to the axis after homing.

Option 2 would be more elegant as it could be done from time to time more easily (for example if something has to be changed on the bed)

7

I’m not sure I understand what is being asked here, so my response below may not help much.

If you have 3 z motors each with their own endstops, and you know an adjustment needs to be made after homing to those endstops, then you can use the Z_TILT_ADJUST tool to determine the adjustments necessary. If you know that the printer will always make the same adjustment to the Z on every Z_TILT_ADJUST (or, just wish to force it to make the same adjustment) then you can use the FORCE_MOVE command to forcibly alter each Z stepper motor by a static amount. So, for example, one could use the GET_POSITION command before and after a Z_TILT_ADJUST command to determine the actual stepper adjustments made to each Z stepper, and then use macros to make the equivalent FORCE_MOVE adjustments after every G28 command.

There is no automated tool to make these static adjustments. See the important warnings in the documentation on using FORCE_MOVE (in short, if it is used incorrectly it can cause all sorts of problems).

Cheers,
-Kevin

8

Hi Kevin,

yes you have the correct understanding of the “issue”
This “force move” makro is a very good workaround idea. Thanks for that, I will implement this together with a “stepper phase endstop” and I am pretty sure that I get good and consistent results.
Thanks Kevin :slight_smile:
btw. This is the printer with the two xycore heads on two independent gantries (our 2 software guys are still trying to establish a good custom klipper branch :smiley: )