|Download Help (Windows Only)|
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.
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.
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.
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:
|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|
|Deterministic communication between RT targets||Time-Triggered Shared Variable||Deterministic execution, deterministic data transfer||Requires a dedicated secondary Ethernet network, limited RT target support|
|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.|
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.
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.|
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.
To maximize throughput, follow these guidelines:
|Note Polling mode provides lower jitter than interrupt mode. However, the CPU overhead required by polling mode decreases the maximum throughput you can achieve.|
To minimize latency, follow these guidelines: