XYZ on display keeps switches between ??? and XYZ

[fabtopia]

When running RC6 the X Y Z on display keeps switching between X Y Z and ? ? ?. Is this normal. RC3 is working fine. Has it something to do with the new endstop config?

[Blue-Marlin]

This is wanted. Home your machine and all is as usual

[bdowling]

Why does it also do this after it has been left idle for a while? Because the stepper motors are disabled?
Seems like there could be cases where this could be a problem (resuming prints,perhaps, maybe warm up cycles? etc?)

[Blue-Marlin]

Blinking axis letters are not the problem - they indicate a (potential) problem.

1. 'X' <-> '?' indicates an unhomed axis.
2. 'X' <-> ' ' indicates the stepper was shut down after the axis was homed and may have lost a step.

(2) can be switched off with DISABLE_REDUCED_ACCURACY_WARNING

[fabtopia]

It worked but i thing i found unwanted feature:
if i do an G28 XY and then an G29 i would think the Z stop switchen between ? and Z. But it does not.

[thinkyhead]

Maybe we shouldn't allow G29 if Z hasn't been homed.

[jbrazio]

Maybe we shouldn't allow G29 if Z hasn't been homed.

This makes all sense, in fact G29 shouldn't be allowed if any of the axis is unknown.

[fabtopia]

So we first need a G28 X Y. That make sense. But the also G28 Z to find some home point and then reset that point bij starten G29. That take no sense and makes the process slow unneeded.

[thinkyhead]

@fabtopia It would be most welcome if code were submitted to make the first probe in G29 a special case – so it can double as the homing process for the Z axis. Of course, that is not the real purpose of G29 and would tend to expand its scope in a way not entirely expected by users.

I do agree that technically, establishing the home position for Z could be combined with the first probe in the G29 process. But with some machines, the Z home position depends on an endstop, sometimes a Max endstop, and on some machines, this Z endstop is a switch rather than a probe, with the probe only being used for probing. (At least, that is an option we continue to support.)

In any case, yes, it might even be trivial to add a conditional to the probing function, making the first probe a special case when Z has not already been homed. But this may produce inconsistent results, if Z is established at the first probe point in some instances, but at the XY home position (via G28) in other cases. And with "Z Safe Homing" the Z homing is supposed to be done at a particular point on the bed, so we would have to take that into account….

Anyway, if all this can be managed, without breaking user expectation or producing inconsistent Z homing positions, then perhaps it could be added as an extra option, for those users who have gotten into the habit of using G28 X Y and then G29 without homing Z.

[jbrazio]

I believe it's better to change bad habits, the description is clear in what is the objective of each g-code (G28, G29).

Having said this.. it's a one time change in the startup script of the slicer..

[fabtopia]

@thinkyhead and @jbrazio I understand the compatiblity problems my startup script can bring for other configurations. I will change my bad habbit for speed (i'm losing not that time with this change if i compare it to the total print time ;-)

Keep up the good work

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.