-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible problem on timed_transitions #22
Comments
Ping, anyone has managed to use timed transactions to same state? |
Hi, this is what I used and it seemed to work:
This is the output - I pressed the button after a little while:
After the button press, the machine keeps the RPI state. |
In case anyone runs into this, there's a limitation that isn't super obvious in the FSM code as it is implemented. The state isn't recorded as being changed until after the on_enter is called on the new state. As a result, if you use trigger to send an event from the start of the new state, it won't find a transition from that new state to the next state. i.e., if you have three states "one", "two" and "three", and you have a timed transition from two back to itself, it'll get called forever if you try to do a trigger(three) in the start method for two. I fixed it in a local copy of the library by moving the m_current_state = transition->state_to; line in make_transition above the transition->state_to->on_enter() call. Its a behavioral change, but because there's no real documentation for the library its unclear if the prior behavior is as-intended or not. |
Consider these transitions:
and then I am doing a:
I was expecting the loop of the 3000ms to stop, but it keeps calling the entry function of state_waitfortriggerack. The fsm.trigger(TIMEOUT) is actually changing the state and doing its thing, but the timed transition keeps repeating.
The text was updated successfully, but these errors were encountered: