Labview Programming Structures

[murray]

I'm curious. It seems to me that the only viable method of programming a medium to large application in Labview is using the Qued State Model Architecture. This is of course, leaving an object oriented approach aside completely. The labview programs I have been involved with have been either entirely user event driven or had a substantial portion of the program based on user events, so the QSM seems to fit well there so far.

The only alternative to QSM I have seen involved large amounts of code within an event structure and a truck load of local variables, which I can't imagine would go down well with others on the board.

From perusing the forum I believe there is third party software and different structuring approaches which attempt to improve on the basic QSM concept as suggested by NI themselves, but ultimately the basic architecture alwasy comes back to some type of state machine.

I am not so unhappy with the QSM approach that I want to throw it out the window, my reason for asking this question is to find other legitimate and sensible approaches to programming labview. To add more depth to my approaches in creating a program.

So is there a non QSM architecture out there that works well? If so what approach have you taken and why did you avoid the QSM.

[SuperS_5]

Hi,

Although I have only have a few years of experience with LabVIEW, I have always used the string based state machine with a event structure. (Very similar to the JKI state-machine approach) I don't have any issue with the Enum and Queued versions of the state-machine, I prefer the string version. (I found it to have more advantages then disadvantages.) Of course this is only the UI side of the application. The UI thread is only a portion of the overall architecture. Anything that needs to run without interruption (like DAQ) will have their own structures. (Usually some form of simple state machine)

[Black Pearl]

My own approach for larger projects is documented here on the dark side.

A very diffrent design pattern class, which is pretty useful on larger app's is dynamical calls via VI server. Currently I'm using (studying) this for recursion, but more commonly you'd see this implemented as 'plugins' and for 'lazy loading'. Going OOP, that'd be the factory design pattern.

Felix

[PaulG.]

My own approach for larger projects is documented here on the dark side.

A very diffrent design pattern class, which is pretty useful on larger app's is dynamical calls via VI server. Currently I'm using (studying) this for recursion, but more commonly you'd see this implemented as 'plugins' and for 'lazy loading'. Going OOP, that'd be the factory design pattern.

Felix

My current app is looking a lot like this. I like the enum state machines as well. I only use the text-based state machine if I need something simple, fast and dirty.

[crelf]

When we want to put together a QSM, we use an internal reuse package that uses a string-based queue. Having it in a reuse package allows us to include other features, like state transition logging. It's currently passing around a dqGOOP reference, so we can use it in producer/consumer architectures, although I guess we could update that to a DVR-wrapped LVOOP class someday, but we haven't seen the need to.

[Grampa_of_Oliva_n_Eden]

I'm curious. It seems to me that the only viable method of programming a medium to large application in Labview is using the Qued State Model Architecture. This is of course, leaving an object oriented approach aside completely. The labview programs I have been involved with have been either entirely user event driven or had a substantial portion of the program based on user events, so the QSM seems to fit well there so far.

The only alternative to QSM I have seen involved large amounts of code within an event structure and a truck load of local variables, which I can't imagine would go down well with others on the board.

From perusing the forum I believe there is third party software and different structuring approaches which attempt to improve on the basic QSM concept as suggested by NI themselves, but ultimately the basic architecture alwasy comes back to some type of state machine.

I am not so unhappy with the QSM approach that I want to throw it out the window, my reason for asking this question is to find other legitimate and sensible approaches to programming labview. To add more depth to my approaches in creating a program.

So is there a non QSM architecture out there that works well? If so what approach have you taken and why did you avoid the QSM.

There better be more the the QSM or else I would not have anything to start with.

THis presentation on the NI site (the dark-side) can show others.

http://forums.ni.com/t5/LabVIEW/Receiving-Multichannel-data-serially-on-Labview/m-p/1400384#M545892

App architectures are a lot like knitting. If you only know one stich then everything looks the same, but irf you understand the nature of the various stitches (functions e.g. Queues Events,...) you can whip up your own pattern with the right combination.

The are many other examples on the NI web-site. Search for Design pattern.

Ben

[Tim_S]

So is there a non QSM architecture out there that works well? If so what approach have you taken and why did you avoid the QSM.

Medium to large applications are going to have multiple pieces, each of which can be a small application (e.g., UI, security, PLC communication, DAQ). Each one, depending on the requirements, can use a different model. For example, I really like the JKI state machine for UI, but wouldn't think of using it for DAQ or communication where a producer/consumer model could be better.

Tim

[Daklu]

I had almost finished composing a message last night when I accidentally hit the "Back" button on my keyboard. Ah, the joys of browser-based text editors.

Note that "QSM" means different things to everyone. I don't use what *I* consider the QSM, but I do use queued message handlers. QMHs look a lot like QSMs, but the difference is in how they're used and what's expected of it. In this post I'm primarily referring to a dual loop "producer-consumer QSM"

I'm curious. It seems to me that the only viable method of programming a medium to large application in Labview is using the Qued State [Machine] Architecture.

Absolutely not true. The QSM is the most common implementation seen because that's all most people know. And truthfully, it probably is sufficient for most Labview users. There are lots of architectures and patterns available. Though Labview is different from common text-based languages, it's still software. The patterns and architectures that apply to those languages can apply to Labview as well.

As an aside (and I'm probably in the minority) I don't think the QSM qualifies as an "architecture," though people often refer to it as such. The QSM is an implementation, not an architecture. Calling it an architecture is kind of like saying my house is built using a screwed butt joint architecture. A "screwed butt joint" (and the QSM) is a construction technique, not an architectural description. So when someone says their app uses a "QSM architecture," I read that as, "My app has no architecture." Usually I'm not far off.

ultimately the basic architecture alwasy comes back to some type of state machine.

There's nothing inherently wrong with state machines. When used appropriately they are very useful. Queued State Machines, however, aren't state machines at all. They're a convenient construct for sequencing code segments.

So is there a non QSM architecture out there that works well?

Your question implies you're looking for a single, general purpose design that works across all requirements. So no, there is not *a* architecture that works well. Like Ben said, there are lots of architectures and design patterns, each with their own strengths and weaknesses. The software engineer's job is to pick those that meet the requirements. Pick one that's too complex and you have to implement a lot of useless code. Pick one that's too simple and you have to resort to hacks to support functionality the architecture isn't well suited to provide. My apps are composed of several different architectures/patterns, depending on what level of the code you're looking at.

If so what approach have you taken...

Event based, Model View Controller, object state machines, active objects, etc. Lately I've been moving towards highly decoupled components that use messages to send and receive information with a mediator handling all message routing and translation between the various application components.

...and why did you avoid the QSM.

1. I got tired of the messes that resulted from using QSMs.

2. They are fragile. Many implementations have inherent flaws that can't be fixed.

3. They are hard to follow. QSMs are a lot like GOTO statements in text languages.

4. They don't provide any structure. Good architectures are designed with clear extension points for adding functionality.

5. There's often no easy upgrade path to something more suitable when the requirements outgrow the QSM's abilities.

[SuperS_5]

Kudos Daklu. You took the words right out of my mouth, then added several times over. I am actually inspired to look for more architectures and styles. After all I want to go for the CLA test sometime after I take my CLD test coming up.

[Grampa_of_Oliva_n_Eden]

I had almost finished composing a message last night when I accidentally hit the "Back" button on my keyboard. Ah, the joys of browser-based text editors.

...

Mega-Kudos!

Ben

[tushar]

when i talk about design patterns(so called architectures) almost every time people start talking about state machines. and i wonder that most people dont accept that state machine can introduce some problems as well.

one of the problem of state machine is that it makes everything sequential, so if you are using LabVIEW because it is "Inherently parrallel" then your state machine is turning it into "inherently sequential" (However if you dont follow good design patttern then the problems are even bigger)

we have developed our own framework for implementing publisher subscriber pattern. this is useful for large applications especially where layered architecture is used. we divide our application into layers and develop them as separately. then these layers communicate with each other through our framework.

Due to loose coupling in layers we get unmatched flexibility and extending application is very simple. all the layer follows a modified QSM for the execution.

here is a small demo of our pattern

Also find attached code of our framework. the example demonstrated in video is also available inside zip file

Also find attached code of our framework. the example demonstrated in video is also available inside zip file

PubSub Architecture.zip

Edited February 11, 2011 by tushar