Organizing Inter-Thread Communication in LabVIEW Real-Time

The first thing you should consider when implementing a system with LabVIEW Real-Time is whether you need determinism. If your application only needs LabVIEW Real-Time’s embedded qualities, including LabVIEW Real-Time's reliability, ability to off-load processing, and headless black box design, you do not need to change your programming techniques. However, if you need to operate your application in real-time, or if you need your application to be deterministic, your application must either guarantee a response to an external event within a given time or meet deadlines cyclically and predictably. When designing applications within real-time constraints, you must employ certain programming techniques to achieve determinism. When programming a LabVIEW Real-Time application, you must decide how to establish communication between multiple tasks or threads without disrupting determinism. This document details how to use the proper inter-thread communication, communicating between threads, to achieve this determinism.

With LabVIEW Real-Time, you can prioritize coded tasks to one of five levels of priority. The highest priority is time-critical priority. If it is set at time-critical priority, a time-critical task can execute deterministically. LabVIEW cannot guarantee execution time on the CPU of the system for tasks on any other priority level. The LabVIEW execution system has a number of worker threads behind the scenes in any application. Many of these threads have high priority settings and can share execution time with your code unless your code is set to time-critical priority. Threads that share processor time are non-deterministic. Avoid placing your time-critical tasks on a non-time-critical thread. For more information on priorities in LabVIEW RT see the link below.

To maintain the determinism of the control code, you must separate the control code from any non-deterministic tasks, including communication with the host. The figure below illustrates this architecture. The arrows indicate communication between VIs and between threads within a VI. The host and target communicate through TCP/IP (other communication methods, like shared memory or other network protocols may also be used.)The control code runs at time-critical priority, so it dominates the CPU whenever it needs to execute. When the time-critical thread runs, you must implement an nonintrusive method of communicating information from the control code thread to the communication thread, and vice versa, to avoid interrupting the control process. If you use global variables to share data between the control code and the communication thread, you risk encountering shared resource conflicts. When you try to access the global while another thread, such as the communication thread, is accessing the global, you introduce jitter to the control code. You do not encounter this problem on the host computer because there are no time-critical threads. You only need to worry about jitter occurring in the LabVIEW Real-Time Target processes.





Use Real-Time (RT) FIFOs (formerly known as RT Queues in LabVIEW Real-Time 5.1.2) or LabVIEW 2-Style Global Variables to pass data safely between a time-critical thread and other threads on the real-time target. RT FIFOs are like LabVIEW Queues except RT FIFOs allocate the memory required to store up to “n” elements of a specified numeric representation, including DBL, SGL, U32, and so on. Memory allocations within a time-critical loop have consequences similar to global variables; they can introduce shared resource conflicts. You can use the RT FIFOs to insert and retrieve elements simultaneously because each RT FIFO consists of two queue copies in memory, which allows concurrent read and write access. Another benefit to using RT FIFOs is that, as long as the FIFO queue does not overflow, all data is guaranteed to pass between threads. One disadvantage to RT FIFOs, however, is that VIs cannot access data arbitrarily. RT FIFO elements are buffered and LabVIEW must remove them from the FIFO one element at a time. More information on RT FIFOs can be found below under Related Links.

LabVIEW 2-Style Global Variables, also called functional global variables, are an alternative to RT FIFOs. A functional global variable (FGV) is a subVI that contains a While Loop with a nested Case Structure. FGVs use read and write access within the nested case structure and store data in shift registers, which border the While Loop. Refer to the diagrams below.



FGVs act like regular global variables, but FGVs offer two distinct advantages over regular global variables. First, FGVs are subVIs so they can have several inputs and outputs; therefore, one FGV can take the place of many global variables. Second, you can program FGVs to avoid a shared resource conflict. Right-click on the FGV subVI used by the time-critical control code, and select Skip Subroutine Call If Busy, shown in the figure below.


This setting ensures that the time-critical thread skips this FGV subVI if another process is accessing the FGV subVI. The FGV subVI returns default values for each data type used in the FGV diagram when skipped - numerics are 0, Boolean are false, and so on. The FGV images depict only one set of shift registers per FGV element. The advantage to FGV subVIs over RT FIFOs is that you can choose whether you want to buffer the FGV elements by adding more shift registers per element. An advantage of FGVs over global variables is that FGVs can evade shared resource conflicts when they are set to Skip Subroutine Call If Busy. A disadvantage of FGV subVIs is that you are not guaranteed to communicate all data between two threads because the time-critical thread must be allowed to skip the FGV when another process is accessing it.

Reader Comments | Submit a comment »

Set SubVIs Priority to "Subroutine"
If you set SubVIs Priority to "Subroutine" then you get this kontext-menu-option also in LabVIEW 7.0 (it is the same in all versions). " "Skip Subroutine ..." is available for Subroutines only.
- Dec 14, 2005

skip routine if busy
this is not in ver 7
- David Smerza, Texaco Ovonic Battery Systems. dsmerza@hotmail.com - Feb 3, 2004