Home
Quickstart Guide
Introduction RIO Academic RIO Application examples Your first RT app Your first FPGA app
Real-Time
Basic procedures System admin File system I/O monitor System controller architecture Timed loops Inter-process communication RT/Host communication RT/FPGA communication FPGA personalities Interrupts Datalogger (file I/O)
FPGA
Design flow Simulation Inter-process communication RT/host communication Derived clock domain IP blocks FPGA personality
Networking
Get connected Email Web services UDP TCP IP addresses
Site Map
Guides Code examples Procedures Tags LabVIEW block diagram elements Targets Communications All pages
Glossary How to use About
RIO Developer Essentials Guide for Academia
RT PC guide

RT programming: Queue-based state machines

Queue-based state machines excel at implementing system control, data measurement and processing, and other tasks to respond to inputs from the surrounding physical system and user interface. Learn about three popular design patterns: queued state machine (QSM), queued message handler (QMH), and event-driven producer-consumer loops.

Elements entering and leaving a queue

Summary

State machines perform system control, data processing, and any task that involves executing a sequence of activities in response to inputs from the surrounding physical system, the user interface, and other processes within the system. Popular state machine design patterns use queues to maintain the system state and to communicate with other state machines operating in parallel within the system.

Queued State Machine (QSM)

The Queued State Machine (QSM) is a popular design pattern that is flexible and versatile, easy to maintain, and computationally efficient. The QSM contains three primary elements contained within a while-loop structure:

  1. “Guard Clause” VI – wait for a state (a string) to become available in the state queue and then dequeue it (remove it from the queue); when the input error cluster status is true, insert the inbound error cluster value into the error handler queue and return “Error” as the state
  2. “Kernel” VI – implements the actions to be performed for each state such as calculations, counting, decoding, peripheral I/O, data measurements, and network transactions; this VI can also insert states into its state queue
  3. Feedback node – stores values that must persist from one state to another

Queued Message Handler (QMH)

The Queued Message Handler (QMH) implements a complete system by partitioning the system into well-defined tasks, with each task implemented by a QSM operating independently and in parallel with all of the other tasks. QSMs communicate with each other by sending messages directly to their queues. The QMH contains application-specific tasks as well as these standard tasks:

  1. System Manager – Maintains the high-level operating mode of the overall system and issues commands to the task loops (QSMs); the task loops issue alert messages to the system manager and can also directly message other task loops to reduce the complexity of the system manager task
  2. Command Parser – Accepts network connection requests from the human-machine interface (HMI) running on the PC host, parses the received commands, and inserts messages into the System Manager queue
  3. Error Handler – All loops place error messages into the error handler queue and continue to run; when an error message is received the error handler issues a “Shutdown” message to all task loops and displays the message; other behavior can be designed, such as logging the error message to a file and continue running, if possible (normally the RT application should continue running while gracefully handling error conditions)

Event-driven producer-consumer state machine

The event-driven producer-consumer state machine creates a responsive user interface for the human-machine interface (HMI) running on the desktop PC. Based on two loops operating in parallel, the “producer” loop event structure responds immediately to user interactions such as button clicks and mouse movements to send commands through a queue to the “consumer” loop which performs the required tasks. Separating the state machine into two loops allows the user interface to remain responsive should a consumer task require an unusual amount of time or must wait for a shared resource to become available.

Code examples

For more information

  1. Effective LabVIEW Programming (http://www.ntspress.com/publications/effective-labview-programming/)
    An excellent textbook by Dr. Thomas J. Bress covering all aspects of system design; Chapter 20 describes the "Queued State Machine with Arguments" in detail. Download all of the code examples from this textbook: follow the link above, select "User Resources", and then "All VIs".
  2. The LabVIEW Style Book (https://www.pearson.com/us/higher-education/program/Blume-Lab-VIEW-Style-Book-The/PGM219404.html)
    This comprehensive textbook by Peter A. Blume lays out everything you need to know about best practices for LabVIEW system design. Chapter 8 describes the "Queued State Machine" in detail.