Homing Alarm 11 Not Asserted Following E-Stop

[engigeer]

I encountered an issue when homing required is enabled. It seems that Alarm 11 is never asserted following an e-stop with loss of position, but the machine remains in an Alarm state until the homing cycle is run. There is a message reported that homing is required, however these messages are not always visible (i.e., if I am operating the machine from a pendant / controller that only reports Alarm codes).

I'm thinking instead perhaps it would be better to mirror the handling case where homing is required but only some axes are homed.

core/system.c

Lines 466 to 477 in e272f77

	if (retval == Status_OK && !sys.abort) {
	state_set(STATE_IDLE); // Set to IDLE when complete.
	st_go_idle(); // Set steppers to the settings idle state before returning.
	grbl.report.feedback_message(Message_None);
	// Execute startup scripts after successful homing.
	if (sys.homing.mask && (sys.homing.mask & sys.homed.mask) == sys.homing.mask)
	system_execute_startup(NULL);
	else if(limits_homing_required()) { // Keep alarm state active if homing is required and not all axes homed.
	sys.alarm = Alarm_HomingRequired;
	state_set(STATE_ALARM);
	}
	}

[engigeer]

It appears that recent changes to the core have fixed this and I can now see the correct alarm state in ioSender.

Ideally, any change in alarm code would also result in an update sent to a connected i2c display / keypad. Currently the state of the machine_status_packet_t struct is updated via grbl.on_state_change, and it seems this handler is not called if only the substate has changed?

I wonder if you would be open to modifying this behaviour, or perhaps this would be best addressed with a small change to the keypad plugin method for updating the struct?

[terjeio]

I think the easiest option for now is to modify the keypad plugin since the substate is determined from data that is changed both inside and outside of the state machine, and even in interrupt context(s). If the current state is one that can have substates then just query the substate in send_status_info().
To aid this a bit I will add add a new define:
#define STATE_HAS_SUBSTATE (STATE_CYCLE|STATE_HOLD|STATE_ESTOP|STATE_ALARM|STATE_SAFETY_DOOR)
that can be used to check which states that can have substates, e.g. something like this:

if(state & STATE_HAS_SUBSTATE) {
    substate = state_get_substate();
    ...
}

[engigeer]

Apologies for the poor commit message. It seems I used my master branch to open this previous PR and then mistakenly pushed the changes here when testing the code you shared for PR #920.

In either case, the changes you shared worked perfectly and were ready for merge, so many thanks for your help. I will close #920 as complete.