[FR] Universal Z Offset

[selalipop]

Description

I'd like to implement a universal Z offset applied to all forms of leveling, with live editing and automatic saving

Feature Workflow

1. User enabled any bed leveling option
2. User enters LCD menu or uses GCode to set a Z offset
3. New Z offset is immediately applied to print with live adjustments
4. User saves settings, universal Z offset is saved

Additional Information

I'm currently struggling with the many different Z offset concepts that conflict between bed leveling options:

The ones the save to EEPROM don't seem to handle live adjustment gracefully. M851 for example, has slightly confusing behavior where any rotation of the LCD encoder will babystep (leading one to believe the value is changing the print in real time), but trying to use GCode to update it's value won't do anything until a homing move. It took looking at the implementation to understand this, and that could be misleading to users.

There's also the multiple interfaces depending on the method used, for example, Manual Mesh Leveling has it's own implementation of a Z offset (which has lead to some confusion in the past: https://github.com/MarlinFirmware/Marlin/issues/3394).

---

I'd love to have an implementation of a Z offset that is applied in real-time, has an LCD UI, and saves to EEPROM.

The implementation of this seems pretty straight forward and I'm willing to tackle it.

In Planner::apply_leveling the value could be applied additively to the existing output of the method. I'd propose the value be applied before raw is sent to the selected bed leveling method

My understanding is the value would be added to ConfigurationStore to enable saving it.

Is there a convention for adding new GCode commands (also is this something that could warrant a new GCode command?)

One potential issue is different bed leveling approaches have vastly different Z offsets. While I don't believe this is something that changes often, this could be handled by storing a value representing the bed leveling method being used the last time the value was saved. When the user their leveling method, the value would be cleared, which is the behavior I would expect as a user.

[selalipop]

@thinkyhead I came across a comment of yours on a related feature request (https://github.com/MarlinFirmware/Marlin/issues/18867) that seemed pretty relevant to this, thoughts?

If my understanding is correct, this doesn't suffer from the responsiveness issue, since it's changing the Z offset at the same place the Mesh Bed Leveling Z offset is applied (and so should behave similarly in respect to live updates)

[selalipop]

Created a first crack at this to confirm the idea, and it worked beautifully for my purposes

Was very responsive while editing, was able to save to EEPROM and retrieve

Needs a few polish changes, but I would love to see something like this integrated, there are a ton of conversations in issues and all across the internet about Z offsets in Marlin. Having a simplified method that applies regardless of selected bed leveling system would be great

[AnHardt]

Adding just another kind of z-offset is not very likely to be a valid solution. It did not work the other times this was attempted (like with babysteps) - why should it now. Most likely it will just add another source of confusion.

[selalipop]

Babysteps are pretty confusing (or at least they were for me) because they're not really a Z offset, at best they're used while changing an actual Z offset to "emulate" live updates of the Z offset (like when Z Probe Babystepping is enabled). They can get out of sync with the value you're changing (which is what happened when I tried to use G-code while editing)

---

I'm coming from the point of view of a user who's fairly new to 3D printing and wants a way to:

Move their nozzle as they print, and save the amount they moved their nozzle for the next print.

It feels like it's something that should be very easy, but I found dozens of comment chains and issues addressing this, and a common theme is that "an offset should be an offset". Instead an offset may be an offset only applied the next time you home, or an offset that works in real time, or an offset that can only be saved if a certain combination of features is enabled (like Babystepping with Z probe).

I believe this is the source of most of the confusion, at the very least it was for me, and the reason I made this FR

---

I would actually love if something like this could replace the concept of per-bed leveling system Z offsets, since all of them seem to use the Z offset in the same way (subtract it from the Z value passed in, and then do their thing), it's just the interface for editing and saving them varies in unfortunate ways.

But I understand that's a much larger conversation. I believe this concept is to Z offsets, what UBL is to bed leveling, where they can co-exist while one is recommended as the "best of both worlds"

[SlickNickeL]

This is now an issue with our manufacturing 3 head printers. We used a fixed Z optical Endstop that is in perfect alignment with our REF screw (never adjusted and considered as fixed). This gives us a perfect Z -0- bed & heads. Only PITCH & ROLL screws are adjusted for a level plane. The Z height is then fixed and not adjustable except through M206. We use NO probes of any kind. Bed is manually trammed using our 3over3 or 3over4 tramming program. We tried the addition of Fixed_Mounted_Probe to use M851 to store babysteps which doesn’t work. It shows up on save settings in M851 but it never applies the offset in the first layer.

When having 3 heads down and printing a first layer, room temp will have an effect on the first layer, since our first layer is an aesthetic exterior, and must be perfect. This must be adjustable using babysteps and then stored for the next run. It would be impractical to do this on every run on every machine to manually adjust babysteps, on every first layer. Usually room temp and filament settle down and don’t need to be reset except for seasonal changes. Repetier uses a bed height changeable through LCD with a simple + or - value .000. Unit re-homes and the new value is set. No need to hook up a computer.

How hard would it be to have a universal offset (which M206 seems to be) where babysteps adjusted on the fly, can then be saved to the universal offset M206 through the LCD but not dependent on the LCD autolevel assist being selected.

Recap, no probe of any kind. All manual leveling. No mesh or autolevel. Babystepping enabled and can be saved to EEPROM to M206 as a universal offset. This IS the way M206 says it functions, regardless of any autolevel or mesh selected.