Understanding Communication Options Between the Windows HMI, RT Processor, and FPGA

When programming a RIO (Reconfigurable I/O) product such as a CompactRIO, sbRIO, or myRIO, there are three distinct components to be aware of:

• Human-Machine Interface (HMI) 
• Real-Time (RT) processor
• Field-Programmable Gate Array (FPGA) 

The HMI, sometimes referred to as the "Host", provides the user with a graphical user interface (GUI) for monitoring the system’s state and setting operating parameters. Using an HMI is optional since RIO products can be programmed to run headlessly and some can connect to an embedded user interface directly, but when HMIs are implemented, they can come in the form of a Windows desktop computer, a tablet, or a Touch Panel Computer, for example. The RT processor runs the main Real-Time program, and is what allows the RIO to reliably execute programs with specific timing requirements. The FPGA is a reprogrammable silicon chip and is at the center of the embedded system. The FPGA connects the chassis I/O directly to the RT processor without going through a bus, which allows for very low control latency for system response compared to other controller architectures. Because the FPGA runs its code in hardware instead of software through the LabVIEW FPGA module, its speed and reliability are often used for applications using high-speed buffered I/O, fast control loops, or custom signal filtering. The HMI, RT, and FPGA each have their own distinct locations in the LabVIEW project where they are programmed, and there are differing methods of communication within each component and between each component. This White Paper addresses those methods and their differences. Below is a diagram that shows how these components interact, given that a PC is used as the HMI.

^{Figure 1: Embedded System Components.}

Before diving into the different communication methods, it is important to understand how the data is transported from the physical input and output ports on the RIO target to the embedded system components. When using a CompactRIO, there are three ways to access I/O:

1. For Real-Time (NI-DAQmx) mode, the data is read through the processor via NI-DAQmx VI’s.
2. For Real-Time Scan (IO Variable) mode, the data is sent through the FPGA, but is ultimately accessed on the processor by dragging and dropping IO Nodes to the Real-Time VI.
3. For LabVIEW FPGA mode, the I/O is read from directly from within the FPGA by dragging and dropping IO Nodes to the FPGA VI.

The programming mode is indicated by the text next to the module in the LabVIEW project.

The figure below shows how each mode sends the I/O data through a unique path with no overlap.

^{Figure 2: Accessing I/O.}

Note that not all CompactRIOs support programming with NI-DAQmx. Refer to the documentation to find which models of CompactRIO support programming with NI-DAQmx.

When programming a RIO target, it is important to be aware of three communication paradigms: 

• Tag 
• Stream
• Message 

The tag type, sometimes called the current value type, is used to communicate latest values. One example of a tag is a control set point given by the operator through an HMI. This tag does not need to communicate all historical data of the control set point, but simply the latest value that the operator inputs. Additionally, the tag transmission is not guaranteed, since the historical data of all previous set points is not needed. This aspect of non-guaranteed transmission is sometimes referred to as "lossy" communication. 

By contrast, the stream type uses buffering to transfer every data point, where throughput is more important than latency. One use case for stream communication is when transferring all temperature data through the FPGA to the RT processor to be logged to a file. In this case, the historical data is necessary, so the transmission of every data point is guaranteed. This aspect of guaranteed transmission is referred to as "lossless" communication. 

The last communication type, message, is used when the delivery of the information needs to be guaranteed and with low latency. An emergency stop command is one example of a message communication type. In the following tables, the communication options will be specified as a Tag, Stream, or Message type. In most cases, a communication option that can support the stream type will also support the message type due to the guaranteed delivery aspect of that option. Below is a table that summarizes these communication types. 

^{Table 1: Communication Types.}

It should be noted that while this guide covers a broad range of communication options, to stay concise, it is not intended to cover every potential combination or use case. The most common and recommended solutions are presented. Configurations with known limitations are noted.

The following table provides the highest-level overview of the different communication options between the HMI, RT processor, and FPGA. Please refer to the more detailed tables when applicable. Click on the individual links to find more detailed information on that communication option.

Table 2: Main Communication Table.

The following table provides an overview of the communication options available when communicating between different processes on the RT program. The table is divided into the options available when communicating between a deterministic loop, such as a timed loop, and a non-deterministic loop, or communicating between a non-deterministic loop and another non-deterministic loop. It is best practice to only have one deterministic loop per core running on the Real-Time processor to avoid priority conflicts.

^{Table 3: RT Interprocess Communication.}

The following table provides an overview of the different communication options available when communicating between a Real-Time program and an HMI running on a Windows PC. The table also lists out whether the communication option supports communication between one or multiple RT processors or HMIs. It should be noted that with our CompactRIO targets running 64-bit NI Linux Real-Time operating system, there is an Embedded UI option that allows the front panel of the Real-Time VI to be displayed. In this case, there is no need to program an HMI. There are other options outside of a Windows PC and using the Embedded UI, such as using a component display, a web HMI, or a Touch Screen Monitor, for example. Those options have their own communication considerations that are not covered here.

^{Table 4: RT/HMI Communication.}

The following table provides an overview of the communication options available when communicating between different processes on an FPGA. There are methods of communicating between two different FPGAs, but those options are not covered here. 

^{Table 5: FPGA Interprocess Communication.}

• NI LabVIEW for CompactRIO Developer's Guide
• FPGA Fundamentals
• Displays and Data Visualization With CompactRIO: The Ultimate Multipurpose Controller