Klipper not applying z_offset to future prints!

[Matgyver85]

FLSUN QQSP

I haven’t been able to get my required z_offset to apply.

Nobody has been able to explain the exact process to get the z_offset setting to actually apply to future prints.

My [probe] section is correct, according to the guides:

If I start a print, the nozzle is too high (~0.2mm)

I use the “z_offset” buttons in mainsail front-end to adjust my z-offset.

The nozzle lowers to the requested height, and the print continues.

I use the “SAVE” button to save the z_offset.

A popup tells me to use the SAVE_CONFIG option to save the z_offset to the config file, and restarts the printer.

I send the SAVE_CONFIG command.

The [probe] section in the “do not edit” section of the config file, updates with the proper z_offset that was saved earlier.

On the next print, the nozzle is AGAIN too high.

I adjust it back down another 0.200mm to correct the height.

The [probe] section in the “do not edit” area updates correctly AGAIN.

Next print, nozzle too high!

I can repeat this process, over and over again.

The new z-offset never seems to actually apply.

Can anyone explain this?

BTW I am using the Z_OFFSET_APPLY_PROBE as required.

Thanks

[theophile]

That value is for the difference in height between the probe and the nozzle and has nothing to do with the distance between the nozzle and the bed. If you’re live adjusting the z height while printing (“babystepping”) that will only apply to that print. If you want it to be persistent, make a note of how much you adjusted it to get it “right” and then add SET_GCODE_OFFSET Z=[your_value] to your start gcode.

[jakep_82]

You misunderstand how Klipper uses the probe. The Z offset on your probe does nothing to adjust your Z height, and should actually just be zero. I’m not super familiar with deltas, but I know they have endstops on each tower. Those endstop positions are what actually control the distance between the nozzle and the bed at Z0. To fix this you likely need to do a new delta calibration. You might also be able to use a gcode offset, but you might run into accuracy issues.

[Matgyver85]

If this is true, then why does klipper prompt you to save the “babbystepping” value to the config file which is literally saved for future prints?

I asked for a way to make THIS button:

Change THIS value:

… in a previous post, because I was apparently on the right track, however,
instead of having the “babystepping SAVE” button save the “probe offset” which apparently does nothing, shouldn’t the “babbystepping SAVE” button save the “babbysteps”?

I know it’s a wild idea to have an adjustment be saved AS the adjustment figure, but it all seems incorrect in the way it currently works.

How can we make the adjusted parameters be persistent in a fluid process similar to how Marlin was able to save the “babbystepping” figures “on-the-fly”?

[EddyMI3D]

I save the Z-Offset with this code:

Z_OFFSET_APPLY_ENDSTOP
SAVE_CONFIG

Or use this if you have a probe

Z_OFFSET_APPLY_PROBE
SAVE_CONFIG

[theophile]

@Matgyver85

If this is true, then why does klipper prompt you to save the “babbystepping” value to the config file which is literally saved for future prints?

I don’t know. I’ve never noticed or used that button.

@Matgyver85

I know it’s a wild idea to have an adjustment be saved AS the adjustment figure, but it all seems incorrect in the way it currently works.

I think the expectation is that users will properly configure their Z offset using procedures like PROBE_CALIBRATE and that micro adjustments like babystepping will only be used sporadically on an as-needed basis.

[Matgyver85]

@theophile

@Matgyver85

If this is true, then why does klipper prompt you to save the “babbystepping” value to the config file which is literally saved for future prints?

I don’t know. I’ve never noticed or used that button.

You have used this button if you have ever processed a “Z_OFFSET_APPLY_ENDSTOP” or “Z_OFFSET_APPLY_PROBE” command. Which I’m sure you have.

@theophile

@Matgyver85

I know it’s a wild idea to have an adjustment be saved AS the adjustment figure, but it all seems incorrect in the way it currently works.

I think the expectation is that users will properly configure their Z offset using procedures like PROBE_CALIBRATE and that micro adjustments like babystepping will only be used sporadically on an as-needed basis.

Some users may require babystepping adjustments more often than other users for a number of reasons. The assumed “sporadic” use doesn’t help to explain the incorrect use of a Z_OFFSET_APPLY_ command as a means for babystepping when it doesn’t actually adjust babysteps and is not permanent.

[theophile]

@Matgyver85

You have used this button if you have ever processed a “Z_OFFSET_APPLY_ENDSTOP” or “Z_OFFSET_APPLY_PROBE” command. Which I’m sure you have.

I have never used either of those commands and did not know they existed. But according to the documentation Z_OFFSET_APPLY_PROBE followed by a SAVE_CONFIG should do exactly what you want.

[Matgyver85]

I know! That’s what the documentation shows, but that is NOT how it actually works.
Hence, my posting here.

The Z_OFFSET_APPLY_PROBE followed by a SAVE_CONFIG adjusts the z_offset, but apparently the z_offset is not persistent, although it seems that it certainly should be persistent.

[EddyMI3D]

Can you please attach the klippy.log to your next post.

[jakep_82]

@Matgyver85

If this is true, then why does klipper prompt you to save the “babbystepping” value to the config file which is literally saved for future prints?

Klipper doesn’t prompt you for anything. Mainsail is doing this, and I don’t believe it’s “smart” enough to understand that adjusting the probe Z offset won’t change the Z height on a delta which uses endstops to home the towers. Using a gcode offset is something very different, and can lead to problems if you don’t have proper macros configured for start and end print.

[EddyMI3D]

@Matgyver85

The Z_OFFSET_APPLY_PROBE followed by a SAVE_CONFIG adjusts the z_offset, but apparently the z_offset is not persistent, although it seems that it certainly should be persistent.

As you have a delta printer, z-homing is done with endstop switches, not a probe.

For your z-offset save you have to use.

@EddyMI3D

Z_OFFSET_APPLY_ENDSTOP
SAVE_CONFIG

Not Z_OFFSET_APPLY_PROBE.

[Matgyver85]

@EddyMI3D

@EddyMI3D

Z_OFFSET_APPLY_ENDSTOP
SAVE_CONFIG

Not Z_OFFSET_APPLY_PROBE.

I WAS using Z_OFFSET_APPLY_ENDSTOP, but since my Z_offset is included in my [probe] section, I switched to using Z_OFFSET_APPLY_PROBE.
I thought that that may be the issue.

I can try it again.

So, If using the ENDSTOP command does work, should I still be using the lines:

SET_GCODE_OFFSET Z_ADJUST=-0.0 MOVE=1 (in start print macro)

AND

SET_GCODE_OFFSET Z_ADJUST=0 (in end print macro)

… Of course SET correctly?

OR, SHOULD only using the “babbystepping” commands (Z_OFFSET_APPLY_PROBE/ENDSTOP) be sufficient?

Currently, I am using the two lines that I questioned above by adjusting the offset value with any adjustment made with “babystepping” during a print.

It works, but isn’t very efficient. The process of “babystepping” should be immediately and permanently saved for the current, and any following prints.

Thanks

[Matgyver85]

Almost forgot the Klippylog. It’s a little bit of a mess due to changing many settings in an attempt to get this working, lol.

klippy.zip (1.9 MB)

[EddyMI3D]

@Matgyver85

I WAS using Z_OFFSET_APPLY_ENDSTOP, but since my Z_offset is included in my [probe] section, I switched to using Z_OFFSET_APPLY_PROBE.

The use of Z_OFFSET_APPLY_PROBE or Z_OFFSET_APPLY_ENDSTOP does not depend on whether there is a [probe] section or not.

It just depends on how the Z-homing is done.

Cartesian/Core-XY and other printers can use a probe for homing. A delta printer can not

I have a cartesian printer and use the probe only for the bed mesh. Homing is done by endstop witches. So I store the baby-step corrections with

Z_OFFSET_APPLY_ENDSTOP
SAVE_CONFIG

I control the Z-offset once in a while or when I fumbled around at the hotend. Then I do the small script and I’m fine.

New values like the Z-offset are stored by Klipper in the DO NOT EDIT section.

[Matgyver85]

@EddyMI3D

I control the Z-offset once in a while or when I fumbled around at the hotend. Then I do the small script and I’m fine.

What is this “small script”?

I will try saving as endstop instead of probe, but like I said, I had it set that way first. It didn’t work then either.

Can you confirm the use of the lines:

SET_GCODE_OFFSET Z_ADJUST=-0.0 MOVE=1

OR

SET_GCODE_OFFSET Z_ADJUST=0

?

[EddyMI3D]

@Matgyver85

What is this “small script”?

This one. I have it on a button on my Frontend GUI

@EddyMI3D

Z_OFFSET_APPLY_ENDSTOP
SAVE_CONFIG

I don’t use Z_ADJUST with Z_OFFSET settings/calibration

[Matgyver85]

I have been asking about THIS:

"Can you confirm the use of the lines:

SET_GCODE_OFFSET Z_ADJUST=-0.0 MOVE=1

OR

SET_GCODE_OFFSET Z_ADJUST=0"

SINCE DAY ONE!

Nobody could give me an answer regarding these lines that were in my config file.

Apparently, they are NOT needed.

The Z_OFFSET_APPLY_ENDSTOP did not work due to these lines existing.

I commented them out and changed my frontend macro to apply the Offsets to my ENDSTOPS instead of the PROBE.

It all seems to actually work now!

Thanks for your time, Eddy!

[theophile]

@Matgyver85

I have been asking about THIS:

"Can you confirm the use of the lines:

SET_GCODE_OFFSET Z_ADJUST=-0.0 MOVE=1

OR

SET_GCODE_OFFSET Z_ADJUST=0"

SINCE DAY ONE!

Actually, you asked about this about an hour before this post. Your original post didn’t attach your klippy.log like the issue template instructed, and it didn’t mention that your starting gcode (for some reason) included this command that explicitly overrides your Z offset and sets it to 0 every time.

@Matgyver85

Nobody could give me an answer regarding these lines that were in my config file.

Apparently, they are NOT needed.

Why did you put them there? Who told you they were needed?

@Matgyver85

The Z_OFFSET_APPLY_ENDSTOP did not work due to these lines existing.

It did work, you were just overriding it.

[Matgyver85]

@theophile

@Matgyver85

I have been asking about THIS:

"Can you confirm the use of the lines:

SET_GCODE_OFFSET Z_ADJUST=-0.0 MOVE=1

OR

SET_GCODE_OFFSET Z_ADJUST=0"

SINCE DAY ONE!

Actually, you asked about this about an hour before this post. Your original post didn’t attach your klippy.log like the issue template instructed, and it didn’t mention that your starting gcode (for some reason) included this command that explicitly overrides your Z offset and sets it to 0 every time.

@Matgyver85

Nobody could give me an answer regarding these lines that were in my config file.

Apparently, they are NOT needed.

Why did you put them there? Who told you they were needed?

The Z_OFFSET_APPLY_ENDSTOP did not work due to these lines existing.

ACTUALLY, I asked about this code 5 days ago in another post that you weren’t involved with, thankfully. Since I posted it, I think I would know. Good try though.

These lines were included in a pre-built config file FOR my printer, I didn’t just dream them up.

And, as I said " The Z_OFFSET_APPLY_ENDSTOP did not work due to these lines existing" Is exactly correct. You literally just reworded my statement.

theophile, if you have no useful input, which you clearly do not, there is no reason to attempt to be sarcastic and condescending, especially when you aren’t good at it.
Every post you have made here includes ZERO help and you are often incorrect. Go troll around somewhere else.

Again, thanks to Eddy for actually helping to understand the issue, I truly appreciate it!