Benefits of Object-Oriented Design in Test and Measurement

This example demonstrates the benefits of LabVIEW object-oriented programming for a company that writes and maintains test and measurement programs.

Table of Contents

The Testing Goal

A company produces computer plug-in boards. The company has three products:
  1. Basic DAQ Board
  2. Elite DAQ Board
  3. GPIB Board
The company wants to inspect each board as it comes off the assembly line to make sure the pieces soldered to the boards are placed correctly. A camera over each of the three assembly lines sends images are sent to a single machine. The machine analyzes the images and determines if the board is assembled correctly.


The boards follow a standard form factor and are made up of common components: resistors, capacitors, and chips.
A) Basic DAQ Board
B) Elite DAQ Board (same as Basic DAQ but with the addition of the on-board filter)
C) GPIB Board

The company needs a LabVIEW program that receives images from the cameras, analyzes them and determines if each board is assembled correctly.

Task-Based Solution

In the Board Testing project, open Test Boards_TASK.vi in the Task-Oriented Solution folder.

This VI demonstrates a task-based approach to the problem posed in the previous section.

Display and examine the block diagram. First, Generate Test Images.vi simulates the acquisition of the images and places them in a queue. Then, a While Loop retrieves one image at a time from the queue and processes it.

A value is paired with each image to designate the type of board it represents. A Case structure switches on the board type and runs the test for that board.

The test results include a unique test identification string, the board type, and a pass/fail Boolean.

Review the subVIs that perform the tests for the boards. They verify the presence of blocks of certain colors at certain positions on the board. Using shared subVIs, they reuse code for common blocks.
   
Overall, this is a good solution that fulfills the requested task.

Object-Oriented Solution

In the Board Testing project, open Test Boards_OBJECT.vi in the Task-Oriented Solution folder.

This VI demonstrates an object-oriented approach to the problem posed in the first section.

Display and examine the block diagram. The generation of simulated images and the test results output are the same as in the task-based solution. This demonstrates that you can rewrite a section of an application to use LabVIEW classes without rewriting the entire application.

The Case structure to switch off the board type is now in the Enum to Board Design.vi subVI that produces an object of the appropriate type.

With the object-oriented approach, it is easier to see that the VI performs the same operations (checking the image and creating a test name) on each board.

Open Check Image Matches Design.vi from the block diagram of Test Boards_OBJECT.vi and display its block diagram. Note that it has a very different structure than the tests in the task-based approach.

Instead of a set of checks for blocks of certain colors at certain positions, this VI gets a list of component objects from the board and calls the Self Test method on each component.

The object-oriented approach encourages the developer to decompose the problem differently than the task-based approach. The next section reviews some of the benefits of the object-oriented approach.

Costs and Benefits of Object-Oriented Design

Open the Classes folder in the Object-Oriented Solution folder. The object-oriented approach uses many more subVIs than the task-based approach.

Each VI in the object-oriented system does a very specific task. The VIs are therefore smaller, and more numerous, than the VIs in the task-based approach. This approach produces code that is easier to read, especially for developers who are new to the project and unfamiliar with the existing VIs.

But the other advantages of object-oriented programming are not necessarily seen when you first write the code. Consider a case where you have to modify your application.

Scenario: A Vendor Changes a Part

Notice that all three boards have three blue squares in a column on the left side and a purple bar on the top row. In the task-based solution, the the test for these four blocks is in a subVI that is common to all three board tests. Shared code in common subVIs is good programming practice. But what the picture does not display is this:

1 == Analog to Digital Converter
2 == Digital to Analog Converter
A) Basic DAQ Board

B) Elite DAQ Board

C) GPIB Board


In this particular situation, the A/D converters and D/A converters happen to have identical appearances. However, the GPIB board is actually different from the two DAQ boards, even though they look the same.

Suppose a parts vendor changes the color of the A/D converters to red. Contrast the steps required to modify the task-based and object-oriented test applications:
Task-based VIs
Object-oriented VIs
The modification to the object-oriented VIs is faster and provides less opportunity to introduce errors.

Conclusion

The task-oriented solution shares code in places where the problem looks the same from a task perspective. The object-oriented solution shares code where the objects underlying the task are the same. This decomposition into components makes it very easy to update code when a component changes. The behavior of that component is isolated from the rest of the system.

Consider these scenarios:
In summary, the value of object-oriented design is not always apparent in the first version of an application (although code readability and organization are certainly valuable). But the benefits of easier and more robust code modification become clear with each revision.