From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-23-2010 11:55 AM
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?
07-23-2010 12:09 PM
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
07-23-2010 12:13 PM
I see..so what are the different design patterns and when would you want to use them?
07-23-2010 12:14 PM
http://zone.ni.com/devzone/cda/tut/p/id/5237
07-23-2010 12:16 PM
07-23-2010 12:27 PM
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?
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.
07-23-2010 12:32 PM - edited 07-23-2010 12:33 PM
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.
07-23-2010 01:19 PM
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.
07-23-2010 01:27 PM
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