Viewpoint News, July 2011

Part 4: RIO Process Communications Reference Designs in an Embedded LVRT Application

by James Campbell - jac@viewpointusa.com

We wrap up the series on embedded applications with a closer look at some Reference Designs for inter-process communications.

The app architecture for the RIO platform sketched out last month has three components: FPGA, RT, and Client PC. Data and state is shared between these parts by using FIFOs for lower level code and TCP between the RT layer and the PC. The TCP-based communications should be based on some standardized code, called Reference Designs. Viewpoint developed such code years ago for our project work. Now, NI has some tools on their website as free downloads that are very similar to ours. You should use them too.

Ethernet-based Communication

Overview

There are two types of communications that typically happen in an embedded app. One mode is between a host (or server) PC and the RIO. The other mode is between various LabVIEW loops (e.g., processes) in the same RIO or between multiple RIOs. NI has two libraries of VIs for these types of communications. For the first mode, Simple TCP Messaging (STM) is used. For the second mode, Asynchronous Message Communication (AMC) is used.

STM Details

The STM is the simpler mode of the two and encapsulates the actual data transmission layer enough that TCP/IP, UDP, or serial can be used, based on the type of connection reference (TCP, UDP, or VISA) wired into the polymorphic VIs. While these VIs are not just for Ethernet, they are often used that way.

The STM VIs are typically used for communications between two devices. For example, the TCP flavor needs an IP address; on the sender side it’s the receiver address and vice versa. Once configured, these two devices can send messages to each other and receive responses. More specifically, this two-way communication is between two TCP ports, so there can be many connections between the same devices. Note that there is no LabVIEW queue here, so your code needs to be listening for responses in a timely fashion.

Since the receiving device doesn’t know the message contents that are being sent, some “header” info needs to be included prior to the data to describe the data packet that follows. In the early years, Viewpoint sent either integers or strings to describe the data packet. The STM couples these two approaches by using an array of strings for all the names of the various packet types and then, when a certain message goes out, translates the name into an integer index which is prepended onto the data packet. This method increases message efficiency (less bytes are sent) and still allows readability in the receiving code. Of course, a first step requires you to send this array of names to the receiver so the recipient knows how to translate the index numbers back to the names. NI calls these names “metadata”.

Note that you can use STM in a LabVIEW app on the RIO and some other programming language on the PC. You’ll have to develop an equivalent of the STM in the other language, but this effort is not onerous. We’ve done it with C++ and C#. If you stay with LabVIEW data types, keep them simple because, otherwise, the parsing of flattened strings will be needed.

However, for the past few years we simply send XML data as the packet and use XML tools to rip apart the data packet. With GigE and good XML tools, the transmission is very fast and the XML parsing is fairly easy. Note that XML tools are now starting to appear in LabVIEW but, in my opinion, XML DOM is still the best. See http://msdn.microsoft.com/en-us/library/aa468547.aspx for details. DOM is part of Windows and is called in LabVIEW via ActiveX or COM methods. Since LabVIEW 8.6, obtaining a reference to a DOM object is found in the menu Programming>>File I/O>>XML>>XML Parser.

For more details on using the STM, see http://zone.ni.com/devzone/cda/tut/p/id/4095.

AMC Details

The AMC can do all that STM can do and more. The AMC adds LabVIEW queues to the basic communications message handling. There is more overhead when moving data around with the AMC than the STM. So, as NI suggests, AMC is better for infrequent, asynchronous messages. You will get better performance from the STM or basic LV queues.

However, the AMC is a more encompassing architecture for sending and receiving data between different parts of your application, whether in the same loop, different loops on the same machine, or different loops on different machines. Multiple named queues can be established so you can target messages to specific portions of your application, equivalent to what you might do with STM by choosing specific ports for communicating to explicit parts of your application. But you can setup different ports too.

Besides allowing multiple queues, the AMC sends data over the Ethernet to remote machines via UDP, so no connection needs to be created prior to use and several receivers can be listening at once (according to standard UDP behavior). The remote receiver must run a Dispatcher VI to listen to the chosen UDP port, figure out which of the many possible queues the message is intended (based on the Receiver Process info in the data packet), and push the message data into that queue.

Note that supporting AMC on a PC will be more challenging than STM. Of course, it can be done, but there is much to code and it will need to support some type of queuing mechanism.

For more details on using the AMC, see http://zone.ni.com/devzone/cda/epd/p/id/6091.

Embedded Diagram

The figure below appeared last month to show the basic parts of an embedded app. This time it is annotated with some possible uses of STM and AMC. Modify to your tastes.

Conclusion

Communications with other computers or between processes within the same application are integral to any embedded application. The figure above indicates some data-passing modalities for the standard parts of an embedded app. Beyond the lower-level, built-in components of LabVIEW (e.g., FIFOs and queues), Ethernet, UDP, and other communication mechanisms need higher-level support that LabVIEW does not supply as purchased. So, if you don’t have your own communications tools for these mechanisms, you can start using the STM and AMC Reference Designs libraries from NI. These tools are not difficult to incorporate and they are free. The challenging part is deciding the data you need to pass around!