<img height="1" width="1" src="https://www.facebook.com/tr?id=1101141206686180&amp;ev=PageView &amp;noscript=1">

Blog

Protecting References in LabVIEW

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.
A VI hierarchy can be thought of as an inverse tree at runtime that describes an initial VI (i.e. ‘main.vi’) and all of the VIs that are statically called from within. Calling a VI dynamically will create a ‘new’ VI hierarchy.

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 01 - Loop Snippet

Example 02: This example provides a handful of situations where references can be come invalid when launching a VI dynamically.
example_02-asynchronous_snippet.png

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.
example_03-open_vi_solution_snippet.png

Recent Posts:

Filtering Basics: Importance of Linear Phase
Publish Date 05 Apr 2017 Jason ThaiJason Thai

Linear phase and computation/memory complexity are important characteristics to [..]

Revisiting OAuth 2 in LabVIEW
Publish Date 05 Apr 2017 John AmstadtJohn Amstadt

Recap In my previous blog, we took a look at how to implement OAuth2 in LabVIEW. [..]

Engineering a Better 3D Print (Part 1)
Publish Date 05 Apr 2017 Michael MaloneyMichael Maloney

3D Printing and its widespread use has been a long time coming and seems to have [..]

NVCC – Intro to Utilizing GPU Power to Offload the CPU Part 3
Publish Date 05 Apr 2017 Jack BakerJack Baker

Assumptions: Machine has a Nvidia CUDA Core GPU (such as a GeForce) with installed [..]

How I Learn New Skills for Personal Growth
Publish Date 05 Apr 2017 Bryce UrestiBryce Uresti

Learning new skills can be quite the task especially when there's already so much [..]

Controlling the Supply Chain Dream
Publish Date 05 Apr 2017 Thomas MathewThomas Mathew

You are out with your friends, bird watching, and nothing could be more peaceful. [..]

Aligning Data in WAVE
Publish Date 05 Apr 2017 Rohama KhadijaRohama Khadija

When analyzing data from multiple sources, we often find that the time series data [..]