Network the User Interface
- Updated2023-02-21
- 4 minute(s) read
RT targets supported by the LabWindows/CVI Real-Time Module are designed to run headless, with only a basic output display. Creating a GUI for a LabWindows/CVI Real-Time Module application requires a distributed computing approach: display the GUI on a general-purpose operating system and use a remote communication protocol to transfer data between the RT target and the GUI device.
Because supported network protocols are non-deterministic, you must separate the remote communication code from the deterministic code in your application. If data you are transferring originates in deterministic code, you must pass the data from your deterministic code to the code that implements the remote communication.
Use the Right Networking Equipment
It can be tempting to use the networking equipment you already have or select the cheapest equipment available. However, the quality of commercial off-the-shelf networking equipment varies widely, so take the time to decide what type of networking equipment is most appropriate for your application. For some applications, lower-quality networking equipment is adequate. However, for applications that depend on network throughput, latency, or reliability, high-quality networking equipment can be crucial.
Use the Right Networking Protocol
The following table summarizes the advantages, disadvantages, and common use cases of the most common remote communication protocols for transferring data between RT targets and GUI devices:
| Use Case | Protocol | Advantages | Disadvantages |
|---|---|---|---|
| Monitoring latest values | Network Variables | Easy to program, publishes to many computers at once, integrates with industrial protocols | High CPU overhead, proprietary, requires the Network Variable Engine |
| Streaming data between an RT target and a host computer, sending commands to an RT target | Network Streams | High throughput, lossless, automatic connection management | Single writer — single reader, unidirectional data transfer, proprietary |
| Starting point for custom protocols | TCP or UDP | Efficient CPU and memory usage, flexible, standard protocol for interoperability | Programming difficulty, string data only, no built-in method to identify data |
The following table presents networking protocol recommendations for the most common RT GUI use cases:
| Use Case | Example | Recommended Protocols |
|---|---|---|
| Command (one to one) | Sending user interface value changes from a host PC to an RT target | Network Streams functions |
| Command (one to many) | Sending user interface value changes from a host PC to multiple RT targets | Network variables |
| Command (many to one) | Sending user interface value changes from multiple clients to an RT target | Network variables |
| Monitor (one to one) | Using a host PC to monitor latest values published by an RT target | Network variables |
| Monitor (one to many) | Using multiple clients to monitor latest values published by an RT target | Network variables |
| Monitor (many to one) | Using a host PC to monitor latest values published by multiple RT targets | Network variables |
| Stream (one to one) | Sending a continuous stream of data from an RT target to be logged on a host PC | Network Streams functions |
| Stream (one to many) | Web video server | TCP or UDP |
| Stream (many to one) | Web video client | TCP or UDP |
Creating a Dedicated Interface
For applications that require a single, dedicated user interface terminal, use the Network Streams Library functions to stream data continuously and to send commands. Use network variables to monitor the latest value of each variable.
Creating a SCADA Interface
For supervisory control and data acquisition (SCADA) user interfaces typically involve one or more user interface terminals interacting with numerous embedded controllers. For SCADA applications, use network variables to send commands and monitor latest values.
Refer to the NetworkVariableRT.prj in the \samples\realtime\NetworkVariableRT directory for an example of using network variables to publish user interface data.
Use the Right Payload Sizes
Payload size is the amount of data you send over the network at once. Throughput and CPU efficiency increase as payload size increases. However, waiting to accumulate a large amount of data before sending the data increases the latency of your network transfers. When streaming data, the goal usually is to maximize throughput. By contrast, when sending commands, the goal usually is to minimize latency.
Streaming Data Continuously
To maximize throughput, follow these guidelines:
- Use an efficient networking protocol, such as UDP, TCP, or network streams.
- Accumulate data before sending the data over the network. By sending data in payloads of 1 KB (1024 bytes) or a multiple thereof, you can achieve high throughput and low CPU overhead while maintaining reasonable latency for most applications. However, if you need to minimize latency while streaming data, use a smaller payload size.
- Consider switching to polling mode for Ethernet packet detection. The Packet Detection setting of an RT target is on the Network Settings tab, under the More Settings pull-down menu in NI Measurement & Automation Explorer.
Note Polling mode provides lower jitter than interrupt mode. However, the CPU overhead required by polling mode decreases the maximum throughput you can achieve.
Sending Commands
To minimize latency, follow these guidelines:
- Use an efficient networking protocol, such as UDP, TCP, or network streams.
- Send each command as soon as possible. For example, if you are using network streams, you can call the CNSFlush function to send data immediately.