Many real-time applications involve some combination of the following tasks:
For each of these tasks, there are recommended architectures that have proven effective for a wide variety of applications. In most cases, it is best to use these architectures as a starting point rather than attempting to create each task from scratch.
For some tasks, there are several recommended alternatives. Generally, these architecture options are subject to tradeoffs along the dimensions of speed, efficiency, expandability, and ease of programming. In these cases, we outline the tradeoffs to help you decide which option best fits your application requirements.
Initialization Routine
Most LabVIEW RT applications benefit from an initialization routine to complete non-deterministic preliminary tasks before running deterministic loops.Common initialization tasks include:
- Preallocating arrays
- Clearing old buffered data, such as network published shared variable data
Shutdown Routine
Use a shutdown routine to safely and cleanly terminate your LabVIEW RT application. Common shutdown tasks include:
Process Control
Process control involves controlling the output of a specific physical process. Most real-time applications involve one or more process control tasks. Typically, these are the most time-sensitive and therefore highest-priority tasks in the application. The two most common approaches to process control are:
- PID Control
- Model Predictive Control
Most process control systems fall into one of the following categories:
However, a hybrid application can include elements of discrete, batch, and continuous process control.
Statistical Process Control
Statistical Process Control (SPC) involves the use of control charts to monitor a process. Much of its power lies in the ability to monitor both process center and its variation about that center. By collecting data from samples at various points within the process, variations in the process that may affect the quality of the end product or service can be detected and corrected, thus reducing waste as well as the likelihood that problems will be passed on to the customer. It has an emphasis on early detection and prevention of problems.
Signal Processing
LabVIEW includes a rich library of VIs and functions on the Math & Signal Processing palette. You also can use textual MathScript functions for signal processing either in LabVIEW RT or in LabVIEW FPGA. However, due to the processing-intensive nature of these VIs and functions, it is important to benchmark and streamline signal processing code before deploying your application.
Data Logging
Data logging involves writing data to a long-term storage device such as a hard drive or a USB flash drive. For high speed local data logging, write to disk in multiples of 512 bytes. Minimize data overhead to maximize the amount of data you can log before filling up the drive.
Inter-Process Communication
Inter-process communication involves passing data between asynchronous processes such as parallel loops. Common inter-process communication tasks include:
Inter-Process Data Sharing
Add text here.
Inter-Process Messaging
Add text here.
Inter-Process Synchronization
Add text here.
Inter-Process Handshaking
Add text here.
Inter-Device Communication
Inter-device communication involves passing data between hardware devices. Common examples of hardware devices that need to communicate with each other include:
- RT / RT
- RT / FPGA
- FPGA / FPGA
- DAQ / DAQ
- RT / CAN
Common inter-device communication tasks are essentially the same as inter-process communication tasks:
Inter-Device Data Sharing
Add text here.
Inter-Device Messaging
Add text here.
Inter-Device Synchronization
Add text here.
Inter-Device Handshaking
Add text here.
Networked Human Machine Interface
Because of the headless operation of RT targets, it is common for LabVIEW RT applications to interface with a networked human machine interface (HMI) running on one or more external computing devices such as desktop PCs or touch panel computers. Common HMI tasks include:
Data Streaming
Data streaming involves sending a large amount of data from one computing device to another in a relatively constant stream. For most streaming use cases, throughput is more important than latency. Therefore, for data streaming it is generally best to wait for a large amount of data to be ready before sending the data so that you can maximize throughput over the network. Use one of the following architectures for data streaming:
Messaging
Command response involves sending and receiving messages, commands, or procedure calls over the network. Use one of the following architectures for network messaging:
Direct Versus Published Communication
It is important to distinguish between direct and published network communication and to use the most appropriate form of communication for the task at hand.
Direct network communication involves a single connection between two networked computers. A direct network connection involves less overhead than network publishing, so you should use network publishing only when you need to publish the same data to multiple computing devices.
Network publishing involves sending data over a network to be read by multiple subscribing computers connected via LAN or internet. To maximize throughput and minimize latency when publishing, bundle data into large packets (4k+) before transferring over the network. Use raw TCP or UDP for minimum overhead. Use network-published shared variables for ease of programming. Use the dynamic variable API for maximum scalability in large applications.
Watchdog
A watchdog is a hardware timer used to detect software hangs and initiate a safe response. Including a watchdog can increase the robustness of your system.
