MarlinFirmware
[BUG] z probe offset isn't working
Did you test the latest bugfix-2.0.x code?
Yes, and the problem still exists.
Bug Description
- I run a bed level using BLTouch and store setting.
- do a test print and use babystepping to find the z probe offset.
- put the value from previous step into the z probe offset under configuration and store setting.
- when doing a print after these steps the z probe offset seems to be ignored and I have to run through step 2 again.
- 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
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).
(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.
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.
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.
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"
Yes, I use the TFT35 v3 screen in GUI mode. I have not tried the old LCD format tbh.
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.
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.
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.
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..
This looks like a duplicate of issue https://github.com/MarlinFirmware/Marlin/issues/21833
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.
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.
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.
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.
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.
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?
What kind of LCD display are you using @GJSchaller? Is that display actually updating the value of
M851 Zor is it actually modifying the value ofM206 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.
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.
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.
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.)
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).
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.
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?
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?
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.
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 :(
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.