Some RT targets include an embedded user interface you can use to view and control the front panel of RT target VIs. However, other RT targets supported by the LabVIEW Real-Time Module are designed to run headless, with only a basic output display. For RT targets that do not support the embedded user interface, creating a graphical user interface (GUI) for a LabVIEW Real-Time Module application requires a distributed computing approach. If your real-time application needs a user interface and you cannot use the embedded UI, 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.

Avoid Front Panel Objects, Methods, and Events

When developing an RT VI for a target that does not support the embedded UI, you can use front panel controls and indicators for debugging, but you cannot use the front panel of an RT VI as the user interface of your final stand-alone RT application. When you deploy a VI as a stand-alone RT application, LabVIEW removes the front panel of the VI, including all objects, properties, methods, and events associated with it. Although event-driven programming can be a powerful user interface design pattern for many LabVIEW VIs, you cannot use the typical LabVIEW event-driven UI design pattern for a VI that runs on an RT target. However, you can use the event-driven design pattern to create a user interface VI running on a host computer that uses a networking protocol to communicate with the RT target VI.

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-Published Shared Variable Easy to program, publishes to many computers at once, safe to include in deterministic loops when the RT FIFO is enabled, integrates with industrial protocols High CPU overhead, proprietary, requires the Shared 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, native LabVIEW data type support Single writer — single reader, unidirectional data transfer, non-deterministic, proprietary
Starting point for custom protocols such as STM, available at ni.com 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
Dynamic control of RT VIs VI Server Good abstraction for local or remote control of VIs and other LabVIEW constructs Low speed, proprietary
Web-based user interfaces, integration with standard Web technologies Web Services Web standard, client connection does not require LabVIEW High overhead, programming difficulty, need to create a thin-client in a non-LabVIEW language

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-published shared variables
Command (many to one) Sending user interface value changes from multiple Web clients to an RT target Web services VIs or network-published shared variables
Monitor (one to one) Using a host PC to monitor latest values published by an RT target Network-published shared variables or STM
Monitor (one to many) Using multiple Web clients to monitor latest values published by an RT target Web services VIs or network-published shared variables
Monitor (many to one) Using a host PC to monitor latest values published by multiple RT targets Network-published shared 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
Note Refer to the NI LabVIEW for CompactRIO Developer's Guide, available at ni.com, for an example of using network-published shared variables to send and receive commands.

Creating a Dedicated Interface

For applications that require a single, dedicated user interface terminal, use the Network Streams functions to stream data continuously and to send commands. Use network-published shared variables or the Simple Messaging Reference Library (STM), available at ni.com, to monitor the latest value of each variable. Use the STM library to send commands to the RT target.

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-published shared variables to send commands and monitor latest values. For maximum expandability in large applications, you can find, read, and write shared variables programmatically.

Refer to the RT FIFO Variables - networked.lvproj in the labview\examples\Real-Time Module\RT Communication\RT FIFO Variables directory for an example of using Shared Variables to publish user interface data.

Note The LabVIEW Datalogging and Supervisory Control (DSC) Module includes additional features you can use to create advanced SCADA applications.

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 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. Not all real-time targets support polling mode.

Sending Commands

To minimize latency, follow these guidelines:

  • Use an efficient networking protocol, such as UDP, TCP, or Streams.
  • Send each command as soon as possible. For example, you can use the Flush Stream function to send a command over the network immediately after writing the command.