Real-Time Sequencer Architectures for LabVIEW

Publish Date: Nov 05, 2008 | 1 Ratings | 4.00 out of 5 |  PDF


LabVIEW Real-Time (RT) was designed to take care of two specific engineering needs, real-time event response and closed loop control systems. Often there is a need to use a single RT controller for multiple real-time applications or “steps”. The goal of each step is to maintain real-time properties and provide simple user feedback. To maximize the use of our real-time hardware—both in hardware/software efficiency as well as manpower efficiency—we need to sequence our derived steps. Sequencing allows users to determine the steps to run, the order in which to run individual steps, and how to coordinate the results of all the steps in a single location—typically on the host. The following two example architectures demonstrate how to facilitate real-time sequencing, while retaining real-time event response and closed loop control systems.

Table of Contents

Table of Contents

  1. Background
  2. Theory of Operation
  3. Implementation
  4. RT Sequencer API
  5. Extended Implementation: Real-Time Event-Based Sequencer
  6. Conclusion
  7. Download
  8. Feedback



Test engineering applications often require software with a degree of determinism that standard operating systems cannot provide.   For these types of applications a real-time operating system becomes the solution that must be used to meet the overall goal of accurate tests. A predominate difficulty occurs, how to maintain the dynamic properties of standard operating systems without losing the determinism of a real-time application.

Almost all real-time applications use a host-target paradigm to accomplish a control system.  The system is made of a host program (a VI running on a general purpose operating system), and a target program (a VI running on a FieldPoint, cRIO, PXI real-time controller, or real-time desktop).  The user interacts with the host program which has a user friendly interface.  The host program interacts with the target program in such a way as to not affect determinism (set to a normal priority).  The target program takes care of the real-time operations (at a time-critical priority), while remaining in contact with the host program (at a lesser priority).  The host program and target program interact through a communication protocol (i.e. TCP, UDP, shared variables, etc.).  In a real-time sequencer application, the target program dynamically runs steps in an order chosen by the user.  Each step then talks back and forth to the target program through some predefined commands or Application Specific Interface (API).

Figure 1. Overview of the RT Sequencer Example


Theory of Operation

An effective RT Sequencer application should be usable, maintainable, and scalable as well as include the following characteristics:

Characteristics for a Host Program

  • User-Friendly
  • Event-based to reduce CPU use
  • Receive/Transmit data to the real-time sequencer (target program)

Characteristics for a Target Program

  • Operate  at normal priority so that steps can use time-critical priority for determinism
  • Receive/Transmit data from steps in a deterministic manor using sequencer API
  • Receive/Transmit data from the host program through a communication protocol (includes sending available steps from the target to the host and receiving steps to run in a dynamic order)

Characteristics for Sequencer API to be used in steps

  • Pass data to/from the target program in a deterministic manor



The following is an example architecture for a real-time sequencer (RTS) application.  Each portion of the code was written to achieve the characteristics described in the Theory of Operation.  Before the example can be opened properly in LabVIEW, you must follow the instructions from here.

TCP was elected as the communication protocol between the host and target because it is lossless and has low overhead.  To help with the maintainability and scalability of the TCP code a simple TCP/IP Messaging Protocol (STM) was used.  For further information please refer to the Developer Zone Article A Simple TCP/IP Messaging Protocol for LabVIEW.


In reference to fig. 1, we will begin by describing RT Sequencer Host program (RT Sequencer –  The host begins by making a connection to the target.   Once a connection is established we enter a variation of a producer/consumer architecture.  The Producer loop is also a state machine architecture.  The state machine has three states Initialize, Communicate, and Exit.  The Initialize state is used to set all the users controls and indicators to a known status.  The Communicate state waits to receive messages from the target.  The message can either be processed in the producer (typically you process in the producer if the operation is short so as to not slow down the reception of further messages), or sent to the consumer via generating a user event (typically longer actions like file I/O, or sending a message back to the target are handled in the consumer).  The Exit state is used to clean up the user interface or display closing user dialogs.  For this example the Exit state is just a place holder.  Parallel to the producer loop is the consumer loop.  The consumer loop is the event handler for user events (i.e. button clicks on the front panel) or dynamic events activated by the target.  The consumer also has the task to send messages to the target. Fig 2 illustrates the overall flow of the RT Sequencer Host program.

[+] Enlarge Image

Figure 2. Host-side application for the RTS and RTEBS



In contrast to the Host program architecture, the RT Sequencer Target program (RT Sequencer – operates by continually running parallel loops.  It begins by waiting for the host to make a connection to the target.  Then it sends important information for the STM to operate correctly (Meta Data), followed by communicating to the host program the available steps on the target.  The target then waits for the host program to return the user’s selection of steps to run.  After the steps to run are determined, three parallel operations occur.  The first loop starts the execution of each step sequentially via VI server.  The second loop receives messages from the current step being run as passes that message to the host. The third loop receives messages from the host program and passes them to the currently running step.  When all the steps are finished, the target program sends a message to the host saying it is complete, and then waits for the host to send more steps to run.  Fig 3 illustrates the overall flow of the RT Sequencer target program.

[+] Enlarge Image

Figure 3.  RT-side application for the RT Sequencer


The final component for an RT Sequencer application is a Sequencer API to be used in each of the steps.  These are simple VIs that pass messages to the target program and vice versa .  The key to an effective Sequencer API is that the API does not impede the development process, and does not affect the determinism of time-critical actions.  Thus the API must be able to detect when the step is being developed versus when the step is being dynamically called by the Sequencer.  It is assumed that a completed step will be compiled into a real-time executable, so detecting completed steps is simply detecting if the VI is in an RTEXE.  To pass data deterministically RT FIFOs send data back-and-forth between the target program and steps.

[+] Enlarge Image

Figure 4. A step that could be called by the RT Sequencer


RT Sequencer API

This implementation of a RT Sequencer example provides five high-level API VIs along with four low-level VIs to build upon.  The following is a brief description of each.  For examples on how to use the API VIs please visit here.

Update Status:  Use this VI to update the status indicator on the host program from a step.  This VI does nothing unless the step is being called by the RT Sequencer – using VI server.

Write to File (Host):  Use this VI to send text back to the host to be written to file.  The name and directory of the file are determined on the host program.  The default file name is “Test File.txt” and the directory is the same as “RT Sequencer –”.  The file location can be changed within  “RT Sequencer –”.

Read INI:  Use this VI to send a message to the host to return information from a configuration file (also referred to as an INI file). The information returned is determined by the Key Info input. If this VI is not called by the RT Sequencer - then it returns Default. If This operation times out then it returns the default. Use this VI in the initialization portion of your code and not in deterministic code.  For the example program the default INI file is named Sequencer.ini and is located in the same directory as "RT Sequencer-".  

Read Host Control:  Use this VI to read the value of a control on the host program. You must provide the Control Name that you are trying to read. If this VI is called without "RT Sequencer-" being loaded into memory the Default value will be returned.

Write Host Control:  Use this VI to write a value to a control on the host program. You must provide the Control Name that you are trying to read, along with the Control Value and type string. You should use Flatten to String with version 7.1 option turned on to easily flatten the data. If this VI is called without "RT Sequencer-" being loaded into memory this VI will do nothing.

Advanced VIs:  There are five low-level VIs that are used to extend the RT Sequencer API.  Each takes care of a different direction of passing data from the step to the target program and vice versa.  At the heart of Update Status and Write to File (Host) is the Enque to Target VI.  Each of these VIs is initialized by the target program inside the Initialize Target VI.   Use Enque to Target and Deque from Target to extend the API for the RT Sequencer.  You can use Enque to Step and Deque from Step to change the way the target program receives/sends data to the steps.  For examples on how to effectively use the Advanced VIs open any of the higher level API VIs.


Extended Implementation: Real-Time Event-Based Sequencer

The Real-Time Sequencer (RTS) provides for a simplified way to sequence steps.  Because of its simplicity there are some features that would be desired in a final architecture that are excluded, for example the ability to abort a step.  To accommodate the ability to perform an event in parallel with running a step, changes need to made to the target program.  The result is an extension of RTS called a Real-Time Event-Based Sequencer (RTEBS).  

Unlike the RTS, the RTEBS target program has five parallel loops.  Fig 5. illustrates the structure of the RTEBS target program.  The first loop, Steps Receive, receives messages from the currently running step.  Depending on the message, it will pass that along to the Host or the Action loop.  The Host Receive loop receives messages from the Host, and will route the message to the Step or the Action loop.  The Connection loop opens and closes connections from the Host.  One large advantage of the RTEBS from the RTS is that the host does not need to be present in order for the tests to be run.  The Execution loop sequences the steps to run.  The Action loop performs real-time actions in parallel to a step running.  An example of a common action would be an abort operation, which would stop the sequencer from running steps until it reaches a safe state.

The RTS and RTEBS use a very similar Host program (fig. 2) and the same Step API (fig. 4).

[+] Enlarge Image

Figure 5. RT-side application for the RT Event-Based Sequencer

In general the RTS more simplistic than the RTEBS, and much of the RTEBS was built from the framework of the RTS.  Table 1 breaks down the major differences between the two applications further.

Table 1.  A comparison of the RTS and RTEBS

[+] Enlarge Image

There are three main differences between the RTS and RTEBS.  The first is that the RTS was designed to be controlled by the Host program.  This makes it so that the sequence order is chosen by the user.  In contrast, the RTEBS is more independent of the host, and the order is hard coded in the real-time side of the application.  Second, the RTEBS can perform actions even while a step is running.  This supports the ability to abort steps if necessary.  The RTS does not have this structure.  Third, the RTEBS can disconnect and reconnect to the host.  While RTEBS is disconnected the RT-side still run the sequence.  The RTS must remain connected, and does not have the ability to reconnect once the connection is broken.



A RT Sequencer Architecture can increase the productivity of the real-time targets in test engineering applications.  The demonstrated architectures provide for a scalable and maintainable solution without affecting the determinism of the steps significantly.  Communication between the user and the real-time target is handled entirely by the host program and target program, allowing developers to focus on individual steps.



You can download the Real-Time Sequencer Example Program from here.

You can download the Real-Time Event-Based Sequencer Example Program from here.



This paper was created by the NI AE Specialist group.  You can give us feedback by posting questions and comments through the Real-Time Sequencer Feedback and Questions.

We do not regularly monitor Reader Comments posted on this page.

Back to Top

Bookmark & Share


Rate this document

Answered Your Question?
Yes No