Archived: Transferring Data in LabVIEW Statecharts
Updated Mar 10, 2020
NI does not actively maintain this document.
This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.
This document describes methods for transferring data into and out of a statechart and discusses advantages and disadvantages of each method. This document ends with a brief discussion on synchronizing triggers and data.
The most common method for transferring data into and out of a statechart is to use the Inputs and Outputs parameters of the Run Statechart function. However, you also can use VI server references, shared variables, and functional global variables to transfer data in statecharts. Although each method has its advantages and disadvantages, you might want to use one of these methods when the default process for transferring data into and out of statecharts cannot meet one of your application requirements.
The Run Statechart function has Inputs and Outputs parameters corresponding to the input and output data of the linked statechart. The data you pass into a statechart using the Inputs parameter is available in all areas of the statechart. You must define this data before the statechart begins its iteration. The Outputs parameter returns the data when the statechart finishes its iteration. Therefore, you cannot use the Inputs and Outputs parameters to transfer data in the middle of an iteration.
Using the Inputs and Outputs parameters to transfer data into and out of the statechart also can result in very large Inputs.ctl and Outputs.ctl type definitions, which can lead to slow editing. Additionally, all data passes through the statechart with each iteration regardless of whether it is needed on a particular iteration.
Even with these limitations, National Instruments recommends this method for data transfer in statecharts because it follows the dataflow paradigm. Therefore, this method allows for easier debugging and minimizes the possibility of data access race conditions. If these limitations affect your application, consider using one of the following methods.
A VI server reference is useful when you want to update values on front panel controls from within subVIs or statecharts. To update a front panel control using a VI server reference, create a VI server reference to the control and then pass this reference into the statechart as an input. Using a reference allows you to access the data without passing a copy of the entire data set into the statechart. You also can configure the properties and methods of the reference to update the referenced control directly. Therefore, you do not have to wait for the statechart to complete an iteration before the control updates.
A shared variable is a variable that can be any data type, belongs to a LabVIEW project, and is accessible from multiple VIs and from multiple computers. To share data across a network using a shared variable, you can specify the shared variable type as a network-published shared variable.
You can access a shared variable within a statechart directly, thus eliminating the need to pass data using the Inputs and Outputs parameters. However, when using shared variables, you must consider possible race conditions when multiple people access the same variable. You also must consider data update speeds. Additionally, note that you cannot use shared variables on FPGA targets.
A functional global variable is similar to a shared variable. However, a functional global variable is a VI that incorporates a While Loop and a shift register to retain values. The structure of a functional global variable mitigates race conditions because you can specify who can read and write to a variable and when the data is allowed to be written. Figure 1 shows an implementation of a Get Value action for a functional global variable, and Figure 2 shows a Set Value action that allows you to write to the variable. You also can use this VI as a subVI and incorporate it into your main program along with a statechart. Unlike a network-published shared variable, which can be bound to a shared variable on another computer, the functional global variable is limited to a single computer.
Figure 1. Get Value Action for a Functional Global Variable
Figure 2. Set Value Action for a Functional Global Variable
An asynchronous statechart has an external trigger queue that begins a statechart iteration. To call an asynchronous statechart, you first must call the Run Statechart function. The Run Statechart function populates the input data, but the statechart then waits for an external trigger to begin the iteration. In this architecture, the input data might be out of synch with the trigger.
To synchronize the handling of triggers and the data that you pass to a statechart, you can use a synchronous statechart with an external queue that you create with the Queue Operations functions. Refer to Figure 3 and Figure 4 for an example of this calling VI architecture.
Figure 3. Enqueue the Trigger and Data Together
Figure 4. Dequeue the Trigger and Data and Send Them to the Statechart
This document describes several methods for communicating with a statechart. VI server references, shared variables, and functional global variables offer increased flexibility for your application development. Depending on the requirements of your application, these alternative methods for transferring data into and out of a statechart might be useful. Refer to the attached statechart examples to experiment further with these concepts.