Jump to content

Labview Programming Structures


Recommended Posts

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.

Link to comment

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)

Link to comment

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

  • Like 1
Link to comment

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.

Link to comment

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.

Link to comment

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

Link to comment

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

Link to comment
  • 1 month later...

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 by tushar
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.