✨ Z_HOMING_WITH_PROBE_AFTER_Z_ENDSTOP

[12oclocker]

Description

Home to bed using probe after endstop homing.
Some machines require multiple Z endstops to sync
the Z motors properly.

Z_HOMING_WITH_PROBE_AFTER_Z_ENDSTOP will
enable a new capability that uses the probe to home Z to bed
surface after Z endstop homing.

This allows "Z Probe Offset" changes take effect
without having to rebuild any bed leveling meshes.

This will fix marlin reported bugs...
27680, 22653, 21727, 21833, 27821

AUTO_BED_LEVELING_BILINEAR has reported on
bugs when using a probe with Z endstops.
This newly added code will solve those issues.

AUTO_BED_LEVELING_UBL may work without this
code, but any change to "Z Probe Offset"
will require the bed mesh to be rebuilt if
this function is not used.

Requirements

Requirement for the new code to take effect,
define Z_HOMING_WITH_PROBE_AFTER_Z_ENDSTOP
enable any Z endstop sensors as well as a probe

Benefits

For machines with Z endstops and probes; 
This allows "Z Probe Offset" changes take effect
without having to rebuild any bed leveling meshes.
Fixes multiple bug reports.

This will fix marlin reported bugs...
27680, 22653, 21727, 21833, 27821

AUTO_BED_LEVELING_BILINEAR has reported on
bugs when using a probe with Z endstops.
This newly added code will solve those issues.

AUTO_BED_LEVELING_UBL may work without this
function, but any change to "Z Probe Offset"
will require the bed mesh to be rebuilt if
this function is not used.

Configurations

Attach Configurations ZIP and any other files needed to test this PR.
Test Configs are for AnyCubicI3 mega with BLTOUCH and MKS_MINI_12864_V3 display
configs.zip
Make sure to add "Z_HOMING_WITH_PROBE_AFTER_Z_ENDSTOP"
to the Configuration.h file

Related Issues

This will fix marlin reported bugs...
27680, 22653, 21727, 21833, 27821

[thinkyhead]

Overall a good implementation of the concept. A tiny bit hackish in using a global flag that costs one byte at all times, but on the other hand not the worst way to modify behavior across a few different methods. We might be able to get away with adding another parameter to homeaxis instead, passing true when we are homing Z with the probe. And then we also must pass the flag to functions that homeaxis calls which are affected by z_homing_use_probe.

Anyway, I am also looking at the automatic probe offset solution for moody probes, which would put full trust the Z endstop and base the Z probe offset on that during initial G29 probing. The key thing is, we need at least one known value to establish Z0 that we can base everything else on. If the probe is very trusted, then probe-based homing is best. If the probe is mercurial then we have to trust the endstop. The only other alternative is to force the beleaguered user to make manual adjustments for every new session. Between all these alternatives and babystepping the probe offset, we should end up with a pretty good suite of complementary features to get that Z0 and bed mesh dialed in.

[thinkyhead]

Made some modifications to the description. There is no reason that Z homing cannot be done with the nozzle, and the utility of this feature is tied to a machine with a Z axis that must home to MAX, for one reason or another. This may be best for machines with a Z bed that homes to the bottom.

TODO: It makes sense to require Z_SAFE_HOMING for this feature because the behavior already encoded in home_z_safely will ensure that the probe is over the bed, at the position the user prefers. But, it will behave slightly differently, only applying home_z_safely for the second, probe-based, Z homing, not the first endstop-based Z homing, which presumably it matters not where the nozzle is in the XY plane.

[12oclocker]

@thinkyhead I agree with your changes and comments. I started an attempt for the flag to be just a function parameter, and unfortunately that opens a can of worms into other functions which seems to bloat the code worse than the global flag.... the global flag seems to follow suit with variables such as relative_mode and z_min_trusted which already existed... Maybe combining relative_mode and z_min_trusted and z_homing_use_probe into a single uint8_t later down the road and using bits for flags would be better, that would probably have to be evaluated though.

I have required Z_SAFE_HOMING as you have recommended, though the home_z_safely function is slightly different than needed during re-homing. home_z_safely does not move Z first to prevent dragging nozzle across the build plate. Also home_z_safely is not in a scope that can be called directly from motion.cpp, luckily all we need is just a Z move to probe deploy position, then XY to Z_SAFE_HOMING position, which is simple enough. A case could be made that instead of a recursive homeaxis call, we simply call it twice from G28.cpp, then home_z_safely is in scope, but also home_z_safely would need modified so that Z moves first, which may alter other functions that depend on home_z_safely to remain as it is. As the code is now everything works fine and home_z_safely is unmodified.

I also noticed TERN0 TERN1 and TERN only work for defines that are defined to 1 or undefined. Thus I had to fix a section of my code which use_probe_bump was not actually grabbing the value of Z_CLEARANCE_BETWEEN_PROBES when it should have. That issue is now also resolved.

I have tested the newly modified version of this code, running on my AnyCubic i3 Mega machines, and it is working well.