You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After reviewing the enable/disable methods and the way they interact with the state machine there are a few considerations.
The enable and disable methods only operate when the mover state machine is in a defined state
Should disable be allowed to work from any state which would necessitate some additional cleanup in the state machine to make sure FBs are reset when "the rug is pulled out from under them"
After a reset, what state should the mover return to. Trying to maintain the last state it was in before error at first glance is doable, but what happens when reset is mashed several times... it was in RUN, but on the second button mash it was in Enabling... where to go in this situation?
Maybe the proper solution is to make disable work at all times... and reset is just an alias of disable. Then both would require a re-enable afterwards explicitly defining states and workflows for these methods.
The reset block is intended to be an immediate call to MC_Reset with execute true and then false. McPower will typically stay on and re-enable the mover, and the state will remain in run.
While this is possible now via a Disable > ReEnable loop, adding Reset explicitly will be more intuitive for new users
The text was updated successfully, but these errors were encountered: