Is a State Machine the best architecture for Labview code?

[ModusPwnens]

Hi all, 

I made a post here the other day and I learned a lot about State Machines architectures and how beneficial they are. My question now is if they are essentially the end all be all to labview architectures or if there are other design patterns one would want to consider. If so, what are they? 

[johnsold]

It really depends on the nature of the requirements for the program.

Have you heard the saying: "When the only tool you have is a hammer, all your problems look like nails." ?

While the state machine is used a lot, other things like Producer/Consumer are also important.  Most of the programs I write which contain state machines also have portions which are not in the state machine.  Some programs have multiple, independent state machines performing independent tasks.

Lynn

[ModusPwnens]

I see..so what are the different design patterns and when would you want to use them? 

[NIquist]

http://zone.ni.com/devzone/cda/tut/p/id/5237

[altenbach]

"State Machine" has become a bit of a buzzword, but is not a very well defined term. There are many architectures that incorporate some elements. Remember, LabVIEW is inherently parallel, so it is easy to design a program where multiple states are concurrently active and a classic state machine won't do. In summary, it is often good to incorporate some elements of state machine architecture, at least in the toplevel VI. Even the simplest VI has two states: running, not running. 😄

[JackDunaway]

---

johnsold wrote: 

Have you heard the saying: "When the only tool you have is a hammer, all your problems look like nails." ?

---

Have you ever heard the Three Fundamental Man-Rules About Tools?

1. Always use the right tool for the job
2. The hammer is always the right tool
3. Anything may be used as a hammer

It's easy see the fallacy in these rules. Now, use it as an analogy to design patterns, and replace "hammer" with any design pattern of your choice. The same fallacy applies.

[GregFreeman]

Two main reasons I have decided this architecture is mentioned so often for LabVIEW.

1. NI pushes it. It's what they teach, therefore, it's what people learn

2. it lends itself very nicely to the dataflow paradigm. It makes it very easy to follow order of execution which therefore makes debugging easy, all while organizing your code into related events (when done correctly)

That said, is it always right? No. Does the fact that it's not always right make it wrong? No. Pretty much what has been said above, it has it's uses. When using it in the right way, as when you use anything the right way, it makes sense.

[waldemar.hersacher]

Beside the Design Patterns NI teaches there are other design patterns often used.

There is a good book about them from the gang of 4.

Although the code examples are in C++ you can implement them in LV. One of my favourites is the observer pattern.

[Darin.K]

I am tempted to say that the Queued State Machine (QSM) is the greatest thing ever invented in LV, just to "tease the lions" as they say.  Instead I'll just point out this fun discussion a while ago.

http://forums.ni.com/t5/LabVIEW/State-Machines-are-great-thank-you-all/td-p/1067135