© National Instruments

| 1-1

1

Moving Beyond Dataflow

As you learned in LabVIEW Core 1, LabVIEW is a dataflow language where the flow of data
determines the execution order of block diagram elements. A block diagram node executes when
it receives all required inputs. When a node executes, it produces output data and passes the data
to the next node in the dataflow path. The movement of data through wires and nodes determines
the execution order of the VIs and functions on the block diagram. This type of communication
between nodes is referred to as synchronous communication.

Topics

A. Asynchronous Communication

B. Queues

C. Event-Driven Programming

Lesson 1

Moving Beyond Dataflow

1-2

| ni.com

A. Asynchronous Communication

Although LabVIEW is a dataflow language that uses wires to transfer data between functions, there
are situations where communicating asynchronously, or without wires, is desirable. In this lesson
you learn two important techniques for communicating asynchronously—queues for
communicating between parallel loops and events for communicating between the user interface
and the block diagram.

B. Queues

Use queues to communicate data between parallel loops in LabVIEW. A queue can hold data of
any type and can store multiple pieces of data. By default, queues work in a first in, first out (FIFO)
manner. Therefore, the first piece of data inserted into the queue is the first piece of data that is
removed from the queue. Use a queue when you want to process all data placed in the queue.

Variables are useful in LabVIEW for passing data between parallel processes. However, when
using variables it is often difficult to synchronize data transfers, which may cause you to read
duplicate data or to miss data. Further more, you must take care to avoid race conditions. This
lesson introduces queues as alternative methods for passing data between parallel processes.
Queues have advantages over using variables because of the ability to synchronize the transfer
of data.

Queue Operations

Use the queue operations functions to create and use queues for communicating data between
different sections of a VI and different VIs.

Table 1-1 describes the queue operations functions you use in this course.

Table 1-1.

Queue Operations Functions

Function

Description

Dequeue Element

Removes an element from the front of a queue and returns
the element.

Enqueue Element

Adds an element to the back of a queue.

Enqueue Element at Opposite

End

Adds an element to the front of a queue.

LabVIEW Core 2 Course Manual

© National Instruments

| 1-3

Refer to the Queue Operations Functions topic of the LabVIEW Help for a complete list and
description of queue operations.

When used with the producer/consumer design pattern, queues pass data and synchronize the loops
as shown in Figure 1-1.

Figure 1-1.

Producer/Consumer Design Pattern (Data) Using Queues

Get Queue Status

Returns information about the current state of a queue, such
as the number of elements currently in the queue.

Obtain Queue

Returns a reference to a queue.

Release Queue

Releases a reference to a queue.

Table 1-1.

Queue Operations Functions (Continued)

Function

Description

Lesson 1

Moving Beyond Dataflow

1-4

| ni.com

The queue is created before the loops begin using the Obtain Queue function. The producer loop
uses the Enqueue Element function to add data to the queue. The consumer loop removes data from
the queue using the Dequeue Element function. The consumer loop does not execute until data is
available in the queue. After the VI has finished using the queues, the Release Queue function
releases the queues. When the queue releases, the Dequeue Element function generates an error,
effectively stopping the consumer loop. This eliminates the need to use a variable to stop the loops.

The following benefits result from using queues in the producer/consumer design pattern:

•

Both loops are synchronized to the producer loop. The consumer loop only executes when data
is available in the queue.

•

You can use queues to create globally available data that is queued, removing the possibility of
losing the data in the queue when new data is added to the queue.

•

Using queues creates efficient code. You need not use polling to determine when data is
available from the producer loop.

Queues are also useful for holding state requests in a state machine. In the implementation of a state
machine that you have learned, if two states are requested simultaneously, you might lose one of
the state requests. A queue stores the second state request and executes it when the first has
finished.

Case Study: Weather Station Project

The weather station project acquires temperature and wind speed data, and analyzes it to determine
if the situation requires a warning. If the temperature is too high or too low, it alerts the user to a
danger of heatstroke or freezing. It also monitors the wind speed to generate a high wind warning
when appropriate.

The block diagram consists of two parallel loops, which are synchronized using queues. One loop
acquires data for temperature and wind speed and the other loop analyzes the data. The loops in the
block diagram use the producer/consumer design pattern and pass the data through the queue.
Queues help process every reading acquired from the DAQ Assistant.

Code for acquiring temperature and wind speed is placed in the producer loop. Code containing the
state machine for analysis of temperature-weather conditions is within the no error case of the
consumer loop. The code using a queue is more readable and efficient than the code using only
state machine architecture. The Obtain Queue function creates the queue reference. The producer
loop uses the Enqueue Element function to add data obtained from the DAQ Assistant to the queue.
The consumer loop uses the Dequeue Element function to get the data from the queue and provide
it to the state machine for analysis. The Release Queue function marks the end of queue by
destroying it. The use of queues also eliminates the need for a shared variable to stop the loops
because the Dequeue Element function stops the consumer loop when the queue is released.

LabVIEW Core 2 Course Manual

© National Instruments

| 1-5

Figure 1-2 shows the block diagram consisting of a producer and a consumer loop. Data transfer
and synchronization between the loops is achieved by the queue functions.

Figure 1-2.

Data Transfer and Synchronization of Parallel Loops Using Queues

C. Event-Driven Programming

Event-driven programming is a method of programming where the program waits on an event to
occur before executing one or more functions. The features of event-driven programming extend
the LabVIEW dataflow environment to allow the user’s direct interaction with the front panel and
other asynchronous activity to further influence block diagram execution.

Events

What Are Events?

An event is an asynchronous notification that something has occurred. Events can originate from
the user interface, external I/O, or other parts of the program. User interface events include mouse
clicks, key presses, and so on. External I/O events include hardware timers or triggers that signal
when data acquisition completes or when an error condition occurs. Other types of events can be
generated programmatically and used to communicate with different parts of the program.
LabVIEW supports user interface and programmatically generated events. LabVIEW also supports
ActiveX and .NET generated events, which are external I/O events.

In an event-driven program, events that occur in the system directly influence the execution flow.
In contrast, a procedural program executes in a pre-determined, sequential order. Event-driven
programs usually include a loop that waits for an event to occur, executes code to respond to the
event, and reiterates to wait for the next event. How the program responds to each event depends
on the code written for that specific event. The order in which an event-driven program executes
depends on which events occur and on the order in which they occur. Some sections of the program