In LabVIEW, there are resources that two or more VIs might need to share. Shared resources can cause jitter and prevent applications from taking advantage of multiple CPUs. Common examples of shared resources include:

  • global variables
  • non-reentrant subVIs
  • The LabVIEW memory manager
  • Queue Operations functions
  • Semaphore VIs
  • Single-threaded DLLs

If a VI uses a shared resource, the VI acquires an operating system mutex around the resource to protect the resource from access by other VIs. A mutex locks the resource so that other VIs may not access the resource. If a time-critical priority VI preempts a lower priority VI and attempts to use a locked resource, the deterministic VI must wait because the shared resource is not available. The lower priority VI becomes more important than the deterministic VI because it must finish its work and release the shared resource before the deterministic VI can proceed. This scenario is a priority inversion and can affect the determinism of a deterministic VI.

Memory Allocations and Preallocating Arrays

When a VI allocates memory, the VI accesses the LabVIEW memory manager. The LabVIEW memory manager allocates memory for data storage. The LabVIEW memory manager is a shared resource and might be locked by a mutex for up to several milliseconds. Allocating memory within a deterministic VI can affect the determinism of the VI.

If you are using arrays in deterministic VI control loops, you can reduce jitter by preallocating the arrays before entering the loop.

The following block diagram builds an array within a control loop. The Build Array function inside the loop uses the LabVIEW memory manager at every iteration to allocate memory for the array, which affects the determinism of the loop.

The following block diagram uses the Initialize Array function outside the loop and the Replace Array Subset function inside the loop to create the array. Because the array is preallocated outside the control loop, the control loop no longer needs to access the LabVIEW memory manager at every iteration.

Casting Data to Proper Data Types

Cast data to the proper data type in VIs running on the RT target. Every time LabVIEW performs a type conversion, LabVIEW makes a copy of the data buffer in memory to retain the new data type after the conversion. The LabVIEW memory manager must allocate memory for the copy, which might affect the determinism of deterministic VIs. Also, creating copies of the data buffer takes up memory resources on an RT target.

Use the smallest data type possible when casting data. If you must convert the data type of an array, do the conversion before you build the array. Also, keep in mind that a function output reuses an input buffer only if the output and the input have the same data type. Arrays must have the same structure and number of elements for function outputs to reuse the input buffer.

Reducing the Use of Global Variables

LabVIEW creates an extra copy in memory of every global variable you use in a VI. Reduce the number of global variables to improve the efficiency and performance of VIs. Creating copies of global variables takes up memory resources on an RT target.