Change G27 to allow Z raise if homing needed

[classicrocker883]

Description

When using G27 P3, this allows Z axis to be raised even if homing may be needed.
Same for G27 P4, allows XY to move if Z axis is not homed.

When a blocking move is done only in the Z axis, it moves up by NOZZLE_PARK_Z_RAISE_MIN which is around 10mm.

• Change G27 P3 to allow Z raise if homing needed
• • Allow XY if Z !homed (G27 P4)

---

• tweak ProUI caselight moved to other PR
• update macros.h so previous #define are above next call
• add millis_t to libs/duration_t.h
• duration_t.h/compat.h/stepper.cpp/motion.h/motion.cpp

unrelated but should be addressed

• src\lcd\extui\ftdi_eve_touch_ui\ftdi_eve_lib\compat.h IF_DISABLED(O,A) TERN(O,,A)
• • before it was defined as _TERN(_ENA_1(O),,A) which is the same as TERN_, which doesnt make sense.
• • it should be IF_DISABLED(O,A) TERN(O,,A), no?
• same with module/stepper.cpp, under FT_MOTION - ftMotion_stepper(), ENDSTOP_INTERRUPTS_FEATURE should enable the update, not disable??? (When FT_Motion enabled Print doesn't start and Homing failure [BUG]  classicrocker883/MRiscoCProUI#113)

Requirements

Benefits

Configurations

Related Issues

The only foreseen negative consequence of this change is if the axis is already near its max limit. This really should not be an issue, a user doesn't have to be extra careful in that regard knowing where the limit is.

But if a user just wants to raise the Z, homing isn't required, and this can be beneficial when aborting a print, when a print is complete, or just wanting to raise Z say if the head is too close to the bed, or printed part, for any reason.
Then G27 P3 can be used without needing to "Home"/"trusted axis"

[sjasonsmith]

I think your change to G27 is worth considering. Can you remove all the other unrelated changes from the PR, so that the G27 change can be reviewed and evaluated in isolation?

[sjasonsmith]

@InsanityAutomation now that the scope of this PR is very small, I'd like your opinion on these G-Code changes. The changes seem reasonable to me. Yes, with the Z-raise it may be possible to crash to the endstop, but it is a small move (presumably at low speed), and it is a compromise between that and potentially dragging across the bed or whatever else is beneath the head.

[InsanityAutomation]

With advanced pause, we allow either behavior with HOME_BEFORE_FILAMENT_CHANGE as the behavior is nearly identical. For consistency sake, I would prefer to see the option in configuration.h to allow or disallow this behavior. As @sjasonsmith notes, the impact is fairly small however the viable use cases are also few and far between. Personally I would configure my own machines to block the behavior. We could look at the axis trust factor on the function, and possibly allow it if position is is known but not trusted (eg manually set or steppers disabled prior) for a general case finding a middle ground that should be viable on both sides.

[classicrocker883]

oh i see so like in configuration.h add something like #define ALLOW_G27_ZRAISE, otherwise default to having it trusted.
the only other possible "compromise" is having it only allow to raise Z if axis is !trusted maybe 1 or 2 times.

let me know what I should do, option 1?

[InsanityAutomation]

Yup, adding the config option as described to allow this behavior is the route I would go.

[classicrocker883]

added if G27_BYPASS_TRUST is enabled, allows G27 P3 !trusted/homed Z axis
added to Configuration.h under NOZZLE_PARK_FEATURE

#define G27_BYPASS_TRUST              // Allows `G27 P3` to raise Z even if axis is not trusted

not sure about the wording/placement, but anyone got something better?

[thisiskeithb]

added if G27_BYPASS_TRUST is enabled, allows G27 P3 !trusted/homed Z axis
added to Configuration.h under NOZZLE_PARK_FEATURE

b47a445 disables this by default to retain existing behavior.

[classicrocker883]

I don't understand, what is causing the error in checks? only says operation cancelled on very last one. surely it cannot be something in this PR two files

[thisiskeithb]

I don't understand, what is causing the error in checks? only says operation cancelled on very last one. surely it cannot be something in this PR two files

Sometimes there are issues on GitHub's end. I restarted the failed job(s), so watch the checks page for details: https://github.com/MarlinFirmware/Marlin/pull/26789/checks

[classicrocker883]

Sometimes there are issues on GitHub's end. I restarted the failed job(s), so watch the checks page for details: https://github.com/MarlinFirmware/Marlin/pull/26789/checks

ok thanks, I figured it was something like that. seems to be working. it was strange because it was the same error a couple times in a row