Have you ever spent hours trying to track down a bug only to find that it was something simple? Or worse: something you didn’t know that you didn’t know. When programming in LabVIEW, a language that simultaneously meets the needs of veteran programmers and neophytes alike, basics can sometime be lost in abstraction; for all the things LabVIEW hides from you it can also create bugs that are seemingly inexplicable and incredibly hard to track down. One of those bugs is when LabVIEW decides to clean up references; which in practice is less a bug and more of a feature.
LabVIEW has two general rules when it comes to references:
- When a reference is created, it is associated with the VI hierarchy of the VI where the ‘create function’ is located
- LabVIEW will release/close any references associated with a VI-Hierarchy that is idle.
This cleaning of references is a kind of ‘garbage collector’ where LabVIEW looks for items that it thinks are no longer being used. This generally affects items that are passed-by-reference rather than passed-by-value. In most cases, normal (non-advanced) LabVIEW programming won’t violate either of these rules; but once you have to create a separate VI hierarchy or launch VIs dynamically where references are created, the life cycle of associated VI Hierarchies become important to achieving certain functionality.
We’ve included three examples providing situations where references can be lost (from simple to advanced), short summaries are provided below, to see these examples in action, download the soure code (LabVIEW 2015) available here: lv-reference-protect.zip
Example 01: This example shows a simple mistake that can cause you to lose a reference. When a for loop runs zero times, simple tunnels will output the default value of the data type rather than the data that’s wired in; using a shift register will preserve the data if the for loop runs zero times.
Example 02: This example provides a handful of situations where references can be come invalid when launching a VI dynamically.
Example 03: This example shows a solution for preserving a reference created in another VI hierarchy using the run VI method and how to keep it alive while in use. This method mirrors the functionality of the proxy caller when using the asynchronous call functions.
