Blog

The concept of LabVIEW Object Oriented Programming (LVOOP) has been around for a number of years now, but has consistently been one of those areas that seemed to have to high of a learning curve to justify learning “just because”. Luckily, in a recent project I managed to get the green light for implementing an object oriented (OO) solution.

For me the biggest appeal for OO programming in LabVIEW was the increase in organization, manageability, and code-reuse that it offers. The implementation requires you to go a little beyond just creating VI’s and using controls, indicators, and functions that are in the standard library, but as this LabVIEW Object Oriented Introduction shows, it is not that scary.

I was totally sold on the Board Testing example (available in LabVIEW 8.2 and later in the directory “labview\examples\lvoop\BoardTesting\Board Testing.lvproj”).

The key to understanding the benefits of an OO solution for this problem compared to a “traditional” LabVIEW solution lies in grasping that we can look at a circuit board test in 1 of 2 ways. We can look at it as each circuit board type is different and thus needs to have its own explicit test VI written for it, which will be similar for each type, but not the same; or we can look at each circuit board as an object containing a collection of component objects, so that we now define which objects a circuit board type has and then these component objects test themselves. This example demonstrates the following shift in mindset:

Traditional LabVIEW:

1. I have a bunch of circuit boards to test
2. There are several types of boards which each have different pass\fail criteria since they have different layouts of components
3. I need to create a test VI for each type of board
4. I need to create a test sub VI for each component
5. I can leverage code reuse by making sub VI’s to test each component, which I will drop into each board type’s “Test” VI
6. If I create a new board type, I will need to explicitly define the test procedure for it

LabVIEW Object Oriented Programming

1. I have a bunch of circuit boards to test
2. Each board can be thought of as an object containing component objects. Thus different types of boards are simply child classes of the “Circuit Board” class
3. I need to define the component set for each Circuit Board type
4. I need to create a “Test” method for the Circuit Board class and for each Component class. To test a board, all I need to do is call the “Test” method for the board which will iterate through all of its components which will call their own “Test” methods
5. Code reuse is leveraged by reuse of component “Test” methods and by inheritance, which allows similar board types and components to use some of the same sub-pieces of the “Test” methods
6. If I create a new board type, all I need to do is define the components, since the “Test” method of each circuit board simply calls the components’ “Test” methods

Of course there are many other OO design concepts besides the one discussed here (which is a Hierarchy Design I believe), but this pattern alone lends itself to many applications in LabVIEW. Some quick examples would include TDMS files (made up of Channel, Property, and Group Objects), any sort of testing (each test is made up of Test Step Objects), and even something like a sensor reading or vision inspection application (each reading is made up of different Limit, Value, and Reference Point Objects).

Having picked up a good feel for proper use of LVOOP, I look forward to using it in future projects, and I know that it will continue to reduce complexity and improve the project development.

Learn more about DMC's LabVIEW programming expertise.