States not transitioning properly

[pixelview95]

I am trying to transition cyclically between 3 states. But after the first transition it just stops. I'm not sure if it's my programming or something with the library. Can't seem to find similar examples. Any help would be appreciated. Thanks. `#include

define ARMED_RFID_TRIG 1

define RFID_BLUE_TRIG 1

define BLUE_ARMED_TRIG 1

void on_armed_on_enter(); void rfid_on_enter(); void blue_on_enter();

State state_armed(&on_armed_on_enter, NULL, NULL);//armed state, default State state_rfid_scan(&rfid_on_enter,NULL, NULL); State state_blue_scan(&blue_on_enter,NULL, NULL); Fsm fsm(&state_armed);

void on_armed_on_enter() { Serial.println("entering armed"); fsm.trigger(ARMED_RFID_TRIG);//trigger transition from armed to rfid delay(1000); } void rfid_on_enter() { Serial.println("entering rfid scan state"); delay(1000); fsm.trigger(RFID_BLUE_TRIG); } void blue_on_enter() { Serial.println("entering bluetooth scan state"); fsm.trigger(BLUE_ARMED_TRIG);//trigger transition from rfid to blue delay(1000); } void setup() { Serial.begin(9600); Serial.println(">> starting setup>"); //STATE TRANSITIONS fsm.add_transition(&state_armed, &state_rfid_scan, ARMED_RFID_TRIG, NULL);//state from->state to->if event trigg fsm.add_transition(&state_rfid_scan, &state_blue_scan, RFID_BLUE_TRIG, NULL); fsm.add_transition(&state_blue_scan, &state_armed, BLUE_ARMED_TRIG, NULL); }

void loop() { fsm.run_machine(); delay(100);

}`

[dotorg]

I ran into this with timed transitions, too. You can't transition with the library as-is between states during the "start"/"enter" method call because the current state being tracked in the library isn't changed until after the start method returns. So in your example when you call the BLUE_ARMED_TRIG trigger in blue_on_enter, the current state is state_rfid_scan not state_blue_scan. You can either adjust your triggers, or fix the library. I fixed the library, here.

In make_transition, just move the m_current_state assignment to run before on_enter().

[altereg0]

define ARMED_RFID_TRIG 1

define RFID_BLUE_TRIG 1

define BLUE_ARMED_TRIG 1

Your triggers should be different. States table of FSM react on "int" values, not "names". Timed transitions work fine.

`#include

define ARMED_RFID_TRIG 1

define RFID_BLUE_TRIG 2

define BLUE_ARMED_TRIG 3

void on_armed_on_enter(); void rfid_on_enter(); void blue_on_enter();

State state_armed(&on_armed_on_enter, NULL, NULL);//armed state, default State state_rfid_scan(&rfid_on_enter, NULL, NULL); State state_blue_scan(&blue_on_enter, NULL, NULL); Fsm fsm(&state_armed);

void on_armed_on_enter() { Serial.println("entering armed"); } void rfid_on_enter() { Serial.println("entering rfid scan state"); } void blue_on_enter() { Serial.println("entering bluetooth scan state"); } void setup() { Serial.begin(57600); Serial.println(">> starting setup>"); //STATE TRANSITIONS fsm.add_timed_transition(&state_armed, &state_rfid_scan, 1000, NULL);//state from->state to->if event trigg fsm.add_timed_transition(&state_rfid_scan, &state_blue_scan, 1000, NULL); fsm.add_timed_transition(&state_blue_scan, &state_armed, 1000, NULL); }

void loop() { fsm.run_machine(); }`

[dotorg]

Two comments:

• First, the #define the OP posted is defining an integer, which is picked up as the compiler as the appropriate type. If it wasn't, it wouldn't compile. That's how a #define works.
• Second, your suggestion is not functionally equivalent to what the original code did. The original code was scheduling a transition to happen a second after the completion of the prior state transition. Your code is scheduling them to happen every 1000ms from the time they were originally scheduled. In a trivial example they may seem behaviorally close enough, but they're not if you're actually doing anything non-trivial at the entry to a state.

The issue, as I said, is that the state transition doesn't happen until the completion of the start method for the state. IMO, that's a bug, but its more of a philosophical bug. The original author may have intended the behavior that way. The code that was originally posted is fine if the library is changed to transition state when the start method is called, rather than after. Given I ran into that issue, and there are multiple issues reported in the repo because of other people making the same assumption, its clear either the library should be changed or the docs need to call out when the state transition is being recorded.

[altereg0]

You are right. I misunderstood.