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

Overview

This paper identifies the different options for communicating between a Human-Machine Interface (HMI) running on a Windows machine, the Real-Time processor, and the Field Programmable Gate Array (FPGA) when programming targets such as the CompactRIO, Single-Board RIO, or myRIO. Depending on the application requirements, multiple options will be available. This guide organizes these options in a clear way, so a well-informed decision can be made before architecting code.

Contents

Review of Embedded System Components

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.

 

Accessing I/O

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.

Tag, Stream, and Message

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. 

 

Communication TypeFundamental FeaturesOptional FeaturesPerformance
TagCurrent value only, read periodicallyDynamic lookup, group managementLow latency, high-channel count
StreamBuffering, blocking (timeout)Multilayer bufferingHigh Throughput
MessageBuffering, blocking (timeout)Acknowledgement of data transferLow latency

 

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.

 

Summary of Communication Options

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.

 

From\ToHMIRTFPGA
HMI

Tag

Stream

Message

     See Table 4: RT/HMI CommunicationThe same methods of communication that are used to communicate between FPGA and RT processor can also be used for communicating between the FPGA and HMI. However, this is less common because determinism is not guaranteed once communication occurs to the HMI over Ethernet. 
RT

   

See Table 4: RT/HMI Communication

    

See Table 3: RT Interprocess Communication

Tag

Stream

FPGAThe same methods of communication that are used to communicate between FPGA and RT processor can also be used for communicating between the FPGA and HMI. However, this is less common because determinism is not guaranteed once communication occurs to the HMI over Ethernet. 

Tag

Stream

  

  See Table 5: FPGA Interprocess Communication

Table 2: Main Communication Table.

 

RT Interprocess Communication

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.

 

Communication TypeDeterministic Loop to Non-Deterministic LoopNon-Deterministic Loop to Non-Deterministic Loop
Tag
Stream, Message

Table 3: RT Interprocess Communication.

 

RT/HMI 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.

 

Communication TypeCommunication OptionNumber of RT Targets: Number of HMIs
TagNetwork-Published Shared Variable1:1, 1:N, N:1
TCP/IP1:1
UDP1:N or N:1
Web Services1:1, 1:N
Stream, MessageNetwork Streams1:1
TCP/IP (message only)1:1

Table 4: RT/HMI Communication.

FPGA Interprocess 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. 

 

Communication TypeCommunication OptionCommon Use
TagLocal/Global VariablesShare Latest Data
Memory ItemsShare Latest Data
Register ItemsShare Latest Data
Stream, MessageHandshakesEstablish parameters for continued communication
FIFOs (Flip-Flop)

Transfer buffered data

(FIFOs < 100 bytes)

FIFOs (Look-up Table)

Transfer buffered data

(100 bytes ≤ FIFOs ≤ 300 bytes)

FIFOs (Block Memory)

Transfer buffered data

(FIFOs > 300 bytes)

*Upper limit of available block memory is specified by FPGA target

Table 5: FPGA Interprocess Communication.

Was this information helpful?

Yes

No