I am trying to learn to design state machines. This is the nth rewrite of my mixing station software. I think that this will work, but I am not sure if I am following the intent of the state machine and using it correctly or not or what that really is supposed to be. In my last one I was just returning out of every state and calling the function repeatedly in loop, and that probably wasn't the best, but I am not sure what "good" design is here? This chunk is the main loop and it shows how things are iterated within it, in the case of iterating the members of a "Formula" struct. Just trying to learn to have do more a better. This has NOT been tested on hardware, it is only a concept at the moment. unsigned long DELAY_START; int DELAY_FOR; void Delay(int dur) { STATE = DELAY; DELAY_START = millis(); DELAY_FOR = dur; } states NEXT_STATE; int currentDelay; int currentRest; Pump currentPump; int mixingIndex = 0; void loop() { switch (STATE) { case MIX: currentPump = CurrentFormula.pumps[mixingIndex]; currentDelay = CurrentFormula.mix_times[mixingIndex]; currentRest = CurrentFormula.rest_times[mixingIndex]; mixingIndex++; if (mixingIndex < 7) { STATE = IDLE; } else { STATE = DOSE_START; } case DOSE_START: digitalWrite(currentPump.pin, HIGH); NEXT_STATE = DOSE_END; Delay(currentDelay); case DOSE_END: digitalWrite(currentPump.pin, LOW); STATE = REST; case REST: NEXT_STATE = MIX; Delay(currentRest); case DELAY: // use Delay(duration) if (millis() - DELAY_START < DELAY_FOR) { return; } else { STATE = NEXT_STATE; } case IDLE: // waiting for a button to change the state return; } }

This is very simple and I'm surprised I didn't stumble upon this in my efforts. Very simple and easy to ready and edit... at least in pseudocode... I almost definitely will use this when I get to RTC timing.

[image] underhilll: it is essentially the same It is not the same at all. The return does what it says, ie returns immediately to where the function being executed was called from, and it does it unconditionally. It does not [image] underhilll: just fall past all other states Using break, however, ends the code block currently being executed and continues to execute the code in the function currently being executed. This can include code that is executed unconditionally Of course, under some circumstances the result is the same, but I think it is wise to use the appropriate command

[image] Delta_G: We break that rule all the time, I'm a relentless out-denter and use return when it can mean the real work of a function is after, and thus can live one tab stop further to the left. From someone's earlier post here: if (dwell && (millis() - lastFMSTime < dwell)) return; // DELAY in state First thing the function does, decide whether it's time to run. a7

[image] Delta_G: We break that rule all the time Who's "we"? One entry, one exit. Return values only when necessary, default return value set at initialization, modify return value when necessary. [image] alto777: First thing the function does, decide whether it's time to run. That decision belongs to the caller, not the callee. It's mostly a style thing, but it does also save the time the call process takes. Calling a function, then deciding we shouldn't be there, was anathema 'back in the day'. That largess would have gotten me a verbal dressing down from my best college instructor, for sure - and likely a -10% for sloppy coding, if done in an assignment. But, my code experience is relatively limited, and training quite dated. Given multi-GHz CPUs, I understand emphasis may shift, but, the Arduino Classic Nano is pretty much the same as what I learned assembly on (it's actually way better than a 6802/6502, and I didn't have to wire wrap it!). Wasting the call cycle is not, IMHO, good coding. YMMV. (crawls into foxhole, pulls hole in on top of himself)

[quote="camsysca, post:85, topic:1198836"] That decision belongs to the caller [/quote Maybe, maybe not in this particular case. Some FSMs are designed to be called very frequently and many times do nothing. Maybe the caller should have known that and just not called? But any function might make execution of most of the code contingent upon a series of tests. If it is this, if it is that if the other thing is OK then… do it. You are three levels in over some simple tests. If it is not this, return. If it is not that, return. If the other thing is not OK, return Then do it. [Why You Shouldn't Nest Your Code] a7

It was raining yesterday afternoon so I posted this [image] Yet another Finite State Machine introduction Introductory Tutorials Hello everyone, On this gray day, considering the number of questions that boil down to programming a finite automaton (or a state machine), I thought I would translate my small tutorial I also have in French to explain how to approach this type of code in a structured manner. Of course, there are libraries that do this more or less for you, but understanding how it works can often allow you to do without libraries that might weigh down your code. The general idea is to write a program that co… Hopefully it will be a helpful introduction to some - I tried to keep it at beginner’s level.

The tuorial is good. I'd consider adding a link to the Toggle.h library in the code like: #include // https://github.com/Dlloydev/Toggle and maybe Toggle::onPress() because this state machine design depends on the one-shot edge-detection events of the button presses to make the transitions out of the states. In the code for this: So a better code would be to first test for the clicks and then if the state is not REST, test for timeout // TEST FOR TIMEOUT if (millis() - chrono >= TimeOut) { // timeout event turnLedsOff(); currentState = REST; } ...you do not test for the non-REST state, (and it isn't a problem if you don't) but it might be better to explicitly add the transition loop from REST->REST since this transition code reinitializes into into REST state each time. I like the choice of focusing on the events that transition between states, particularly the beginnings of the arrows in the state diagram. Some explanations gloss over where the transitions happen, and the code derived from them can end up with races or they end up looking like they depend on COMEFROM. With your transitions coded as the beginnings of the arrows in the State Transition Diagram, there's an clear place for the one-shot initialization code. If there is a lot of repetition, or the initializations are complex, one could code up a transitionToXXXX() function and call it instead of coding the initializations of stateX in the end of the other states.

[image] DaveX: I'd consider adding a link to the Toggle.h library in the code I don't agree. It is all too easy to start writing a tutorial on a particular subject only to use something that itself needs explanation. This soon escalates and you find yourself way off the original subject There is an example of this in the @J-M-L tutorial where he suggests using an enum for the state names and has to divert to a long explanation of what they are before getting back to the core subject of the tutorial You, I and @J-M-L know the advantages of using an enum but you can do without them by using variables. On the other hand, suggesting the use of switch/case seems more sensible and can be explained in a single paragraph and bring much needed structure to state machines As usual, YMMV

I like tutorials that give you what you need without having to divert to e.g. enums. With this, you can get going and never come back if it suits you What's nicer is another section or two following that cover "We covered the minimum, but you can improve/evolve your solution using this other thing"

I like tutorials that give you what you need without having to divert to e.g. enums. With this, you can get going and never come back if it suits you In the case of the use of enum, and for that matter the use of switch(), both could be elegantly explained within the original post by the use of footnoting. *, or *1, followed by a detailed explanation at the end of the note, would keep the tutorial flowing while providing the novice user with the required explanation, along with a contextually appropriate example. I find tutorials that reference you to the original C or C++ reference material aren't really a help, because the authoritative material doesn't usually have context that's relevant to the tutorial, just leaving the beginner/novice more confused.

State machine design?

Projects Programming

J-M-L December 11, 2023, 9:02am 87

It was raining yesterday afternoon so I posted this

Hopefully it will be a helpful introduction to some - I tried to keep it at beginner’s level.

Topic		Replies	Views
Need help writing a state machine Programming	94	1465	May 5, 2026
When to read sensors whilst running a state machine? Programming	64	1024	November 7, 2025
Getting back to Arduino General Discussion	197	2737	October 13, 2025
State-machine and timing - Newbee, I would like to read your opinion Programming	100	6456	September 16, 2021
Looking for some state machine design advice Programming	63	1306	September 7, 2025

State machine design?

Related topics