Glad it was helpful!

Now you can do both!!! 😁

Sorry, Gary get gets close to, but not quite there. Sure, if you have had a course in compiler design, you already know this - however, if you haven't had such a course then I suspect making the connection is rather difficult.

@@RobertBartlettBaron You have a point that it's not quite there, but to be fair (and pardon me if this is very apparent, but) if he'd be explaining compiler design, then the video would've been named "Compiler design". Not making the connection is fine. These are soft-skills that will come to the surface whenever people do decide to take a course in compiler design, and subsequently, they'll pick up on the intricacies much better. RIght now it's handily packaged in an entertaining video, and the knowledge will hang around until it's needed. (insert witty reference to interrupt handling) But yeah, that's exactly why I called it a headfake. Gary makes us learn skills that are potentially useful in more than one field.

@@devjock I realize he is not explaining compiler design (see the original post for context), but he also doesn't mention the relationships between regular expressions and finite state machines, nor does he mention common applications that they are used in.

Glad to hear that.

Tell me about it! 😊

@@GaryExplains Also check the Xstate JS/TypeScript lib, it's really nice and has a cool SM visualizer

Best of luck!

You're welcome!

I am glad you enjoyed it. Thanks for the feedback about future videos. One question, if I may, why were you surprised that I made a video about FSMs?

@@GaryExplains I was surprised because I've mostly seen videos about hardware stuff (which I also like) on your channel lately. Even though there has been programming videos before, of course. But it was a pleasant surprise :)

@@CedLePingouin Understood. Thanks. Yes programming videos are also part of my repertoire. I have videos on C, Rust, Python, linked lists, sorting, and more.

Sadly this video didn't get many views so I won't be doing another FSM video soon. 😢

@@GaryExplains I looked at the views after commenting, I figured that would be your answer. But if it makes you feel happy, this video helped me more than any other in this year.

@@GaryExplains Actually, what I really wanted is a series on practical yet very simple applications for each design pattern.

In Europe. It helps the driver know which way the traffic light will go next. If you see just amber then you know red is next.

Same for Canada, except Quebec of course, where amber is just a decoration. No need for red-amber, red-green, or pink etc.

MARK!

I published the C one already 👍

@@GaryExplains oh, I guess I missed the notification. I'll look for it! Thanks to UKposts's stupid recommendations, now I have too many channels with notifications enabled :(

I published the C FSM video already! 👍

A Google search for "Gary explains GitHub" should be sufficient. Here is the link github.com/garyexplains/examples/tree/master/FSM

Who is stopping you from doing that ?

It's already in C and its 1000x easier. Just use switch statements.

@@ChandrapalSd Nothing, but I would like to see how Gary goes about coding it. Maybe I'd learn a thing or two!

Ladder logic is used to implement state machines. Sometimes many simultaneous state machines. Ladder Logic also deals with analog signals pretty well, whereas most FSM you're going to see written in Python will be dealing with far less complex "real world" situations, since the beginner is not really ready to deal with hysteresis, feedback loops, and process control timing, where a difference of 0.0002 seconds (200 microseconds) might be the difference of diverting a bottle on a conveyer that failed visual inspection into a reject bin or kicking the bottle so hard that it smashes on the wall (or hits a factory worker if you're very unlucky). I have great respect for PLCs, Logix controllers, and other such devices, and for the people who program them well. I studied various forms of state machines in college, did some embedded programming and compiler development in various jobs after college, and over the years, most of my significant work involved extensive use of state machines. It was about 20 years after I graduated from college that I first started working with PLCs, but I picked it up pretty quickly. Still, it took me a while so that my code could compensate for cranky pneumatic actuators that changed performance significantly from when the bottle inspector was turned on to about 15 minutes of running once the rubber pressure hoses had stopped softening. The reason they're called "Finite" is because there are a countable number of defined states the state machine can be in. There are many kinds of FSMs, ranging from simple accepting automata which have a single "start" state and have terminal states, and really don't branch a lot, but there are much more complex FSM. Often, it is easier to create multiple linked state machines, each having its own independent state, but with synchronization points where they can affect one another. Deterministic Finite Autonoma (DFAs) are predictable and will always behave the same for a given set of inputs, but there are other kinds that, although the state transitions are well defined, the outcome for a given set of inputs can be different based on some external influence such as a random number generator. There are push-down autonoma that have a state stack (Turing machines), "Finite State Machines with Oracle" that depend on an external process to determine state changes, and so on. Regular Expressions are "Accepting Finite State Machines", and are good for parsing serial input data. My typical FSM for power sequencing of a circuit board defines each state in terms of the entry conditions, a list of actions to take on entry to the state (handled by an "enter state" procedure), a list of exit conditions each with the state that condition causes transition to, and an "evaluate" procedure that is called or event (timer, interrupt, etc.) handling, and in which the exit conditions are evaluated and the exit handling and transition to the next state is signaled when a matching condition is found. In C or Assembly, all states are represented as 'structs' that have function pointers for the "enter state" and "evaluate" entries (some also have a "reset" function pointer), and the FSM is driven by an outer "super-loop" that may run multiple parallel FSMs for different purposes (eg, asynchronous communication, watchdogs, key decode, A/D, etc.). What I do is often safety and time critical, and frankly, a "switch" statement isn't going to cut it. I always start out with a directed graph of the states, labeling all of the edges with the conditions under which the that edge is followed. A lot of analysis gets done on the graph before the first line of C code is written, though typically, the graph gets modified as the interactions between the FSM implementation and the hardware it runs in become better understood. After burning out a few $800.00+ FPGAs, you learn to be very careful about FSM design. Many real-world FSM are most easily documented as a set of macro-states which are each smaller FSM made of of "micro-states". In these cases, rather than having a lot of parallel FSM that interact, you can think of it as either a birds-eye-view of a single gigantic FSM or an FSM made of "black box" states that are much simpler than the top-level FSM in which they exist. I'd much rather do formal documentation for 16 FSM each with around 10 states than one FSM with 160 states.

That is a lot of information and I wxpect I know most of the things you are referring to by different descriptions. I am not comfortable with expressive abbreviations and those things which sound cute as well so I just use them as is. I do not prefer Ladder Logic if there is a choice. Seimens PLC, which I used often had a Logic Block Form and a sort of Assembler form They called them Control Flow System (CFS) and Statement List (STL) which were far more flexible and "Leaner". The last version I used almost twenty years ago, S7 could even be considered Object Type with a bit of imagination using local and global variables very nicely. I do not recall a State Machine type of function. I created Step Functions (the design is within their literature) with Set/Reset blocks formed into Sequence Steps with the time critical stuff going off in dedicated modules and in the background. I do not believe that you can get a meaningful timer of less than a tenth, maybe 0.05 with a PLC without very careful program layout because of the Scan Time Issue. The last time I added a scan time indicator into a program (using an S5-115 generation unit at the basic end of the range) where I was concerned about reaction time and wanted to check before I decided to use an expensive interupt type module it was about 15ms and I only need 30ms so I stayed with the cheaper solution. Processors are much faster nowadays up from 4.77MHz to lots of GHz now so I expect that PLC have speeded up too. My current knowledge of the subject remains the same as twenty years ago, not kept up-to-date. I will read your reply again more carefully. It was interesting.

Hmmm. I don't see how a switch statement helps. A dictionary is much more elegant.

@@GaryExplains It's much easier to do: switch(state) { case 0: (do something here) state=1; case 1: (do something else here) state=nth; case nth: ... default: printf("I'm done."); break; } Than to do all that python stuff. Enums make it much better. Python seriously needs switch statements. They just jump to a point in memory rather than check conditions.

@@chudchadanstud No, sorry, I don't agree. My Python code is just one line to know what handler to call to "do something". 1 line for 5 states and 1 line for 25 states, always 1 line. That case statement is hideous. Imagine if you had 50 states that would be a sprawling mess. Unreadable and unmaintainable.

@@chudchadanstud Also, the idea is to have a FSM that can be dynamically created, your switch statement is a hardcoded nightmare. Even in C you should be using a table of some kind.

@@GaryExplains Yes, you can work around it in many ways using, enums, abstract data structures, functions, pointers, OOP principals etc. It's also why I mentioned enums, with enums you don't have to use literals which will make tracking down things difficult just read the enum. An IDE can can track down every reference of an enum or auto complete. Order in the switchs statement matters less. It's also not a string so you'll notice typos before hitting compile.