Add option for Z_SAFE_HOMING position to be unaffected by M206

[evg-zhabotinsky]

Description

Scenario:
Using M206 to set XY home offsets while Z_SAFE_HOMING is enabled.

Observed behavior:
Point defined by Z_SAFE_HOMING_[XY]_POS respects those offsets and moves, even failing with echo:Z Probe Past Bed during homing if it tries to go beyond soft endstops.

Possible desired behavior:
The safe homing point stays in the same position relative to physical endstops, regardless of M206 offsets.

Solution:
Implement an option to enable either behabior: Z_SAFE_HOMING_POINT_ABSOLUTE.
That is what this PR does.

Requirements

Any non-delta printer, as M206 is unavailable on deltas.

Benefits

An option to decouple "safety" of Z homing from M206. Depending on how you use them, that might be useful.

In my specific case, I use M206 to define the actual printable area, and use Z_SAFE_HOMING to home Z at (0,0), outside the build plate, with an endstop that is below bed level. The reason for off-bed homing is to avoid both hitting the bed with the nozzle and releveling the bed every time I use a surface of different thickness. (I don't have a Z probe currently, so I can't automate that.) As is easy to see, moving (0,0) position onto the bed with M206 crashes the nozzle without this fix.

An alternative scenario is when homing with a Z probe to always use the same point for consistency, even if M206 is used to change XY offsets. In extreme scenarios, like moving (0,0) to the center to imitate a delta, the current behavior might even result in trying to home with the probe outside the build plate, resulting in a crash and/or grinding.

Configurations

None. Just enable Z_SAFE_HOMING and try with Z_SAFE_HOMING_POINT_ABSOLUTE both disabled (default) and enabled to test. Use M206 with XY offsets to observe effects.

Related Issues

#23021 might be related, or it might not. Found nothing else.

[thinkyhead]

I'd prefer that the safe homing position be set in machine (aka "native" or "raw") coordinates that are unaffected by workspace offsets, home offsets, etc., and that this should be consistent across builds. I don't really like adding an option that breaks consistency, especially for a behavior that should be well-defined.

[thinkyhead]

CC: @InsanityAutomation — Let's talk about reverting #19423 and finding a better solution for your use cases.

[InsanityAutomation]

I 1,000% disagree as a home offset should be a persistent home offset and a workspace / tool offset should be something different... I still firmly believe that the original function of applying it directly on homing to persist everywhere transparently was the correct application. The home offset is intended to be exactly what it says, You're offsetting the actual zero of the machine and everything should honor that. What people keep describing wanting is a tooling / workspace offset which is absolutely not the same as a home offset.

A home offset should be used for example when a persistent fixed mounted plate is changed that modifies the trigger point of the end stop. It would be in the case of replacing the end stop itself and offsetting by the small difference to get to the exact same positioning that was there before, or in the case of a new hot end plate being mounted to get the tool exactly where it was before as a fixed permanent item.

A tooling / workspace offset however is not expecting the trigger point for home to have changed, however is intending to offset the workspace based on the current application which is typical when finding your material zero on a CNC machine or laser etchers. This offset should honor existing soft end stops in the absolute positioning based on the physical switch as it is not expecting that there has been a physical underlying change that the offset is correcting.

The inconsistent behavior and the lack of enforcing it to follow standards over the years has caused confusion on what they are supposed to be and I believe that is causing people to look forward to do something it's not. My belief is the correct resolution is to have M206 100% enforced to everything, and better document use of G54 / implement G52 in order to cover these situations.

[evg-zhabotinsky]

I was suspecting that I am using M206 wrong, and the explanation kinda makes sense.

However:

• M206 still doesn't affect soft endstop positions relative to trigger point. Only MANUAL_*_HOME_POS do as far as I know. It definitely is relevant for soft endstop opposite the hardware one, but in weird configurations can be for both. (i.e. If I couldn't crash the axis before M206 I still can't after setting arbitrary offsets with M206, but if I could I still can.)
• What is the purpose of M428 then, also invoked with "Set Home Offsets" from LCD? It currently does "current position is now logically (0,0,0)" and you probably can't even go to the "real" (0,0,0) after making an endstop trigger earlier. At the same time, going to the corner of the actual printable area is possible by definition.

CNC coordinate systems, if enabled, look like they should do the job, since G54 et al moved by G92 can be saved to EEPROM. They may even be more convenient if switching beds often, provided that LCD menu entries are added to switch between them, plus one to call G92 X0 Y0 Z0 as alternative to "Set Home Offsets" entry. However, the option resides in Configuration_adv.h and thus is likely missing from most firmwares out there, plus currently at least using CUSTOM_MENU_MAIN is required to match the convenience of M206/M428.

What I'm saying, things could work the way InsanityAutomation described, and it probably would be for the best, but we aren't there yet.

[InsanityAutomation]

I just saw i never submitted what i started to type out the other day...

M206 may or may not be desired to affect soft endstop position on the opposing end. That depends on the situation. We may be best off looking to modify the auto retract feature in order to get in line with some other standards (eg G10) and match RRF on M208 to configure the soft endstops.

[DerAndere1]

Note that https://marlinfw.org/docs/gcode/M206.html says about M206:

Some uses include f[...] shifting the coordinate space to print on a different part of the bed

That seems wrong as for this use case there is G10/G54. I agree with InsanityAutomation: M206 should have a well defined purpose: to overwrite a single setting in the configuration. in this case probably MANUAL_*_HOME_POS. There should be a clear seperation of commands:

Command	Setting	Description
M206	MANUAL_*_HOME_POS	Set /offset home position
M208	*_MIN_POS, *_MAX_POS	Set endstop position (axis limits)
G10, G54	N.A.	Work coordinate system (non persistent)
G52	N.A.	Local coordinate system (non persistent)
G92	N.A.	set current position (non persistent)
N.A.	*_BED_SIZE	set printable area

[evg-zhabotinsky]

Notes on @DerAndere1 's post:

1. CNC workspaces chosen by G54&co ARE persistent. At least their individual offsets set by G92 are saved to eeprom according to docs. There currently is no way to persist the selected workspace to eeprom, though.
2. M208 and G10 are already taken by firmware retraction in Marlin, and incompatibly changing existing commands might end up like Python2 to 3 transition.
3. If M206 is used to set endstop positions, then M428 sort of stops making sense? Its use case becomes "Home to endstops, manually (with commands, not hands) move the head to where native zero should be (possibly unreachable) and then call M428."

Just saying, universality and compatibility is a huge can of worms, not even specifically with Marlin but in general. I've long lost count of cases where some feature that I need is just a few lines of code (that I often write for myself when sources are available, like in this PR) but making it available to everyone is a huge pain or makes no sense.

[thinkyhead]

At this time, we could add an option to completely revert M206 to its original behavior, if only for experimentation and comparison. Of course, we should look at the current code and audit the use of home_offset versus position_shift or workspace_offset (i.e., both).

As for defining the safe home position and other calibration-related positions, we first need to say in the configuration whether a position is defined in terms of Native Machine Space or in terms of Cartesian Space. We then need to define whether the M206 offset modifies Native Machine Space or Cartesian Space.

First, consider that the endstop positions are relative to a 0,0 bed corner, and they define the outermost bounds for motion. The 0,0 position is the outermost position for printing, and the bed size defines the other corners. All of these are defined in Native Machine Space, and workspace offsets don't move their physical positions, only their logical positions.

If an endstop is moved, you should use M206 to change its offset, and thus modify where 0,0 is. The outer bounds for motion may be increased or decreased by M206, but the printable area remains the same, and the physical position of 0,0 should remain the same. For the most thorough effect, M206 should make it so that Native Machine Space 0,0 is the printable bed corner, and so it should behave essentially as it did back in the olden days.

That is worth a try, and may help with some leveling issues if M206 Z is a common thing with opto endstops.