Open 5ocworkshop opened 2 years ago
Did some testing:
Powered on machine and homed.
Disabled soft-limits. Machine stayed homed.
Jogged around.
Enabled soft-limits. Machine stayed homed (contradicts what I reported above via user feedback, that enabling soft-limits lost home position).
Changed any axis maximum travel distance, machine loses home and therefore soft-limits.
So it appears the alarm case would only apply when soft limits are enabled while the machine is not homed, and/or a maximum travel distance for an axis is updated.
So it appears the alarm case would only apply when soft limits are enabled while the machine is not homed, and/or a maximum travel distance for an axis is updated.
IMO an alarm should (only?) be raised if $22
Homing on startup required flag is set. I'll add that.
BTW soft limits check does not check for homed status, but should? $40
Limit jog commands enabled does. FYI soft limits check functionality was carried over from legacy Grbl "as-is" to keep it compatible, limit jog commands is a grblHAL addition.
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.