LabVIEW done right: Requesting advice for a large LabVIEW project

[AaronMcCollough]

Hello Everyone,

I have been coding LabVIEW for about 2 years now, off and on as my company requires it, and although my coding abilities and neatness have improved greatly since I first started I still end up with large, messy looking programs.

I have a great understanding of SubVIs and use them regularly and often. I am also familiar with the various code structures such as a producer/consumer or state machine. But I keep finding that too much of my main code is interdependent on common variables, indexes, and values that it seems impossible to simplify any of them into subVIs because I would need like 10+ inputs or a custom cluster for each one. This seems counter productive and time consuming.

I have searched far and wide for good programming technique for larger labview programs and I have only been able to find the most basic advice such as "Use subVIs" or "Use a state machine" and all the examples I can find are laughably simple.

I can reduce my program to 3 while loops. One captures Events and gives commands on a queue, another takes those queued items and performs actions, and the third performs data gathering, plotting, and saving once each second. This starts out good, but by the time I've incrementally added all the features my company requires, each loop is a huge interconnected mess of wires with no clear way to section them up into subVIs.

A solution would be to make everything either a global variable or FG but as a native C programmer I was always taught to avoid globals. And if I went the FG route I would need somewhere around 100+ different VIs just to handle them all. 

Is there something I'm missing? I want to know how you pass data between the various loops of your program. Do you use one big cluster? Globals? FGs? None of these options seem ideal to me but maybe I'm missing something obvious.

If anyone has any advice for me, it would be well appreciated. Better yet, if anyone has, or could point me to, an example program exhibiting an ideal programming structure for a project similar to the one I mentioned above, I would love to take some time to look it over. Hopefully I'll be able to pick up some good tips and tricks for keeping my main VI to one screen size, and effectively passing all the required data to all the subVIs that require it.

Thanks in advance,

-Aaron

[Synaesthete]

A lot of your problems might be solved if you approach your application in an Object-Oriented fashion.  LVOOP really helps to consolidate data and ties methods to the various data types you're working with.  Additionally, inheritance will allow you to extend data in appropriate contexts rather than create large catch-all super clusters.

My favorite aspect of OO programming is that it's a lot easier to think about when designing large applications.  You can think in terms of abstract objects and their relationships rather than trying to keep track of a million data types and an abundance of independent VIs for acting on the data.

I've managed to design very large applications using LVOOP and standard event driven producer-consumer loops.

I suggest reading up on LVOOP!

[CMal]

You might want to check out the Advanced Application page.  The page has links to a lot of useful content for creating large applications with LabVIEW.

Chris M

[JÞB]

Poke around the Large LabVIEW Application community!

It is full of tips and tricks hows and why-don'ts.

There is also a application development community nugget series (on hold pending IP issue resolution) addressing how to document and model a scaleable application using OO concepts but a LVOOP approach

[AaronMcCollough]

Great thanks!

I have looked over LVOOP and watched a bunch of videos from ElijahK before, but I will take a closer look at the links you guys posted. I'll let you know what I find. I think LVOOP looks like my most promising route but it will take some experimenting and example reading before I fully get the hang of it I'm sure.

Thanks for the quick responses! I'll let you know how things go.

-Aaron

[drjdpowell]

---

@AaronMcCollough wrote:

I have a great understanding of SubVIs and use them regularly and often. I am also familiar with the various code structures such as a producer/consumer or state machine. But I keep finding that too much of my main code is interdependent on common variables, indexes, and values that it seems impossible to simplify any of them into subVIs because I would need like 10+ inputs or a custom cluster for each one. This seems counter productive and time consuming.

...

I can reduce my program to 3 while loops. One captures Events and gives commands on a queue, another takes those queued items and performs actions, and the third performs data gathering, plotting, and saving once each second. This starts out good, but by the time I've incrementally added all the features my company requires, each loop is a huge interconnected mess of wires with no clear way to section them up into subVIs.

---

Do you try to identify related information that can be used by a whole set of related subVI's?  For example, you might have several parameters related to a specific piece of hardware.  These can be grouped into a typedef cluster (or, even better, an object with all the related subVIs part of the object class).  You definitely don't want to be using custom cluster for each subVI, but well designed subVI's shouldn't have more than a few custom inputs once related information is grouped.  

As for data in the loops, I usually just have one big cluster in a shift register.  This is never itself sent into a subVI, but parts of it (the typedef clusters or objects from above) are unbundled and sent into subVI's.  It's basically just serves as a cleaner way of holding all the parameters.  I'll attach an image of a "state" of the program I'm now working on.  There are only a few wires unbundled in each individual "state", even though the full cluster (the top shift register in the image) has 20-odd components (and some of them are subclusters/objects that themselves have many components, such as the "Selected Record" object in the image which itself is a 15 element cluster).

BTW, I'm using the "JKI state machine toolkit" which you might want to look at to get some ideas.

-- James