Soft-limit changes can cause dangerous misunderstanding due to homing required, suggest alarm on enable or change to axis length

[5ocworkshop]

Over on the PrintNC discord we've been helping new users get their grblHAL boards up and running and a recent discussion highlighted the current behavior around enabling soft-limits.

As noted in the notes section of IOSender for soft-limits, they require that the machine be homed in order to take effect.

For new users it is easy to miss this and in their excitement, fail to realize the logical need for it.

To be confirmed, but it has also been reported that changing the axis length while you have soft-limits enabled will invalidate the 'homed' state and homing is then required again before the new axis length takes effect. This leaves the new user setting up their machine for the first time in a position where they could have had soft-limits working and by making an axis-length change they invalidate their homed state and could crash their machine unexpectedly as a result.

I would like to propose that the act of enabling soft-limits or changing axis lengths (when soft-limits are enabled) causes a default (but toggable, so edge case users can override the raising of the alarm in this situation) alarm condition indicating that the limits configuration has been changed and that limits may not be accurate and homing is recommended before proceeding.

There also seems to be some situations where the "Save" function is not always applying the settings changes, although we have not been able to consistently characterize this and some of it may be user related. By having the alarm, you would get an explicit confirmation that your change to limits has applied and the machine is in an un-limited state until homing is completed.