FSM diagrams: states and transistions

Projects Programming
1

I saw a link to the FSM tutorial in the playground and I don't agree with the FSM diagram for the example. I'm no expert but I'm pretty sure that two of the "states" are actually "transistions".

The first attachment below is a screen shot from the tutorial. Seems to me, that FadeIn and FadeOut are transitions: they are ways of getting from Off to On and back to Off. To my thinking the boxes are states; the arrows are the transitions.

The second attachment is my take on this, with the event causing the transition, and the transistion, attached to the arrow between two states (event/transiition), along the lines described here. So there are 4 events (Buttons ABCD) and 4 transistions (FullOn, FadeOn, FullOff, FadeOff) giving 4 arrows between the 2 states of Off and On.

I'm sure there are different conventions in FSM modeling, and it's not out of the question that a transition could be seen as a state- a Transition State- but I'd be keen to hear others' views.

Jim

LED FSM from tutorial.PNG

LED FSM from tutorial MarkII.PNG.jpg

2

That whole example seems confused - certainly the diagram is wrong as
the correct sequence is off - fadeIn - on - fadeOut - off
The fade states are exited upon completion (time-related).

The usual way you would program a state like this is to trigger an event regularly,
which progresses the fade (incrementing a variable and updating PWM), and eventually
when the fade is complete then causes a transition. A variable is used to represent the
sub-state during the fade.

3

I don't think there's a "correct" sequence: it's button controlled, so you can elect to go from Off to On via FullOn or FadeOn at whim.

Here's the table:

Current        Event        Transition     New
====================================================
Off             ButtonB      FullOn         On
Off             ButtonD     FadeOn         On
On              ButtonA     FullOff         Off
On              ButtonC     FadeOff         On

Or pseudo code:

Initialise On as true
Read the buttons A-D, set as true if active (assume for now, only one is pressed)

If (Off and ButtonB), do FullOn, set On true
If (Off and ButtonD), do FadeOn, set On true
If(On and ButtonA), do FullOff, set On false
If(On and ButtonC), do FadeOff, set On false.

My main issue in the example is having transitions as states, and the arrows mean nothing. Makes more sense to me, to have states as identifiable end conditions and have the arrows as the transitions.

4

I see no problem with "FadeIn" and "FadeOut" being states. If the diagram was labelled with "button pressed" on all transitions and shows the initial state, it would be much less confusing.

SEQUENCE DESCRIPTION (example)

• Startup - Led is Off
• Button is pressed
• Led fades in to 50% brightness in 1 second
• Button is pressed
• Led fades out to 25% brightness in 2 seconds
• Button is pressed
• Led is turned on (100%)
• Button is pressed
• go back to initial state

5

You can have any convention you like.

If you take the view that the boxes represent the "states", and the arrows represent the "transitions", then if you want to label what the actual action is that is taken to transfer from one state to the next, you have to have captions floating around the picture awkwardly next to the arrows, as the example in the preceding post shows.

On the other hand, if you have more of a "flowchart" mindset, it is the actions or steps of the process which go inside the boxes. You can use different shapes of box to indicate actions, final or intermediate endpoints ( "states" ), and also different boxes for branches.

6

Thanks for the comments.

I guess I was taking a UML State Diagram view, where the arrow is the transition and may be labeled with the causing event, as in the RCMartin tutorial linked earlier. Visual Paradigm uses the same approach, as a UML tool.

It just sits nicely with me that the arrow represents a transition, but of course there are many ways to skin the proverbial cat.

7

JimboZA:
I saw a link to the FSM tutorial in the playground and I don't agree with the FSM diagram for the example. I'm no expert but I'm pretty sure that two of the "states" are actually "transistions".

The first attachment below is a screen shot from the tutorial. Seems to me, that FadeIn and FadeOut are transitions: they are ways of getting from Off to On and back to Off. To my thinking the boxes are states; the arrows are the transitions.

The second attachment is my take on this, with the event causing the transition, and the transistion, attached to the arrow between two states (event/transiition), along the lines described here. So there are 4 events (Buttons ABCD) and 4 transistions (FullOn, FadeOn, FullOff, FadeOff) giving 4 arrows between the 2 states of Off and On.

I'm sure there are different conventions in FSM modeling, and it's not out of the question that a transition could be seen as a state- a Transition State- but I'd be keen to hear others' views.

Jim

I would say that the fade phase is a(n unsteady?) state until the fade has completed. Only then do you transition to the next phase. But it's a matter of one's own interpretation of the word 'state'.

8

Henry_Best:
But it's a matter of one's own interpretation of the word 'state'.

Yep... or the interpretation of the convention one's following. In UML-speak it certainly seems the states are the steady parts (off, on; the boxes) and the transitions are the pathways between them (goOn, goOff; the arrows).

9

I use transitional states that are only "active" for one cycle. I usually prefix those with a tr_. They are kind of like a setup() function, only meant to be run once before the "main" state takes over and acts like loop(). For example, right now the project I'm working on has several menus to display on an LCD. Each menu has different settings associated with it, and reacts differently to the encoder turns and button presses. Therefore, I give each menu a different state, and control which menu is active by controlling the state. Each menu also has a tr_ state associated with it that initially displays the menu and in general sets it up ready for user input. For example, here's a snippet for the configuration menu:

    case tr_CONFIG:
    {
      init_menu( config_menu_str );
      print_config_zero_offset();
      print_config_backlight();
      print_config_contrast();
      system_state = CONFIG_MENU;
      break;
    }
    case CONFIG_MENU:
    {
      if( E1_turns != 0 )
      {
        configuration.backlight += E1_turns;
        configuration.backlight = constrain( configuration.backlight, 1, 8 );
        lcd_set_backlight( configuration.backlight );
        print_config_backlight();
      }
      if( E2_turns != 0 )
      {
        configuration.contrast += E2_turns;
        configuration.contrast = constrain( configuration.contrast, 1, 50 );
        lcd_set_contrast( configuration.contrast );
        print_config_contrast();
      }
      if( E3_turns != 0 )
      {
        configuration.dc_zero_offset += E3_turns;
        configuration.dc_zero_offset = constrain( configuration.dc_zero_offset, 0, 4095 );
        print_config_zero_offset();
      }
      if( onoff_long_press_flag )
      {
        update_EEPROM_config();
        system_state = tr_ANALOG;
      }
      break;
    }

tr_CONFIG prints the menu and immediately transitions to CONFIG_MENU. CONFIG_MENU is the one that reacts to user inputs and updates the screen only as needed. Whenever I need to change to a different menu, I change to the tr_ state for that menu.

This may or may not be how state machines are "meant" to work, but it is certainly a pattern that's helped me in more than one project with a user interface.

10

JimboZA:

Henry_Best:
But it's a matter of one's own interpretation of the word 'state'.

Yep... or the interpretation of the convention one's following. In UML-speak it certainly seems the states are the steady parts (off, on; the boxes) and the transitions are the pathways between them (goOn, goOff; the arrows).

I think it's how you approach it. My approach is "What state is the program in?" rather than "What state is the LED in?" I can say my program is in the state of fading the LED and, only when it has completed that, it will transition to the next state.
I tend to use switch-case in my sketches. I'd find it very difficult to use fade as a transition between states.
OTOH, the LED is transitioning during the fade. You pays your money and you takes your choice!

11

The good thing that's coming out of this discussion is that states are good stuff.....

12

JimboZA:
The good thing that's coming out of this discussion is that states are good stuff.....

I'd say they're vital for avoiding indecipherable spaghetti code.
If you've ever written assembly language, states come naturally, otherwise you'd tie yourself up in knots within less than 100 lines, especially if your assembler program would only accept 5 character labels, as mine did.

13

In a "pure" state machine, the "fade" part would consist of multiple states, with boring transitions.
(LED10% -> LED20% -> LED30% -> LED40% ... unconditional, timed. The process where a single state sits there and changes outputs is NOT "pure") (of course, this level of purity can be annoying to implement...)

14

westfw:
In a "pure" state machine, the "fade" part would consist of multiple states, with boring transitions.
(LED10% -> LED20% -> LED30% -> LED40% ... unconditional, timed. The process where a single state sits there and changes outputs is NOT "pure")

Agreed, but I termed it 'an unsteady state'.

(of course, this level of purity can be annoying to implement...)

This would lead to the banishment of the for loop and further leads back to assembly language programming... :fearful: