From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
To download NI software, including the products shown below, visit ni.com/downloads.
The Real-Time Test reference design consists of three high level components. The RTT Engine component executes the RT test profiles by generating different stimuli and analyzing the DUT’s response. The test executive component is responsible for automating the test, analyzing the results, and displaying a comprehensive report to the operator. The host component is used to monitor variables as well as to access and display parameters and signals as the test is performed.
The communication between the three subsystems occurs via TCP/IP, UDP or Active X, depending on which two systems are communicating. The following diagram shows the communication channel used and what type of data is being passed.
The purpose of the RT Test Engine is to deterministically execute the test profile used to verify the functionality of the DUT. The Real-Time Test Engine can be broken into smaller sub components according to their specific function. These smaller sub components are a host communication server, an application command server, a real-time profile sequencer, a data logger, a command dispatcher and a base rate loop. These sub components will be discussed below.
Each sub component is a queued state machine. This allows the test executive to send commands to each process loop within the RTT Engine and control their tasks. Examples of these commands are start, stop, pause, abort, configure, etc. The commands sent by the test executive are received by a dispatcher and then assigned to the correct process through queues. These queued state machines are built on top of the Asynchronous Messaging Communication (AMC) reference library.
The AMC library will be installed as part of this Real-Time Reference Design. To learn more about the AMC, review the link at the end of this document to: Asynchronous Messaging Communication (AMC) Reference Library.
The following diagram shows how the different components interact with each other.
The variable table is a central repository to store and share data among the different loops. The current value table (CVT) is the reference library used in the RTT Engine that plays this role. The CVT consists of functional global variables (FGV) which each contain an array. There is a FGV for each major data type in LabVIEW. Each element in a FGV’s array represents a variable in the system. These different variables are accessible from anywhere in the engine, allowing communication among all the loops.
The CVT is a component that is installed as part of this Real-Time Test Reference Design. To learn more about the Current Variable Table (CVT), review the linked document on: A Current Variable Table for LabVIEW.
The Application Command Server is a queued state machine loop that is responsible for managing functions that affect the entire RTT engine. Configuring system variables and stopping the RTT engine are two example commands.
The RT Profile Sequencer loop is a queued state machine in which every state represents a function or possible step in the test profile sequence. The test profile sequence is sent from the test executive to the RTT Engine via ACM as part of a command and then processed by this loop. Once this loop receives the test profile sequence, it indexes the first profile step and starts execution. Upon completion, the next profile step is executed and so on until the entire test profile sequence is finished and the sequencer goes back into the idle state. It is important to note that each profile step should be designed to not block the RT Profile Sequencer Loop from executing at its specified rate. This allows the test executive to pause, abort, and modify the test sequence, among other things.
This process is responsible for receiving UDP commands from the test executive. Once a command is received, the AMC Dispatcher determines which process the command is intended for and sends that command on the appropriate queue.
The base rate loop runs the dynamic portion of the system. This loop consists of two pieces: the IO Scan Engine and the Control/Simulation loop.
Since this loop is responsible for timing the real-time test, this loop executes the IO Scan blocks and the dynamic block
RT IO Scan
The IO Scan component is responsible for reading the physical response from the DUT, updating the variable table, and vice versa by writing the new stimulus value to the hardware.
Control/Simulation
Depending on the type of real-time test that needs to be done, this control/simulation piece can be developed in different ways. For example, in the hardware in the loop (HIL) or rapid control prototyping (RCP) case, the system model can be generated using LabVIEW Simulation or LabVIEW SIT. If it is an engine test scenario, then the LabVIEW Control Design toolkit can be used to implement the control algorithm. Sometimes the RT Profile Sequencer Loop can replace this block altogether.
These two pieces operate in the following order. First, hardware inputs are read and the variable table is updated with the new values. Then, the base rate loop runs one step of the control or simulation algorithm. Last, the hardware outputs are updated. All this occurs within one iteration of the base rate loop.
The data logger loop reads the variables from the variable table and writes their values to a file. The CVT Data Logger (CDL) is the library in the RTT Engine responsible for performing this task. Because the data logger is implemented as a state machine, it can be started, and stopped by the test executive at any time.
The CDL is installed as part of the RTT Engine. To learn more about how the CDL has been implemented, review the document about: CVT Data Logger (CDL) Reference Library.
The host communication server is the process responsible for passing data from the RTT engine to the host and vice versa. The CVT Client Communication Server or CCC is the library responsible for this task. This library mirrors the variables between the local and remote variable table by sending its values over TCP/IP.
The CCC gets installed as part of this reference design. To learn more about the CCC, refer to the link at the end of this document on: CVT Client communication (CCC) Reference Library.
Just like the RTT Engine, the Host Program can be broken into smaller components. The following diagram shows the different components and how they communicate among each other.
The real-time profile editor is a tool used to create a RT test profile sequence that will be executed in the RT Test Engine. NI TestStand is test executive software that can call this tool directly. The steps created by this tool are deployed to the RTT Engine using the RT Command Client VIs.
NOTE: This tool has not been implemented yet. Therefore, the test profile has to be configured manually as an array of clusters.
The real-time host is used as a user interface in which certain parameters and signals can be monitored while the test executes. This user interface reads and writes to a local variable table (CVT) that is mirrored for the selected variables using the CVT Communication Client (CCC). This program also allows a user interface to update the test executive with test results and the status of the RTT Engine so that the test can be aborted or modified. This communication between the RT Host and the test executive is done through Active X.
The test executive is the part of the architecture that is responsible for automating and managing the entire test or tests by sending the commands to the RTT Engine to configure, run, stop, etc. the different components in the RT system. It is also responsible for deploying test profile sequences, analyzing results and generating reports.
The test executive uses a set of VIs that function as an API to send commands to the RTT Engine named RT Command Client VIs. These VIs can be used from a LabVIEW built test executive or from TestStand. These VIs are implemented using the ACM library. For more information on the ACM library review the document linked at the end of this document.
TestStand’s built-in tools are used to analyze and evaluate the test results in these types of applications to reduce programming time and to leverage the reporting capabilities of the product. Once the test is done, TestStand evaluates the test results received from the RTT Engine and generates a test report.
This tool is used to create and configure the variables that will be used in the system as well as to bind local variables to remote variables. The configuration is stored as an XML file which needs to be transferred via FTP to the RT controller’s root directory where it is parsed by the RTT Engine.
The Test System is broken down into two main subsystems, which are: Host (HMI) and RT Controller (Controller)
Variables that run in the Windows computer are configured under the HMI section. The Host supports two types of variables: Local Variables and the Network Variables. The Local Variables are CVT variables that are used locally on the Host. Network Variables are CVT variables that are used on the local Host VI but also write or read from variables running in the RT Controller (RTT Engine).
Variables that run in the RTT Engine are configured under the Controller section. The controller supports two types of variables, although it could be expanded to more. The first type is Local Variables. Just like the local variables on the HMI, these variables are used in the local system. The second type of variable is the IO Variables. These are the variables that store the data values for any IO channel configured for the test. The IO variables are mapped to hardware I/O by specifying the address to that channel. The hardware address can be obtained from Measurement & Automation Explorer (MAX).
The following image shows how a DAQ Variable is linked to the AI channel 0 under slot 8 of a PXI system.
To learn more about how the Variable Configuration Editor is implemented, go the link under References for Generic Configuration Editor.
The RTT reference design is a framework for testing devices under test (DUTs) in a deterministic and repeatable way which simulates real world conditions. This design can be exemplified with a DC motor control test system. In this example, the DC motor is ran through a speed profile using PID control. Both the speed profile and the PID are executed in the RTT Engine. The purpose of the test is to verify that the motor speed is within a certain range throughout the test. In a real life application, this could be an engine test cell where torque or speed could be controlled while the engine is exercised through a speed profile to test multiple aspects of the engine like vibration, fuel efficiency, etc.
Located at: tce_source_201(DAQ)\TCE Source\TCE
Open the TagConfig.lvproj project and run the TagEditor.vi. The sample configuration file used in this application is located at \RTT Reference Design\TCE files\TCE_ConfigPID.xml.
This configuration file contains the variables used by the example application. To run this example, the binding to the hardware variables and the IP address of the Host computer need to be modified to your setup. To do this go to the UI IP Address variable and update its value to your computer IP Address. Then go to the AI_RotorSpeed and PID_Out variables and replace the address to match your hardware. For example:
The PID_Out variable has as address PXI1Slot8/ao0
Once you have updated the hardware variables and the UI IP Address variable, save the file and transfer it to the root directory of your RT controller via FTP.
The RTT Engine for this example is located at: \RTT Reference Design. The RTT Engine VI is under the RT PXI target in the LabVIEW project. Run this VI before starting any of the Host VIs or test executives discussed below. This VI is design to and should always be left running.
The RTT Engine contains five different processes: the base rate loop, the application command server, the sequencer, the data logger and the host communication server.
This process is responsible for performing the hardware inputs and outputs. This loop waits for the test executive to specify the path to the hardware configuration file that it is used to configure the hardware. Once configured, the base rate loop waits for a command from the test executive to start running. Because this process is a state machine, it can be interrupted by the test executive at any time to update hardware configuration, stop IO, etc.
Once started, the base rate loop reads from the hardware and updates the variable table. Then it executes the dynamic system (PID control in this example) and finally it uses the new variable table values to update the hardware outputs.
This process is the loop responsible for deterministically executing the test profile sequence. This process, just like the rest of the RTT Engine, is a queued state machine that waits for the test executive to send commands.
Once this loop receives the test profile sequence, it indexes the first profile step and starts execution. Each profile step should be designed to not block the sequencer from executing at its set rate. A wait function is a good example. Typically, a wait function of 60 seconds would block the sequencer loop from executing for 60 seconds. This is not ideal as now the sequencer can’t receive commands from the test executive for this duration. Instead, a wait function which is simply checking if time has elapsed should be implemented. Then, the sequencer can continue to execute at its correct loop rate and receive commands from the test executive while still having the necessary functionality. Once the first profile step has finished execution, the next profile step is executed and so on until the entire test profile sequence is finished and the sequencer goes back into the idle state.
This process is responsible for executing tasks that affect the entire RTT Engine. These include configuring the system variables and stopping the RTT Engine
Just like the other processes this one is also made of a queued state machine that receives the commands from the test executive.
This process is responsible for storing variable values into a file. The CVT Data Logger (CDL) reference library provides a basic API to configure, monitor and control the data log process.
This library reads the CVT variables and writes the values to a file through a set of FIFOs. The file format used by the CDL is TDMS, allowing the data logger to categorize the different variables based on their data type.
This process is responsible for sharing the CVT values between the Host and the RTT Engine. The CVT Client Communication (CCC) server is the library that provides the API to perform this task.
This process is responsible for receiving UDP commands from the test executive. Once a command is received, the AMC Dispatcher determines which process the command is intended for and sends that command on the appropriate queue.
Two different reference applications are attached to this document. The difference between the two applications is that one uses TestStand as the test executive and the other one uses LabVIEW.
To use TestStand as the test executive, open the RTTest.seq sequence file located at \RTT Reference Design. To run this example the only thing that needs to be done is change the IP address under the Init Cmmd Loop Action Step, to match your RT Controller and make sure the RTT Engine is already running.
In this example, TestStand is responsible for opening the session with RTT Engine, sending the test configuration parameters, and sending all process commands.
The sequence first configures the variables that will be used in the test by passing the path to the XML configuration file that was previously created using the Variable Configuration Editor and transferred via FTP to the RT system as part of a command to the RTT Engine. Then, the data logger is started and the base rate is configured. A user interface (discussed below) is opened for the user to view the test. Once this is done, a real-time test profile is deployed to the RTT Engine and then executed by the RT Profile Sequencer.
While the RT test profile is being executed, TestStand waits for the “TestDone” variable to be True. In this application example, the last step in the RT sequence is “Set TestDone to True”. This variable is set by the engine once it gets to this final step. The Host then reads this variable and updates a global variable within TestStand through Active X that awakes it from the wait state and makes it continue with the rest of the TestStand sequence.
Once the RT profile is done, TestStand evaluates the maximum RPMs achieved by the motor, and performs a limit test. TestStand then sends the command to stop the data-logger and disconnects from the RTT Engine.
After that, TestStand generates a report with the value for the variable used in the limit test and the results of the test (I.e.: pass/fail).
The Host VI is located at: RTT Engine and Config\RTT Reference Design and is called RTT-Host(TS).vi. Note: This VI can only be ran when called by TestStand.
As mentioned above, the host VI is launched in a different execution thread as an asynchronous process through a sequence call. It is responsible for displaying the values for the set point and actual motor speed on a graph while the test occurs as well as to set the PID gains.
Once the test is done, this VI reads the TestDone variable from the CVT and writes its value to a global variable within TestStand using Active X. Using this same method it passes the max RPM variable value to TestStand so that TestStand can evaluate this number in a limit test.
As an alternative to TestStand, LabVIEW can be used to perform the test executive’s functionality in the Host VI. This example can be found at: \RTT Reference Design\RT-Host.vi and can be accessed by opening the Real-Time Test(RTT).lvproj and opening the RT-Host.vi located under “My Computer”. The same RT Command Client API VIs that was used as a code module in TestStand can be used from the Host VI to send the necessary commands to the RTT Engine.
This is the only difference from the other host VI mentioned above.
Example code from the Example Code Exchange in the NI Community is licensed with the MIT license.
