What is a state machine?

[johntrich1971]

A post in this thread has prompted me to ask the question to make sure that I'm not off my rocker. The poster is a new poster but claims to have an accreditation (it's hinted that it's CLD, but never specifically said), to have been coding in LabVIEW since 1999, and to have "taught LabVIEW at intel for ten years." The post included a sample program that may be worthy of the Rube-Goldberg thread that he claims is a state machine. My understanding of a state machine is that each iteration of the loop goes to exactly one distinct state, and that there is not another while loop inside a state (or multiple states). The OP seems to think that this is a normal state machine. Am I totally wrong in my thinking that this is not a state machine? 

[thols]

According to Wikipedia "An FSM is defined by a list of its states, its initial state, and the inputs that trigger each transition". An FSM (finite state machine) is what we usually mean when we say state machine. I would say that it looks like that code of "state machine with multiple event structures.vi" fulfills the definition, but I may be wrong.

The while loops surrounding the event structures are only used in the timeout case and doesn't affect the state transition. 

But, does it really matter what we call it and who is correct about it? I understand from how the conversation went that you want to be "right", but I don't think that will help the OP. The OP is already satisfied with the answers he got and his code is working, even if he is not following best practices.

[johntrich1971]

Thanks for the reply, thols. This post isn't really about being right. It's really about tying to find out if I'm wrong. I'm willing to accept if I'm wrong - but only  when it comes from people that I trust. That's why I posted here where many long-time forum members that I trust will hopefully see it and chime in. 

[drjdpowell]

Unfortunately, the LabVIEW community used "State Machine" for things that aren't actually State Machines.  The JKI "State Machine" Template, for example, is not a State Machine; more correct terminology would be Queued Message (or Event) Handler.  And the common naming of cases in a Case Structure as "states" is also wrong, as they are usually actions that the "Machine" performs, rather than being states that the machine is in.

So the OP in that other conversation is trying to make a real State Machine, and is/was having difficulty with setting up the Events (Events in LabVIEW are an API that tried too hard to be simple, and ended up obscuring important details to Users and resulting in an API that is hard to understand).

[wiebe@CARYA]

Since I started using OO, I haven't made a single state machine. I never really liked them anyway.

I prefer to use a state pattern, if I really need such functionality. Even more now we have interfaces.

[johntrich1971]

---

wiebe@CARYA wrote:

Since I started using OO, I haven't made a single state machine. I never really liked them anyway.

I prefer to use a state pattern, if I really need such functionality. Even more now we have interfaces.

---

I'm still learning OO, but I don't think that I've made a state machine in a long time. They're great for small applications but quickly become unwieldy as the application grows.

[crossrulz]

---

@johntrich1971 wrote:

---

wiebe@CARYA wrote:

Since I started using OO, I haven't made a single state machine. I never really liked them anyway.

I prefer to use a state pattern, if I really need such functionality. Even more now we have interfaces.

---

I'm still learning OO, but I don't think that I've made a state machine in a long time. They're great for small applications but quickly become unwieldy as the application grows.

---

The only form of an actual state machine I have used since my CLD exam is a sequencer.  There can be arguments that some of my Queued Message Handlers are another form of a state machine.  Possibly a better argument with my Remote Terminal library, which has more state data than probably any of my other VIs I have ever made.

[drjdpowell]

State Machines, as they have both multiple states and respond to multiple triggers (events/messages) can be built in two ways.  

• given a state, handle trigger(s)
• given an trigger, handle it based on the current state

The first one is what the OP of the linked conversation was doing, with a State case structure and an Event Handler in each case.  But if one starts with a Queued Message Handler, it is more natural to develop it into the second one, where one has multiple case structures selecting different trigger-handling based on state.

[wiebe@CARYA]

---

@crossrulz wrote:

---

@johntrich1971 wrote:

---

wiebe@CARYA wrote:

Since I started using OO, I haven't made a single state machine. I never really liked them anyway.

I prefer to use a state pattern, if I really need such functionality. Even more now we have interfaces.

---

I'm still learning OO, but I don't think that I've made a state machine in a long time. They're great for small applications but quickly become unwieldy as the application grows.

---

The only form of an actual state machine I have used since my CLD exam is a sequencer.  There can be arguments that some of my Queued Message Handlers are another form of a state machine.  Possibly a better argument with my Remote Terminal library, which has more state data than probably any of my other VIs I have ever made.

---

For a long time (probably still), a state machine (or at least a typed def'd state enum) was a requirement for CLD, and failing to have one would result in instant disqualification.

I didn't dare to challenge the examiner at my CLD. After all with a state pattern the state class is a type def representing 'state'. I'm not sure a VI analyzer or other automated test would agree.

[crossrulz]

---

wiebe@CARYA wrote:

For a long time (probably still), a state machine (or at least a typed def'd state enum) was a requirement for CLD, and failing to have one would result in instant disqualification.

I didn't dare to challenge the examiner at my CLD. After all with a state pattern the state class is a type def representing 'state'. I'm not sure a VI analyzer or other automated test would agree.

---

It's been at least 10 years since I took the CLD, and even then the State Machine architecture was not a requirement.  But all of the test scenarios were certainly geared towards the State Machine.  I think AristosQueue used Actor Framework to pass his CLD (not going to swear to that).