state machine with event structures that share a control

[mcduff]

---

@jgvarner57 wrote:

I thank everyone for their help. This is a state machine, it is just a more complicated one.

---

You are making thing hard for yourself. When you have an event structure in a state machine you typically have an "Idle" state; that is, a state waiting for a user input/interaction. Did you look at the JKI State Machine?

NI has somewhere an example of a soda machine state machine. The machine is in an Idle state, then a user puts some money in, it is enough money -> allow user to get soda, not enough money -> go to Idle state and wait for more money.

[jgvarner57]

When I got my LV certification, we did the soda machine using an event structure, that's when I fell in love with them. So elegant! However, my main application today has sixteen clusters with ten controls in each of them that are all selectable and will trigger different events that will conform to which of the sixteen clusters was selected, the functions of these sixteen clusters with ten controls each are vastly different between the 'setup state' and the 'test state', and there are also floating charts that fall outside of the normal data flow structure (using VI server functionality) thus the need for this complexity.

[johntrich1971]

---

@jgvarner57 wrote:

I thank everyone for their help. This is a state machine, it is just a more complicated one. This is representing my larger application (which I can't share as it is proprietary) which has a 'setup state', a 'test state', and a 'quit state' where there is a lot of interaction on all three states, thus the need for multiple event structures. I have made a simple model of this that uses dynamic events that are shared in both state's event structures as well as static events that are unique to each state event structure and it works great. I have the 50ms timeouts because if I didn't the string would not get updated with the current state. I had to use "switched when pressed" mechanical action for the controls and handle them with property nodes, but the automatic handling of "latched when released" was not very elegant, and quite unpredictable, when it came to the states of the controls.

---

Once again, this is NOT a state machine. You really need to go back and understand the definition of a state machine. Your "state machine" can have multiple states simultaneously (loops within a loop). I suspect that in your real application you have not defined all of the states, thereby necessitating the nested loops. To write a proper state machine you need to understand your all of your states. If you would reformat to a proper state machine you will save yourself a lot of headaches. Mcduff has mentioned the JKI State Machine. While I've not used it myself I know of others who use it religiously. I write code that is likely significantly more complicated than your code and never have to do a state machine that doesn't have well defined states. 

[johntrich1971]

---

@jgvarner57 wrote:

When I got my LV certification, we did the soda machine using an event structure, that's when I fell in love with them. So elegant! However, my main application today has sixteen clusters with ten controls in each of them that are all selectable and will trigger different events that will conform to which of the sixteen clusters was selected, the functions of these sixteen clusters with ten controls each are vastly different between the 'setup state' and the 'test state', and there are also floating charts that fall outside of the normal data flow structure (using VI server functionality) thus the need for this complexity.

---

I also love the event structure - it's one of the best features that has been added to LabVIEW since I started using it back in the 90s. It sounds to me like you really do need to look at a better architecture, though. The JKI State Machine is a possibility. I also like to use a queued message handler, which works really well when I also have vi server functionality. A simple Producer/Consumer might also be appropriate. If you really want to move up you can check out Delacor Queued Message Handler and Actor Framework. 

[jgvarner57]

I write code that is likely significantly more complicated than your code and never have to do a state machine that doesn't have well defined states.

I've been doing this since LabVIEW RT was first released in 1999, while incorporating C++ with code interface nodes and now with dlls, using web servers and datasockets where I could control my lab in AZ from Singapore so I kind of doubt it. There is no need to be rude. I also taught LabVIEW at intel for ten years.

doesn't have well defined states.

Did you even look at my latest shared VI? The states are very clear.

[johntrich1971]

---

@jgvarner57 wrote:

I write code that is likely significantly more complicated than your code and never have to do a state machine that doesn't have well defined states.

I've been doing this since LabVIEW RT was first released in 1999, while incorporating C++ with code interface nodes and now with dlls, using web servers and datasockets where I could control my lab in AZ from Singapore so I kind of doubt it. There is no need to be rude. I also taught LabVIEW at intel for ten years.

---

I've been doing LabVIEW since well before LabVIEW RT was released. You're right, I don't know how complicated your code might be. The fact that you didn't know how the Event structure worked led me to believe that you were a novice - but perhaps you do a lot of programming in RT where an Event structure does not apply. In any event I apologize for coming off as rude, that was not my intent.

[jgvarner57]

The fact that you didn't know how the Event structure worked led me to believe that you were a novice

BTW, when you kept saying my state machine was NOT a state machine, I was questioning your skill level as well. It is clearly a basic state machine where each state also happens to have an event register for interactive control during that state. It is not that complicated. I am just really good at finding little idiosyncrasies with platforms where things seemed to act unpredictably and was wondering why the event structures were acting erratically when I had them sharing controls. If you look at my last VI submission you can see that what I stated is indeed possible.

[jgvarner57]

and there should be only one event structure in the VI.

This is absolutely untrue. I have thousands of application with many states with their own event structures that work fine. This was the first time I found a way to have multiple event structures share controls within a single state machine.

[johntrich1971]

---

@jgvarner57 wrote:

and there should be only one event structure in the VI.

This is absolutely untrue. I have thousands of application with many states with their own event structures that work fine. This was the first time I found a way to have multiple event structures share controls within a single state machine.

---

I was only repeating what NI said in the link that I sent previously, and what most experienced LabVIEW programmers have agreed is best practices. It is certainly possible to have multiple event structures, but rarely a need. I generally use a messaging approach, but there are plenty of ways to use a single queue in a state machine as well. Mcduff mentioned an Idle state, which is probably the most common method. Sometimes people call this state "wait for event" or some variation of that. The method that I showed previously will also work. 

[Mark_Yedinak]

---

@jgvarner57 wrote:

and there should be only one event structure in the VI.

This is absolutely untrue. I have thousands of application with many states with their own event structures that work fine. This was the first time I found a way to have multiple event structures share controls within a single state machine.

---

While you may have had some success with your "state machine", I would not recommend doing it the way you are doing it. Personally I prefer to use Norm's TLB template for implementing my state machines. I would not recommend using multiple nested loops with multiple event structures within it. Using your pattern would make it very difficult to share common functionality across different states. Without seeing the larger application it is difficult to determine how much code you are duplicating. It also appears that your UI processing is fairly tightly coupled to your business logic. It is always a good idea to separate the UI stuff from the code doing the real work. There are many ways this can be accomplished.