A Real-Time Sequencer Architecture for LabVIEW
PrintOverview
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 is an example architecture of how to facilitate real-time sequencing, while retaining real-time event response and closed loop control systems.
Table of Contents
Background
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 Windows 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 (stays at 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
- Allow user to determine which steps to run and the order to run them
- 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
Implementation
The following is an example architecture for a real-time sequencer application. Each portion of the code was written to achieve the characteristics described in the Theory of Operation. Before the examples 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 – Host.vi). 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 RT Sequencer
In contrast to the Host program architecture, the RT Sequencer Target program (RT Sequencer – Target.vi) 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, which are then forwarded to the host. 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 – Target.vi.
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 – Host.vi”. The file location can be changed within “RT Sequencer – Host.vi”.
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 - Target.vi 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- Host.vi".
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- Target.vi" 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- Target.vi" being loaded into memory this VI will do nothing.
Advanced VIs: There are four 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.
Conclusion
An RT Sequencer Architecture can increase the productivity of the real-time targets in test engineering applications. The demonstrated architecture provides 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.
Download
You can download the Real-Time Sequencer Example Program from here.
Reader Comments | Submit a comment »
Legal
This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although technical support of this tutorial may be made available by National Instruments, the content in this tutorial may not be completely tested and verified, and NI does not guarantee its quality in any way or that NI will continue to support this content with each new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF USE (http://ni.com/legal/termsofuse/unitedstates/us/).