M851 & Z Probe Offset does not work with Bilinear, endstops & BL Touch

[willeywilson]

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

No, but I will test it now!

Bug Description

SKR 1.4 Turbo, BL Touch on an Anycubic Chrion with optical end stops & Dual Z. AUTO_BED_LEVELING_BILINEAR MANUAL_Z_HOME_POS set to 5.175 (notes do not accurately reflect what this function does, had to learn about it here in order to get the machine working even remotely correctly https://marlinfw.org/docs/hardware/endstops.html) NOZZLE_TO_PROBE_OFFSET { 4.5, -37, -2.065 }

Bed is probed and returns values from -0.34 to -0.51.

Then with a G28, M420 S1, G1 Z0 the nozzle is approximately 0.13mm too high from the bed, confirmed with baby stepping during a live print.

Changing M851 Z-2.07 to M851 Z-2.2 (i.e. the 0.13mm change required) makes no difference and appears to only be used for the initial probing.
In Marlin 1.1.9 M851 Z would allow you to change Z offset values in real time. The Z Probe Offset value on the LCD is also ignored (assume it uses the same M851 command)

Therefore a) how do I permanently lower the nozzle 0.13mm in relation to this mesh bed level. b) why is M851 ignored until next probing event.

Configuration.zip

Bug Timeline

New 2.0.8

Expected behavior

M851 updates to be reflected in real time and allow for accuracte nozzle offsets.

Actual behavior

M851 and Z Probe Offset completely ignored once Bed Probing is saved.

Steps to Reproduce

G28, M421 S1 G1 Z0 nozzle is 0.13mm too high. M503 shows M851 Z-2.07 M851 Z-2.2 M500 M503 shows M851 Z-2.2

G28 G1 Z0 nozzle is still 0.13mm too high

Version of Marlin Firmware

2.0.8

Printer model

Anychubic Chiron

Electronics

SKR 1.4 Turbo

Add-ons

BL Touch

Your Slicer

Cura

Host Software

OctoPrint

Additional information & file uploads

No response

[spikedsoft]

I have pretty much the same setup (BTT SKR1.4 Turbo on a Chiron with BL-Touch)... I also had the exact same problem. You can read about it here https://github.com/MarlinFirmware/Marlin/issues/21727

The solution so far has been to use the BL Touch for Z-homing and enabling Z_STEPPER_AUTO_ALIGN and using G34 to align the Z motors. It would be nice if it would work with the endstops though...

[willeywilson]

@spikedsoft I have read that thread, thanks.
Have you had to move the black and white wire into the Z End Stop position or can I do everything within the firmware and just deactivate z-min & z-max end stops? It would be nice to use the end stops indeed, although having managed to get it level perfectly, ran a print, the next print is miles off on one side of the bed which is a tad annoying to say the least.

[spikedsoft]

@willeywilson If your BL-Touchj is already working for probing, you don't have to rewire anything. Just enable USE_PROBE_FOR_Z_HOMING and Z_SAFE_HOMING and DON'T enable Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN, then it will use the probe pin for Z-homing. Also set #define Z_MIN_PROBE_PIN P0_10 (That's assuming that you connected the BL-Touch probe pin to the probe pin on the mainboard).

I attached my config for reference. MarlinConfig.zip

[willeywilson]

@spikedsoft So I bascially did that already after reading this https://marlinfw.org/docs/configuration/probes.html unfortunately it absolutely refuses to home Z, and when I ask it to level z it attempts to do it but gives up assumingly because it goes past the Z_PROBE_LOW_POINT, so I am wondereing whether to just turn that off and run the risk of crashing the through the bed if the BL Touch fails.... but that still doesn't answer why it doesn't home Z at all when clicking auto home.

Thanks for your config, I'll have a look through it now and see if I can spot any differences.

[willeywilson]

Do you still have the endstops plugged in? I ask as our config.h's are almost identical bar some personal preferences and the only thing I can think is that I unplugged my endstops when I undefined Z_MIN & Z_MAX in the last iteration.

[spikedsoft]

Yes the endstops are still plugged in.

[willeywilson]

OK, my bad, resolved the hole not homing Z issue.

on Octoprint it was showing "Z Probe Past Bad". In my Config.h I had set Z_SAFE HOMING_X_POINT & Y_POINT TO X_MIN & Y_MIN to reflect the stock Chiron homing sequence. However, my BL Touch is at -4, +37mm, therefore it was out of bounds.

Upon rechecking your config.h @spikedsoft I realise yours is homing in the centre.

I've now changed it to:-

if ENABLED(Z_SAFE_HOMING)

define Z_SAFE_HOMING_X_POINT 100 // X point for Z homing

define Z_SAFE_HOMING_Y_POINT 30 // Y point for Z homing

and it has sucessfully homed and completed a Z stepper auto align sequence. No I just need to get it to park back at 0,0,0 once it has homed Z so its not spewing molten plastic onto the bed.

thanks for your help. Although it doesn't take away from the Issue topic in the first place, therefore still open.

[willeywilson]

Ok, I have now wasted nearly 2 weeks of my life on this. I have got z stepper auto align working etc but still CANNOT get M851 to what it is supposed to do.

I'll do a G28 and z will raise to +5 I'll do M420 S1 and the value of Z now changes to +4.95. G1 Z0 leaves the nozzle 2.4mm from the bed, the exact same amount as Z Probed Offset is set to.

My conclusion is the firmware only looks at M851 value when its creating the mesh bed point, it then completely ignores it going forward such that the Z Home position and the True Z0 position (nozzle touching bed) are never properly related to each other. The only work around I can find now is to set a Z offset in my slicer, which is less than ideal.

[willeywilson]

also, note to add:- Recv: X:200.50 Y:242.00 Z:5.00 E:0.00 Count X:16040 Y:24200 Z:2000 Recv: ok Recv: echo:endstops hit: Z:7.42

The "endstop hit" value is the exact value I need it to drop by when performing a g1 z0 to have the nozzle touching the build plate.

[willeywilson]

Downloaded the nightly build and chose UBL instead of Bilinear. M851 now appears to work as intended. Now I'll have to try re-enabling the z end stops to turn off this horribel Z Stepper Auto Align routine and improve the mesh bed levelling.

[willeywilson]

Update to add that whilst UBL appears to work better, it still completely ignores M851 in every regard. I have used a dial test indicator to get this bed level and it still wont print right.

[SwiftNick]

M851 sets the difference between the nozzle tip and the probe trigger point. Changes to this value will not alter any levelling mesh you have saved in EEPROM.

If you are only using the probe for bed levelling, then any changes you make using M851 will only affect the next probe cycle that you do.

If you want M851 changes to move the starting height of the print, then you must use the same probe as your Z end stop. The changes will take effect the next time you home.

willeywilson, The Stock Chiron is a bit different as the Z home position leaves the nozzle tip about 2mm above the bed. So under normal print conditions, the firmware allows the head to travel below the Z home position by disabling the end stops during a print.

To make things even more confusing, the ALL value on the stock Chiron touchscreen does mirror the M851 value, but it does not behave in the same way. When you edit the 'ALL' value using the levelling menu, the firmware does alter all of the 25 mesh points. When you send an M851 it does not.

[willeywilson]

Prior to this I was running Marlin 1.1.9 on my Chirons which when using Bilinear you could send an M851 zx.xx command and M500 mid print and it would adjust the Z height live.
One of the Chirons has the newer screen which was unsupported in 1.1.9 and therefore this was the only solution I had, and why I was familiar with it working this way. However this clearly isn't how 2.0.8 works and I've now accepted that lol.

Given I now understand and agree that M851 is only used for probing to create the mesh in the first place (although diasspointed as this seems a regression from 1.1.9 behaviour), I took to using UBL. Once I got this working with using the BL Touch to home, I then swapped it back to using the end stops to home.

The issue here was that my UBL mesh was almost completely -1.9 - -2.0mm, which whilst the first layer went down okay, my prints are coming out with a 2mm z height stretch. I wondered if (now) chaning the Z offset to 0mm or turning off fade height would resolve this issue and I could live with it. It did not.

So now I have yet again gone back to using the BL Touch to home, UBL for leveling, and G34 for Z stepper alignment. My first layer on the latest print is going down nicely and I will have to wait and see if the Z height issue is resolved (I suspect it will be) now that my bed mesh is -0.1 - -0.2mm.

Note to add, that I had allowed the printer to go below the endstops in order to get it to put a first layer down whilst using the stock chiron Z end stops. The only issue I couldn't manage to correct for was the bed mesh being -2mm or so causing the Z stretch on my prints. If I could resolve this I would go back to using the optical end stops over the BL Touch and G34 every print.

[skellatore]

I have/had this problem too #22274

I bet if you follow the working changes I did it will resolve.

[DerAndere1]

This z probe offset issue probably still exists but at least you should now be able to use whatever bed leveling method you like again. There was a bug in bed leveling on top of this probe offset issue. To isolate the probe offset issue, I suggest to update to current bugfix-2.0.x after commit https://github.com/MarlinFirmware/Marlin/commit/154decfc66c30808cfe7320e542fcf90427d7176 and test again.

[thinkyhead]

Maybe we can have @mwinters-stuff or @swissnorp give the current Probe Offset Wizard a test and have a look at the code and make sure it's doing the right thing. Someone might try adding logging to the probe offset wizard, to collect data about where the problem lies.

[mwinters-stuff]

I have just done a basic run through the wizzard and adjusted the offset and run off a print, using yesterdays pull of bugfix-2.0.x and started a print, it all worked fine. I dont have complicated setup, UBL mesh is being used and there is no extra zstop's just the cheap BL-Touch nock-off..

[credomane]

I dunno if this bug is the bug I'm running into but it sure seems like it so here goes.

I've spent nearly a week trying to figure out why marlin release 2.0.9.1 will respect z-offset on my stock creality v2.2 board but ignore it on my BTT Octopus V1.1 board. Tonight I finally figured something out and I'm totally scratching my head as to why. I haven't tried the 2.0.x bugfix source yet but I will tomorrow or later today would be more accurate...I've been up too late already trying to figure out why z offset won't work properly for the 4th or 5th day in a row now.

I also have AUTO_BED_LEVELING_BILINEAR enabled same as the OP. I do not have the wizard enable. Ender5Plus has a crappy DGUS display that doesn't work with stock marlin so I'm currently headless. Octoprint/Pronterface is my screen. lol

Config differences between the two boards are as follows.

ConfigName	Creality V2.2	BTT Octopus V1.1
MOTHERBOARD	BOARD_RAMPS_CREALITY	BOARD_BTT_OCTOPUS_V1_1
XYZE DRIVER_TYPE	A4988	TMC2209
Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN	enabled	disabled

Stock Ender5Plus board works 100% as expected. G28, G29, M851 all good and G1 Z0 touches nozzle to bed.
BTT Octopus V1.1 board doesn't work as expected. G28 and M851 are Good, G1 Z0 leaves a gap (because zoffset is being ignored). G29 fails since the Zoffset is being ignored so it makes it easy for any probe point to exceed the value of Z_PROBE_LOW_POINT. At least I think that is the what is triggering the "hold up something's wrong here" halting the printer with probing failed during G29. I spent way too long barking up the wrong tree there.

Literally minutes before finding this issue I got Z-offset working on my Octopus board for my Ender5Plus. What did I do? Why I enabled Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and, naturally, moved the trigger pin for the BLTOUCH from the dedicated pin to the ZMin Pin and like magic zOffset wasn't being ignored anymore. To prove I wasn't losing my marbles I disabled that setting and moved the wire back. Zoffset ignored. swapped that the setting (and wire) back-n-forth a few times and yeah. Each time I had Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN enabled on the Octopus board z-offset worked like a charm. Each time I had it disabled then it would be ignored.

I don't know the inner works of Marlin from a hole in the ground so to me the only thing that setting is doing is change what pin is being used for the BLtouch trigger pin. I really wish I knew what was going on here. I really don't want to have to continue using this ugly breakout cable for the bltouch to z_min pin.

[DerAndere1]

Even with a probe installed, you may have configured Marlin to use endstop limit switches for homing. In that case, NOZZLE_TO_PROBE_OFFSET is only relevant during bed leveling but irrelevant during homing, so MANUAL_Z_HOME_POS has to be set. This makes sense and it is in accordance with the documentation at https://marlinfw.org/docs/hardware/endstops.html#microswitch-used-for-homing,-probe-for-bed-leveling.

With that in mind, lets have a look at the code: https://github.com/MarlinFirmware/Marlin/blob/ed0c5aefd8c79d88f5b5fb69baae161b58c72eae/Marlin/src/inc/Conditionals_LCD.h#L927-L932

This logic basically says: if Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN is disabled and USE_PROBE_FOR_Z_HOMINGis enabled, the probe will be used for homing . if Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN is disabled and USE_PROBE_FOR_Z_HOMING is disabled, the endstop limit switches will be used for homing and NOZZLE_TO_PROBE_OFFSET is not relevant during homing. if Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN is enabled, the probe will always be used for homing .

@credomane : For the config with Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN disabled, try to enable USE_PROBE_FOR_Z_HOMING and report back if that makes home position depend on NOZZLE_TO_PROBE_OFFSET . Also try it with Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN disabled, USE_PROBE_FOR_Z_HOMING disabled and set MANUAL_Z_HOME_POS. If that solves your problems, this was not a bug but expected behaviour

[credomane]

Did you mean USE_PROBE_FOR_Z_HOMING not USE_PROBE_FOR_HOMING?

My ender 5 plus doesn't have a Z endstop so BLTouch probe must always be used or the nozzle will crash.

Here is my z-offset_broken.zip config and my z-offset_working.zip config.

I was running stock marlin 2.9.0.1 without an LCD at all because Marlin doesn't support the Ender5Plus's crappy DGUS/DWIN display. I came across a marlin fork earlier this week that has custom DGUS/DWIN firmware for the Ender5Plus display. Since I managed to get z-offset working again, granted with a hacky workaround, I switched to that fork today after finding a workaround for the Z-Offset not working. Using the Forked 2.9.0.1 firmware the "bug" persists in exactly the same way as with the stock firmware.

The only change to my config from stock to the fork is the addition of DGUS_LCD_UI_RELOADED to configuration.h

[edit]
I've done all the debugging I can think off too.

My "official" z-offset testing has been the following: M502, M500, M851 Z-2.71, M500, G28, G1 z0

With the working config the bed and nozzle are touching because zoffset is working.
With the broken config the bed and nozzle have a significant gap of about...2.71mm because zoffset is being ignored.

I've tried shoving a power cycle in after either or both M500 commands and still nada.

[edit2]
I'm behind on stuff my wife is wanting printed and since I technically have the printer working I'm going to get caught up on that stuff first. I'll be back to test out the bugfix-2.0.x stock marlin branch in a couple days. See if my issue is something that has been fixed already.

Also I looked at my Ender3Pro's configs. Since it is also using the dedicated BLTouch pins on the board and not the ZMin Endstop. Ender 3 Pro is running Marlin 2.0.7.2 with Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN disabled and `` enabled and zoffset works fine. But on my Ender5Plus running 2.9.0.1 this same setup doesn't work. Here's my Ender3Pro_2.0.7.2_working.zip config for funs.

Perhaps there is something I missed that someone could point out? Otherwise I'm totally going with this is a bug/regression sometime between 2.0.7.2 and 2.0.9.1

[edit3]
Ha! Looks like the forked marlin's DGUS/DWIN implementation (DESUUUU's) just got merged into the marlin bugfix-2.0.x a few hours ago. That will make things easier when I test the bugfix branch in a couple days and see if this problem is fixed or not. :D

[edit4]
Had a chance to try out the Marlin 2.0.x bugfix branch. issue is resolved there. Would still like to know what caused the issue. I know the probe and endstops got some refactoring recently but I don't see anything anywhere that should have caused my problem. Whatever. Running on the 2.0.x-bugfix branch until the next marlin release. lol

[github-actions[bot]]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[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.