Prevent data loss and promote efficiency when transferring data between producer and consumer loops by using queue nodes.
By creating a queue of data that is ready to be consumed, a consumer loop can process a greater volume of data at more regular
intervals without losing data. This is especially useful if data from multiple network channels need to be processed in the
order in which they arrive.
Since each queue is bound to one data type, each unique data type in a producer loop requires a unique queue, which could
complicate the diagram. To avoid complicating the diagram with multiple queues, use a cluster or array of clusters to write
a variety of data types in a single queue.
What to Use
What to Do
Create the following diagram to automate the reading and writing of data without the risk of losing data.
Customize the gray sections for your unique programming goals.
|| Use Obtain Queue to set the data type for the queue and to set the maximum number of elements the queue can hold. In this example, the queue
can hold up to 50 pieces of numeric data.
If you call Obtain Queue inside a loop, this node creates a new reference each time the loop executes, and each new reference uses an additional four
bytes of memory. To conserve memory, call Obtain Queue once before the loop executes.
|| Use Enqueue Element in the producer loop to add data to the back of the queue. If the queue is full, the producer loop stops adding elements
to the queue until Dequeue Element removes data. If the producer loop runs slower than the consumer loop, the queue will empty and result in an underflow.
If you want to ask a sensor for data at regular intervals instead of as often as possible, use Wait in the producer loop.
|| Use Dequeue Element in the consumer loop to remove data from the front of the queue so that data processes in the same order that it is added.
If the queue is empty, the consumer loop waits to remove elements from the queue until Enqueue Element adds data. If the consumer loop runs slower than the producer loop, the queue will fill up and result in an overflow.
Use Get Queue Status in the queue status loop to return information about the current state of the queue, such as the number of elements currently
in the queue.
Using this node in parallel code can result in race conditions which can cause incorrect logic control and data loss.
|| Click the
Stop button on the panel. The queue status loop finishes executing and calls Release Queue. This node invalidates the queue reference which causes the producer and consumer loops to error out and finish executing.
Larger applications typically require a more sophisticated mechanism for stopping parallel loops. To see an example of such
an architecture, launch the Queued Message Handler project in LabVIEW NXG.
If a consumer loop processes data too slowly and results in an overflow, add a consumer loop to the diagram to raise the rate
of data consumption.
If a producer loop reads data too slowly and results in an underflow, raise the producer loop time if Wait is used. Otherwise add a producer loop to the diagram to raise the rate of data production.
When multiple loops execute at the same time and
change the same object, race conditions can occur which can result in data
loss. Using Get Queue Status as a control mechanism
that triggers an event between loops in code could result in race conditions
if other loops change the contents of the queue before the event can be
executed. This means that when the event does execute, it may do so based on
outdated data and overwrite more current data. Improve the speed of your VI
without the risk of creating race conditions by following the practices
outlined in the Using Parallel Loops to Increase VI Execution Speed section
of Strategies for Improving VI Execution Speed. Use
an event structure as a safer way to trigger your code using event-driven programming.
Search within the programming environment to access the following installed example:
Queued Message Handler