Creating and Calling LabVIEW Sub-VIs

The ideal program in any programming language looks much like the block diagram, flow chart, or algorithm from whence it came. The more “human” the text, the more readable the code will be. Therefore, it is important to break large programs into smaller sub-programs, functions, or subroutines with human-sounding names. This simultaneously makes the program easier to understand and is yet another way to document the code. 

On larger projects, subroutines can help break down the entire project to distribute the workload among programmers. Perhaps a large program has multiple nodes for different functionalities that need to be coded. 

The group can decide on the overall structure and then operate in smaller work groups or as individuals to finish the program. It also allows new programmers or interns to contribute to the project by writing a few smaller subroutines rather than simply shadowing more experienced programmers.

Subroutines also help increase the speed of upgrades or added features. As a general rule, any time a piece of code is used more than once, it should be a subroutine. This prevents problems with updates. 

Suppose that a piece of code is used to relate a best-fit line to predict some parameter in a control routine. New calibration data is collected and the best-fit line needs to be updated. If this update can be performed in one place, versus ten places, this greatly simplifies the update and the troubleshooting for where one place gets missed.

LabVIEW makes creating and calling subroutines, called “Sub-VIs,” very simple, though there are some nuances that must be addressed. LabVIEW Sub-VI (virtual instrument) creation can be performed quickly and called just as easily, though sometimes this is problematic if proper planning has not been performed before the programming.

 

Creating a LabVIEW Sub-VI

Suppose a piece of code used in the United States is now going to be shipped to an international customer, and the newest update will need to have unit conversions from Fahrenheit to Celsius throughout the program. Rather than writing the same code in multiple places, the smart action is to create a Sub-VI.

In LabVIEW, the programmer can simply write the code once. Then, drag and select the code, plus any wires leading into or out of this section of the code. Under the “Edit” menu, select “Create Sub-VI.”

 

Figure 1. Notice how a wire from “Temperature Input” and “Temperature Output” has been captured. The wires that lead in and out of the selection will be inputs and outputs to the Sub-VI. 

 

The code has now become a single block, a Sub-VI, that can be reused repeatedly. Because the Sub-VI is its own code block, it must be saved separately. Name it something that makes sense, like “F to C.vi.”

 

Figure 2. The simplest of Sub-VIs. This works, but the default Sub-VI icon may not be useful.

 

Useful Documentation with LabVIEW Sub-VIs

The default icon leaves much to be desired. It tells the programmer nothing about what is happening in this Sub-VI. Thankfully, there are a few ways to make this code more readable. First, double-click on the icon to open the Sub-VI. Then click on the icon in the upper-right corner. This will open up the icon editor and allow the programmer to change the icon.

Figure 3. Click in the blue circle to load the Icon Editor.

 

The Icon Editor lets the programmer create graphics or text to represent the Sub-VI. Take advantage of these tools; some programmers color code their Sub-VIs into categories, such as “unit conversions,” “file manipulation,” “instrument control,” and so on.

 

Figure 4. The icon has been modified to read “F to C.” The blue banner at the top matches the author’s convention of blue for “unit conversions and math.”

 

The programmer can also right-click on the icon and select “Sub-VI properties.” In this list, there is a “Documentation” option. This allows the programmer to author what text appears in the “Help” window or link the documentation to an existing file.

 

Figure 5. Much of the Sub-VI’s function can be controlled from the VI Properties window. 

 

The VI Properties window can be used to alter the Sub-VI’s window at run-time (the default option does not display a new window), such as whether it can be used recursively, or other properties. It also displays how much memory it uses and how much space on the hard disk it requires.

 

Calling a LabVIEW Sub-VI

Calling a Sub-VI is also simple. It can be searched for in the Functions Palette, dragged, and dropped into place, like any other LabVIEW block. To connect the Sub-VI, run wires to the pins on the edges of the Sub-VI, just like any other LabVIEW block.

 

Problems with Calling a LabVIEW Sub-VI

Sub-VIs are great, but it can be easy to get carried away. In the sample VI and Sub-VI for this article, notice how there is little difference between the two. 

In reality, there would be a lot more code leading up to the unit conversion, but in this program, there is not. The sample VI and the Sub-VI are nearly identical, and the Sub-VI adds no value. Instead, variables are simply passed to and from the Sub-VI. 

Surprisingly, this inefficiency happens when teams of programmers are stitching together code from multiple places. To check for this problem, see if the calling VI has any code besides what is in the Sub-VI. If it doesn’t, then the Sub-VI is unnecessary.

 

Figure 6. Two terminals are wired on this Sub-VI. The left side is typically for inputs and the right for outputs. The bottom corners are often used to pass error clusters.

 

Another inefficiency involves the wiring terminals. Next to the icon is a wiring diagram. These terminals can be named, new terminals added, or terminals subtracted. The temptation is to save memory and remove unwired terminals. However, the wiring will need to be altered again if a later version of the code requires more terminals. It is better to leave the unwired terminals for future expansion. Also, if a Sub-VI requires more than 16 inputs and outputs, then it should probably be broken into multiple Sub-VIs for clarity and ease of use.

LabVIEW Sub-VIs are versatile and can clean up code to make it more readable, easier to update, and easier to delegate smaller pieces of code to a programming team. While there are some complications, they greatly simplify the programming and documentation experience of the entire LabVIEW VI.