[BUG] z probe offset isn't working

[CMcKenzie74]

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

Yes, and the problem still exists.

Bug Description

1. I run a bed level using BLTouch and store setting.
2. do a test print and use babystepping to find the z probe offset.
3. put the value from previous step into the z probe offset under configuration and store setting.
4. when doing a print after these steps the z probe offset seems to be ignored and I have to run through step 2 again.
5. if i power off the printer the prints seem to work fine unless I run another bed level which forces me to run through step 2 again and the z probe offset value keeps getting bigger. My Marlin setup files.zip

Bug Timeline

new I have just upgradded my ender 3 Max with a BTT E3 turbo and BL Touch

Expected behavior

I expected the setting for the Z probe to stay in config and retain it for every print even after a g29.

Actual behavior

the z probe offset seems to be ignored.

Steps to Reproduce

1 run a bed level procedure (g29). 2 run a print.

Version of Marlin Firmware

bugfix-2.0.x downloaded 09\07\21

Printer model

creality ender 3 Max

Electronics

BTT e3 turbo board

Add-ons

BL Touch

Your Slicer

Cura

Host Software

SD Card (headless)

Additional information & file uploads

No response

[lmocanu]

I can confirm I have been having the same issue with Z-offset babystepping not being taken into account after restarting print.(bugfix branch, with E3 Mini v1.2 and BLTouch clone).

[CBDesignS]

(quote) I run a bed level using BLTouch and store setting. do a test print and use babystepping to find the z probe offset.

Is the bltouch rotuine saving the mesh for you ? Once you have worked out the Z offset are you saving the settings then reloading the settings to make the new settings active ?? m500 saves eeprom then you need to m501 to load and activate the new settings ? if you do it in terminal. If you use lcd then once you enter offset then you need to store settings then you need to Load settings so that the controller knows it is working with new offset.

you say it works after a reset (because it is forced to use the new updated / saved offset) It may be the fact you are missing 1 step and that is possibly causing this problem.

[lmocanu]

It is not an issue of saving/loading configuration; the issue is that after reset, saved Z-babysteps values are not added to current Z value. Thus, Z-babysteps need to be set again; Since the old value is still there, its value increases again and again.

[CMcKenzie74]

After the test print and changing the z offset using baby stepping I did then store the setting, I wasn’t aware that you then needed to load the setting to make the new z offset setting active I will try it and let you know.

[CBDesignS]

lmocanu I must have been miss informed because I was told that babysteps were only an "on the fly" adjustment to help get a good first layre if you could not dial in your settings while configuring the Z height & offsets, Are you using a tft in tft mode ? as in btt tft35/mks tft50 etc with the posh looking menus and icons or a standard 12864 Marlin type lcd ?? I can remember a while ago that the babysteps had problems on the tft screens because of the way they work (they are a controller & not just an information display) like the good ole 12864 screens and the problem was in the screen firmware & not with marlin firmware. " the reason I changed back from posh tft to the good ole 12864 lcd screen"

[lmocanu]

Yes, I use the TFT35 v3 screen in GUI mode. I have not tried the old LCD format tbh.

[CBDesignS]

I would have a try in Marlin mode instead of gui/tft mode. My tft35 is in the box as I could never get it to work as I wanted. I spent many an unhappy hour in the firmware trying to get it working and gave up. Those screens are mini controllers that have firmware and the firmware used to be buggy as hell (the problem may be fixed in newer firmware updates) but I gave up because the bugs were reported and never fixed unless a user could code and fix the mess left by MKS & BTT .. Check for the latest screen firmware and try Marlin mode to see if it helps.

[nsarzyns]

I have a similar issue with the Z probe being incorrect and the Z probe offset wizard just not doing anything useful. When I updated, I didn't change anything on my printer or with the mount but using my old Z probe offset of -1.31 was no longer valid. I used the Z probe offset wizard and that gave me a value of -1.45, still very wrong. After trial and error, I found a working value to be -1.91

Nothing changed on the printer except the firmware. Eeprom with reset and reinitialized as a test didn't fix the issue.

[loetefix]

same here. z offset takes no effect on skr1.4turbo with marlin 2.0.9.1

[CMcKenzie74]

lmocanu I must have been miss informed because I was told that babysteps were only an "on the fly" adjustment to help get a good first layre if you could not dial in your settings while configuring the Z height & offsets, Are you using a tft in tft mode ? as in btt tft35/mks tft50 etc with the posh looking menus and icons or a standard 12864 Marlin type lcd ?? I can remember a while ago that the babysteps had problems on the tft screens because of the way they work (they are a controller & not just an information display) like the good ole 12864 screens and the problem was in the screen firmware & not with marlin firmware. " the reason I changed back from posh tft to the good ole 12864 lcd screen"

I am aware that babystepping is a way of getting your reference offset, which is what I put in my initial description of this issue. I do have a MKS TFT35 installed on my printer but I mostly use it in marlin mode as I have found that it can be problematic in touch screen mode.

[CBDesignS]

I think this still all relates to the firmware for the screen. Maybe the screen is saving the babystep data & if adjusted it is not overwriting it but just adding to the saved data (this may explain the problem you are getting) I do not use babystepping but I have the same hardware and have no problem with it. I have spent many an hour getting the glass beds level as possible tho. I hope you find the solution and get printing without tinkering..

[DerAndere1]

This looks like a duplicate of issue https://github.com/MarlinFirmware/Marlin/issues/21833

[thinkyhead]

More details are needed. Please log information using M420 after each adjustment, before and after saving to EEPROM, after reboot, etc. Of course, make sure you are actually using BABYSTEP_ZPROBE_OFFSET and that the display interface is actually doing the right thing with respect to this option. The more data we have, the better able we are to narrow down the true problem.

[Zloyuzver]

Marlin 2.0.9.1 and buffix for him. The printer does not remember the configured Z-offset. Configured from marlin 12864 screen emulation on TFT43 from BTT. With every new print, you have to re-adjust the Z-offset. Automatic bed leveling is not activated in firware settings (Configuration.h and Configuration_adv.h). After setting up the Z-offset, I saved them to the EEPROM and immediately loaded them from there. Nothing helped.

[GJSchaller]

I'm running into similar issues with an EZABL and a SKR mini E3 v2.0 - no matter what I seem to set the Z Offset to, the print will begin (which includes a G29), and then the Z offset is wrong - under 2.0.8 (the BTT fork), it would be too close to the bed, under 2.0.9.1, the nozzle would be too high. I'm using Bilinerar leveling if that matters at all, and not even doing Babystepping - the initial Wizard results are close, and then the nozzle is off to the point that the filament is either entirely blocked, or so loose it doesn't squish / adhere to the bed at all.

I'll try to log some M420s over the next few nights when I am home from work and have the free time.

[GJSchaller]

I had a bunch of comments earlier that were more confusing than helpful, so I deleted them and will summarize here.

It seems like when G29 is run, it causes the position of the Z Home to change somehow. Although the Z Offset itself is the same, the nozzle will hit the bed, and if you recalculate the offset, it's higher than it was before. Each time you re-run G29, the problem repeats, so the offset value needs to be recalculated between each print.

As a work around, I tried adding a G28 Z to my start code in Cura after the G29, and this seems to be a temporary fix. Whatever the bug is that's causing the position of Z's home to change, re-homing Z forces it to update and be correct, so the print can proceed without needing to change the offset value.

So the problem is not Z Offset, it's what the printer considers "Home" for Z is changing when G29 is run.

My setup is an Ender 3 Pro, BTT SKR mini E3 v.20, EZABL, Marlin 2.0.9.1 Vanilla.

[GJSchaller]

Update - even after a print finishes, and I re-home at the beginning of the next print, the Z Offset needs to be manually updated and recalculated. It looks like the only way to correct the Z Offset Bug is to potentially reboot / reset / initialize the EEPROM. I'll try to test more when I am back next week, see if I can confirm what specific actions will clear the issue.

[thinkyhead]

What kind of LCD display are you using @GJSchaller? Is that display actually updating the value of M851 Z or is it actually modifying the value of M206 Z?

[GJSchaller]

What kind of LCD display are you using @GJSchaller? Is that display actually updating the value of M851 Z or is it actually modifying the value of M206 Z?

Stock Ender 3 Pro supply. I can attach / send my Configs if you’d like.

Edit: So I’ll set the Z Offset, run a print, and it will be fine. Without changing anything, the next print will have the Z issue. Something in the act of printing is causing the change in Z.

[GJSchaller]

Z Probe Offset Bug Hunt Process:

Display is defined as: CR10_STOCKDISPLAY

• Power on printer
• Init. EEPROM
• Z Height is currently 5.00
• Run Z Offset Wizard *** Result is -2.10mm
• Run test print w/o G29 - Print successful.
• Run Z Offset Wizard *** Result is -1.30mm
• Run (same) test print w/o G29 - Print successful.
• Run Z Offset Wizard *** Result is -0.10mm (Edited for correct value.)

Even without the G29, the value of Z is changing after each print. @thinkyhead I can send you my Configuration.h file and the test print file, if you'd like.

[GJSchaller]

Update - ran some more testing tonight.

• Started by powering on the printer, and flashing the latest bugfix compiled this afternoon. Loaded defaults.
• Ran Z Probe Offset Wizard. Staring values: Z0 = 5.00, Probe Offset is 0.00 Photo
• Results: Offset: -1.90mm
• Ran test print (no G29)
• Ran Z Probe Offset Wizard again. Starting values: Z1 = 5.00, Probe Offset is listed as 3.10 Photo

Note that 3.10 = 5.00 + -1.90... is it possible the Offset is being re-calculated somewhere? It's happening outside the Wizard, as it was happening when I set it manually as well.

As a further test, I loaded the Defaults, which corrected all issues. The Offset was back to 0, and I could calculate it normally.

[GJSchaller]

Thought - since the print itself seems to be fine once calibrated, could the cause be in the End Code?

G91 ;Relative positioning
G1 E-2 F2700 ;Retract a bit
G1 E-2 Z0.2 F2400 ;Retract and raise Z
G1 X5 Y5 F3000 ;Wipe out
G1 Z10 ;Raise Z more
G90 ;Absolute positionning

G1 X0 Y200 ;Present print
M106 S0 ;Turn-off fan
M104 S0 ;Turn-off hotend
M140 S0 ;Turn-off bed
M84 X Y E ;Disable all steppers but Z
M117 Brazen bless this print!

(The last M117 is a running blessing from an RPG I play, don't mind it unless it's causing the error.)

[GJSchaller]

In regards to #21833 - my setup is using an EZABL, and it uses the Z-Endstop connection to trigger (as opposed to the BLTouch port on the board).

[GJSchaller]

Confirming this is still an issue as of Sept. 14th, 2021.

[nsarzyns]

I'm still having this issue too. The Z probe offset changes every time I turn the printer on or restart a print. Rolling back to a previous firmware doesn't have the issue so it's not a physical printer issue. Today, I went from a Z probe offset from -1.39 to -1.05 to -1.29 and now -1.91. It's all over the place. I tried the bugfix, issue still exists. I need to adjust with babystepping on every print. Rolling back is the only fix.

Something I was wondering is it could be the Z endstop triggering at different times. I still use the Z endstop. I have the Z probe plugged into the probe header on the SKR mini e3 v2. It is the stock ender 3 screen. I'm not sure what would cause the endstop to trigger differently between releases but it's something I need to test.

[GJSchaller]

There was another bug (#22524) related to the EEPROM on the SKR mini v2 that may be the cause of this? If it's having problems committing the value when saving it, that may be the cause here. Is anyone having this problem on a board other than the SKR mini E3 v2?

[nsarzyns]

Hmm I'm not sure. It seems to get committed to eeprom. I can read back the values between power offs and it does persist. It just needs to be changed with almost every print.

Something just occurred to me, one thing that changed was the environment definition in .pio file. It's late right now so I might not be verbally clear but this issue might have appeared when I had to change which processor I selected the board had. I think before there was some 512k option a lot of people used for the skr v2 but that wrong and was fixed.

Am I not remembering correctly?

[GJSchaller]

That's actually a good point - even when I reset the EEPROM and re-calculate the Z Offset, it varies from session to session. Sometimes it's over -2mm, sometimes closer to -1. It's certainly not as consistent as fixed hardware should be. That might be a clue to solve this.

[moham96]

Facing the same issue, very annoying. I have to change the offset each time i turn on the printer, I go from -1.900 to -1.300 to -1.500, note that the offset is saved fine to EEPROM, it's just somehow used incorrectly each time and that's why i need to change it each time :(

[nsarzyns]

Today again, between multiple prints I had to change the offset 3 different time. Largest swing between values was 0.7. Again, nothing is changing mechanically.

[GJSchaller]

This appears to be getting worse, or at least have more... interesting things happen in later releases.

I used to be able to clear EEPROM, set the offset, and one one clean print. Now, when I clear the EEPROM, and run the print, the purge line comes out fine, and the actual print begins with the nozzle scraping the bed.

I'm going to try to roll back to an earlier version of Bugfix 2.0.9ish to see if that fixes the latest issue. Rolling back to 2.0.8 or 2.0.7 would require taking apart my machine and replacing the EZABL with a BLTouch, but I may need to do that if we can't nail this down.

[GJSchaller]

@thisiskeithb - It looks like you have a good amount of experience with the SKR mini E2 v2 - are you able to assist with this bug? What further information can we provide to help track it down and eliminate it?

[nsarzyns]

@GJSchaller Have you tried an earlier version of the bugfix branch? Or even further back? I haven't tried the newest release nor the latest bugfix commit. Funny thing is my co-worker has basically the same setup as me with the excepting of the SKR mini E3 v2 and was running 2.0.9.1 without any issues. I thought about giving klipper a try but I try to shy away from klipper with how, for lack of better word, toxic that community is. Been chewed out on the reddit page for asking basic questions and how dare I compare it to marlin.

[GJSchaller]

@nsarzyns - I tried 2.0.8.x last week, and the bug was still present. I'm going to try 2.0.7.2 tonight, I made the change in firmware to 2.0.9 around the same time I installed my EZABL, so I never did confirm when / where the bug was introduced. Hopefully I'll be able to use my printer again after rolling back.

[numpad0]

I just encountered what seems a similar problem, albeit in 1.1.9(not 2.x). Z probe offset worked fine for years within -1mm to +1mm range, but today I had to change the value to way over 5mm and it simply didn't work. Maybe some sanity checks or value clamping code is causing it?

[psychoph]

Any update on this issue? I think I am running into the same issue with a reality silent board 4.2.7 on an ender 3 pro with Marlin 2.0.9.2. I will run the z probe wizard to come up with a consistent -0.7 offset and then when I print I scratch the crap out of the bed until I stop the print. I manually tune the print and I come out with a -0.25 offset that seems to work for short prints.

[SwagDad99]

I am fighting this on my JGMaker Artist-D Pro running latest upstream 2.0.9.2BugFix.

[jurajdanis]

Same problem here. Seems like z offset is commited to memory, however same z offset value produces different nozzle-bed gap height. I my case the margin ranges from 0.05 to 1.7. Problematic part about this is, that when I go G28 a then G0 Z0, nozzle hits the bed despite offset was set up fine during the last print, or after homing with G28, lowering to Z0 goes fine and z offset value is displayed correctly, but when I adjust the z offset by any value (0.01 e.g.) it drops nozzle 1-2mm down.

M500/M501 does not change anything, Z offset value is stored correctly, seems like (as mentioned in earlier comments) that problem is in Z0/Home position changing randomly during the prints.

Right now, running marlin 2.0.1/E3V2 4.2.2 with CRTouch. I can't find any higher marlin version with crtouch support to test.

[C0rn3j]

@jurajdanis

I can't find any higher marlin version with crtouch support to test

What do you mean? 2.0.9.3 supports CR Touch just fine

[SQL-enwiki]

Rolling back to a previous firmware doesn't have the issue so it's not a physical printer issue.

@nsarzyns What version are you rolling back to that works?

[nsarzyns]

@SQL-enwiki Honestly I don't remember. I moved to klipper after fighting this issue for too many versions of Marlin. As toxic as the Klipper community can be it's actually really good. Haven't seen this issue ever again since switching. Marlin is great, but this issue pushed me away for at least my current printer

[descipher]

I can confirm that there is an issue with the offset function manual or wizard on a bltouch. It does not compute correctly.

Loaded Creality stock with manual offset:

      0      1      2
 0 -0.101 +0.041 -0.234
 1 -0.062 -0.028 -0.254
 2 -0.253 -0.188 -0.289

bugfix-2.0.x with manual offset:

      0      1      2
 0 +3.987 +4.027 +3.792
 1 +3.988 +4.001 +3.772
 2 +3.853 +3.913 +3.842

Same offset M851Z-1.4

Value M851Z4 looks inverted as well this setting of offset to +4.0 appears to correct the actual Z position.

Also noticed that if consecutive G29s are issued it will result in a +1 to the entire grid. After reset it's back to the initial setting of M851.

[descipher]

Looks like this issue occurs when the #define PROBE_OFFSET_WIZARD_START_Z -4.0 is not set to start below the probe deploy point. By setting the value to 0.0 I can consistently cause the miscalculation to occur.

After setting it to -4.0 here is the result:

Bilinear Leveling Grid:
      0      1      2
 0 -0.106 +0.027 -0.132
 1 -0.084 +0.004 -0.147
 2 -0.179 -0.036 -0.022

[sarvenn]

I have reported an issue about Z offset consistency and adjustment delay. I think ABL function is broken somehow. https://github.com/MarlinFirmware/Marlin/issues/23781

[sarvenn]

I can confirm I have been having the same issue with Z-offset babystepping not being taken into account after restarting print.(bugfix branch, with E3 Mini v1.2 and BLTouch clone).

I have the same issue and in addition to this issue while using the TFT touch mode (BTT TFT35) there is too much delay whenever I adjust my Z offset while printing, it takes like 20 seconds for Z stepper to react. https://github.com/MarlinFirmware/Marlin/issues/23781

[thinkyhead]

Looks like this issue occurs when PROBE_OFFSET_WIZARD_START_Z is not set to start below the probe deploy point….

We could do a sanity-check of the configuration, anyway, to make sure that PROBE_OFFSET_WIZARD_START_Z is set below the probe offset point, and maybe some kind of runtime check. Or, maybe there is some way that PROBE_OFFSET_WIZARD_START_Z can be ignored or overridden when it's too small.

[thinkyhead]

too much delay whenever I adjust my Z offset while printing

That is to be expected. You can try the experimental INTEGRATED_BABYSTEPPING option to see if it improves babystepping generally.

[sarvenn]

too much delay whenever I adjust my Z offset while printing

That is to be expected. You can try the experimental INTEGRATED_BABYSTEPPING option to see if it improves babystepping generally.

When I use Manual mesh bed leveling (nozzle as probe), there isn't any delay at babystepping while printing. Is it normal to have a delay at ABL but not at MBL? I think the delay is because the current gcode command in progress. It looks like it is waiting for the current gcode command to be finished. But this doesn't apply to MBL. I will give a try for integrated_babystepping though.

[DiskDoctor]

I'll add some detail to this problem. Marlin 2.0.9.3, I'm still trying different combinations of settings to isolate WHY the z probe offset is being ignored.

Specifically, CRTouch is used to auto home, then any of 3 methods (Measuring and setting via M851, Z probe offset wizard, gcode via terminal used to determine Z offset) to set z probe offset, yet as soon as G28 is issued, Z ZERO is set to the probe trigger point, NOT the trigger point minus offset.

No adjustment below 0 is allowed, unless M211 S0 or firmware disable of soft endstop. During print, including pre-print line purge using starting gcode from Cura, babystepping can be used to lower nozzle but is not a small number, requiringe many many turns of knob. Print then continues normally, no issues.

Next print, same issue, ignoring the offset, even when babystepping used, new offset set and confirmed via M851. Tried with the following enabled and disabled. No difference.

#define BABYSTEP_ZPROBE_OFFSET // Combine M851 Z and Babystepping

Potential workaround in startup gcode: M211 S0 M90 G1 Z-0.60 G92 Z0

where -0.60 is replaced with your measured offset.

I have tested this using Pronterface step by step but not in slicer and print yet.

It seems either the offset is being ignored AND/OR

When soft endstop for Z is enabled, any command to move below ZERO is stopped at 0, or G28 or simply Z home is resetting Z zero point without including negative z probe offset

Questions and tests: One test to narrow down is to disable soft endstop for Z in firmware and see if Z probe offset is properly applied.

Is there an accessible variable to retrieve offset value from printer that can be included in the workaround code that will manually apply the offset value stored in the printer?

Where is the Z zero minus offset value calculation located? Would adding M211 S0 before calculating be helpful? Can M211 S1 be turned back on afterwards?

Can G92 (or something else) be used to set a value that is not the current position? In other words, can gcode be used to set Z zero position to (z probe trigger point minus offset) without moving nozzle to that point, to avoid nozzle touching the bed?

What about using G92 to set abs(offset) of offset, thereby making zero point of Z that increment lower? IE: G92 Z.060 Where .060 is absolute value of the z probe offset. Perhaps this can be used in starting gcode, if z probe offset value is retrievable and usable?

Would reinstalling mechanical Z stop and placing at bed level (below probe trigger point) and NOT using probe as Z endstop be of any use? How would that affect automatic leveling?

Hope this is helpful

[SwagDad99]

'#define BABYSTEP_ZPROBE_OFFSET // Combine M851 Z and Babystepping' Fixed mine...