No lower Z after home

[GMagician]

Not sure why it behaves this way but it's unpleasant to see Z moving down after home ends.
Worse when G34 is used just after home. You see Z moving up then down then up again.
With same parameters in configuration once it worked like now

[thinkyhead]

We have to allow for Z_AFTER_HOMING to move down if that's what a user specifies. This is probably most important for cases when Z homing is to the top. So simply making it impossible does not appear to be the right answer.

[thinkyhead]

Ah, well some of that is correct. But we do have this sanity check:

#if Z_HOME_TO_MAX && defined(Z_AFTER_HOMING) && DISABLED(ALLOW_Z_AFTER_HOMING)
  #error "Z_AFTER_HOMING shouldn't be used with Z max homing to keep 'G28 Z' safe for end-of-print usage. Define ALLOW_Z_AFTER_HOMING to allow this at your own risk."
#endif

[GMagician]

What is weird here is that blame doesn't report any recent change in code in line changed. Then something else changed the behaviour

[thinkyhead]

There seems to be a little wave of confusion happening around here regarding how we manage Z raises and other Z moves for homing, probing, tramming, leveling, etc. I see growing interest in how raises differ when the position is trusted and known versus when it is not trusted or unknown, when the probe is deployed or requires manual deploy/stow versus when there is no probe or the probe is known to be stowed, or when the raise needs to account for a changeable probe.offset.z versus when that may be safely ignored. We also have to consider the issue of probing for the benefit of CNC, where the top of the workpiece is probed to establish Z before working downward, and where a probe might snag on the side of the workpiece if Z is not raised sufficiently.

Anyway, it couldn't hurt to do another complete and thorough audit of the homing, leveling, and probing code.

As for this PR, I don't think it's entirely correct, at least not for everybody. Some will want their nozzle to move down closer to the bed after homing is completed, and right now this is the one supported way to accomplish that behavior without editing EVENT_GCODE_AFTER_HOMING.

If there is some concern about bad behavior connected to Z_AFTER_HOMING then maybe a sanity-check or #warning is the better way to go.

[GMagician]

I agree that there are a lot of different situations and different behaviours. What I noticed was that behaviour changed from my previous installed version. I though it was an error not considering that maybe it changed to fullfill someone else corner case.
However what I was expecting was a back compatibility. Fell free to close this (or I can close it for you). Let me know