State Machines are great...thank you all

[Hummer1]

Thank you!!!!!

For the past several months I have struggled to learn how to use LabView, at all...much less effectively.  With the help of the forum I finally was able to cobble together a display manager for our lab.  It was slow, unresponsive and completely event driven, and totally unmaintainable.  With the help of several key forum members (and I'm sure the good wishes of the rest)  I learned about state machines, queues and other good habits. 

In less than 2 days, I have rewritten the project in state machine form and it works beautifully.  It uses a typedef enum for state definitions and a sub.vi for variable initialization.  The BD is readable, simple and can be seen on one screen (nearly...have to scroll down a bit to see all of the error function.)

I can't thank all of you enough.

Hummer 1

[Mark_Yedinak]

Glad to hear that things went well for you.

[Darin.K]

Now young Grasshopper it is time to take it to the next level.  With LV scripting you can write a state machine to write your state machine for you. 

I need coffee now, still waiting for a state machine to do that.  Wait, I, err my daughter, got a Mindstorm for Christmas, could their power be unleashed in the physical world?

[Hummer1]

Oh thank you master, but I see the coin is still in your hand.

Hummer1

[NIquist]

A Coin!  Sheesh, back in my day all I got was a pebble.

Congrats on your success! 

[Taylor.Kendall]

We have used State Machines for years and they are great.  But the thing thats even better is a state machine with a queue in front.  You can execute the same state multiple times if need be and you can use different states in different orders depending on what is needed. 

Give it a shot for your next project. 

[PaulG.]

---

tsksesa wrote:

We have used State Machines for years and they are great.  But the thing thats even better is a state machine with a queue in front.  You can execute the same state multiple times if need be and you can use different states in different orders depending on what is needed. 

Give it a shot for your next project. 

---

A queue-driven state machine is my favorite architecture. And I use a typedef enum as the data type for the states. You can mix and match states and it's so easy to maintain and read.

[Mark_Yedinak]

---

PaulG. wrote:

---

tsksesa wrote:

We have used State Machines for years and they are great.  But the thing thats even better is a state machine with a queue in front.  You can execute the same state multiple times if need be and you can use different states in different orders depending on what is needed. 

Give it a shot for your next project. 

---

A queue-driven state machine is my favorite architecture. And I use a typedef enum as the data type for the states. You can mix and match states and it's so easy to maintain and read.

---

I also use the queued state machine extensively. Recently Ihave switched to using a cluster for the state rather than a simple typdefed ENUM. My cluster consists of the typedefed ENUM and a variant. This provides a mechanism for easily passing data between states and since it is a variant one the poster and the specific state need to know the data type. New states can be added without worrying about updating typedefs for the state data that may be required.

[DianeS]

A queued state machine is your friend

It's not just a fad or a trend

A typedef'd enum

Leaves plenty of room

For changes you won't have to mend!

I also like type-defined clusters

A variant gives it some lustre

You can pass anything

Array, number, or string

And your next state will always pass muster!

d

[NIquist]

NIce!