Company Events Academic Community Support Solutions Products & Services Contact NI MyNI

Synchronous and Asynchronous Statecharts (Statechart Module)

LabVIEW 2010 Statechart Module Help

Edition Date: June 2013

Part Number: 372103F-01

»View Product Info
Download Help (Windows Only)

You can use the LabVIEW Statechart Module to build two types of statecharts: synchronous and asynchronous. The type you choose to build affects the configuration of the Run Statechart function when you generate code for the statechart. National Instruments recommends that you decide on the type of statechart you want to use before building the statechart. While you can convert between asynchronous and synchronous statecharts, the two types handle data in different manners. If you change the type of statechart after building the statechart, you need to restructure the way in which other VIs send data to the statechart.

The type of statechart you build depends on when you want the statechart to perform an iteration. Synchronous statecharts execute one iteration at the moment the Run Statechart function receives all input data. Asynchronous statecharts execute one iteration once the Run Statechart function receives all input data and a trigger is present on the external trigger queue. If the Run Statechart function receives all input data and a trigger is not present on the external trigger queue, the function does not execute until a trigger is present. The Run Statechart function specifies that the thread that executes the statechart sleeps until a trigger is present on the external trigger queue.

Note  Synchronous statecharts begin an iteration according to the flow of data through the block diagram of the caller VI. Asynchronous statecharts begin an iteration according to the flow of data through the block diagram of the caller VI and the presence of a trigger on the external trigger queue.

A Synchronous Example

For example, consider a statechart that implements logic similar to a programmable logic controller (PLC). This statechart might read input data, execute an action, and then return output data, all within 10 milliseconds. A synchronous statechart is suitable for this example because the statechart executes at defined time intervals, that is, the statechart does not rely on a trigger to execute.

If the synchronous statechart must execute at defined time intervals, consider placing the statechart in a timed structure. For example, you can place a statechart in a Timed Loop in the caller VI. Timed Loops execute at intervals that you define. If you install the LabVIEW Control Design and Simulation Module, you can place the statechart in a Simulation Loop. Refer to the National Instruments Web site for information about this module.

An Asynchronous Example

For another example, consider a National Instruments DAQ device that monitors the temperature of a car engine. If the temperature rises above a certain threshold, the VI that reads from the DAQ device sends a trigger to the statechart, which then performs some action. An asynchronous statechart is suitable for this example because the statechart executes only after receiving a trigger, that is, the statechart does not execute at defined time intervals.

Because asynchronous statecharts do not execute at defined time intervals, you typically place these statecharts in a While Loop in the caller VI. You can place the code that sends triggers in a parallel While Loop or in another VI.

You specify the type of statechart by using the Statechart Code Generation page of the Project Library Properties dialog box.

Sending Data to Statecharts

Whereas asynchronous statecharts react to triggers, synchronous statecharts typically react to input data only. This difference is important when you create transitions and static reactions for a statechart. When you create these items for an asynchronous statechart, you specify a trigger that causes the statechart to begin taking the transition or executing the static reaction. However, when you create these items for a synchronous statechart, you typically use a guard that takes into account input data only.

Consider the DAQ and PLC examples again. The DAQ example uses a trigger to tell the statechart when to react. The PLC example does not need a trigger because the PLC executes at defined time intervals. The only data the PLC needs is the input data. Therefore, the transitions and static reactions in this statechart do not have triggers. Instead, the guards in these transitions and reactions return TRUE or FALSE depending on some logic that is based on the input data.

Note  You also can use guards with asynchronous statecharts.

Calling Statecharts

Another difference between synchronous and asynchronous statecharts is the number of VIs that can send triggers to the statechart. Only one VI, the caller VI, can send triggers to synchronous statecharts. Conversely, multiple parallel VIs, which might include the caller VI, can send triggers to an asynchronous statechart. This parallelism is possible because asynchronous statecharts provide an external queue in which the statechart stores incoming triggers.

Any VI can send a trigger to this queue at any time. If a VI sends a trigger while the statechart is waiting for a trigger, the statechart reacts to that trigger. If a VI sends a trigger while the statechart is executing, LabVIEW stores that trigger in the external queue. For example, consider the DAQ statechart again. This statechart can receive triggers from multiple DAQ devices. The statechart stores these triggers in the external queue and reacts to these triggers one at a time.

Note  Synchronous statecharts do not have external queues.

By default, all VIs that send triggers to an asynchronous statechart must be running on the same execution target. However, you can use a network-published shared variable to send triggers between these VIs and statecharts running on distributed execution targets.


 

Your Feedback! poor Poor  |  Excellent excellent   Yes No
 Document Quality? 
 Answered Your Question? 
Add Comments 1 2 3 4 5 submit