Network Communication Methods in LabVIEW

Applications normally involve a variety of systems, such as data acquisition system, controllers and hosts, that must exchange information, often over Ethernet. While one may be reading data from peripheral instruments, such as sensors – camera for instance, others may be processing data and giving  results or transferring to a central data system. There are several methods available to accomplish these tasks. In this post, I would like to give some fundamentals about common communication models as well as networking protocols commonly used. As a result, designers can choose an appropriate way for their application.

I – Models of communication

There are several models used for communication that can configure in different ways, for example, (1:1) one host and one target, (N:1) or (1:N). However, in most applications, there are three models commonly used, which are:

- Command or message-based communication

- Process Data Communication

- Streaming/Buffered Communication

With the first model, there are two participants are involved, which are client and server aCommand-based communication block diagramapplications. The organization of the command-based design pattern can illustrated as beside.

In host computer, there are the following parts:

  • Command/Parameter Sender loop
  • Data Receiver loop

In general, the command/parameter sender loop actions can be driven by any source, for instance, User Interface -UI. On the other hand, The Data Receiver loop is responsible for receiving and processing each incoming message from the target. For example, the Data Receiver simply displays the data, do post-processing, or performing some analysis, etc.

In the target, some parts may be included:

  • Command Parser
  • Medium Priority Task(s)
  • High Priority Task

The Command Parser waits for commands from the host, interprets them and routes the incoming command parameters to the appropriate loop. However, Medium Priority tasks might be signal processing, sending data to the host via TCP/IP or logging data to disk. Since Medium Priority tasks and the Command Parser are not deterministic, we can use various methods of data sharing between them, such as Queues, Local Variables, Functional Globals, etc. Most importantly, it is the High Priority Task loop, which represents the deterministic part of the application. Typical deterministic tasks include data acquisition, closed-loop control or simulation model execution.

Process Data Communication

Process data communication usually consists of current values being sent periodically between machine. Each data transmission does not need to be guaranteed because the target is always interested in the latest value, not in buffered values. This type of data transfer can be used between embedded controllers and may need to run at high speeds.  However the most common use of process data communication is for updating. A good rule of thinter-process communicationumb is that numeric displays should be updated at rates no faster than 1-2 Hz, and for graphical displays, 30 Hz provides smooth updates.
Furthermore, it is important to pick the right architecture depending on how and when our applications will need to communicate with each other. There are some common architectures, which are often overlapped:
- Producer/Consumer Architecture: In this architecture, one application produces data while the other waits for data and ‘consumes’ it. For example, one could be producing the data by reading from a data acquisition device, while another application consumes it to run a report on the data, or vice verse.
- Remote Procedure Architecture: This architecture is similar to calling a function that may return data, except that the function is run on a separate process.
- Bi-Directional Communication Architecture: In this architecture, both applications can send commands to each other and can return data to each other.
- Shared Data/Object Communication Architecture: In this architecture, rather than simply sending commands and returning data, both applications share the actual data through some sort of shared memory method.
Streaming/Buffered Communication
When streaming data, large amounts of information are sent continuously but not necessarily in real time. A network stream is a loss-less, unidirectional, one-to-one communication channel that consists of a writer and a reader endpoint. A common use of streaming communication is when one machine is doing high speed data acquisition, and the data must be transferred to the another for logging or post-processing.
network-streams
It is important to note that network streams require more overhead than non-networked data transfer methods. In addition, the processing part of the whole system need enough memory to store data before analyzing.
So, each model has different strong points. The way to choose an appropriate model mainly depend on requirements of the application and resources that we have. For instance, If we use the CompactRIO target for image processing, which does not have enough memory to analyze the images captured from the camera. So, we can not use Streaming/Buffered Communication model.
II – Networking Protocols
There are several protocols that LabVIEW supported. Some commonly used are:
  • Network Streams
  • Network-published shared variables
  • Time-triggered shared variables
  • TCP/IP
  • UDP
  • VI Server
  • Web services
- Network Streams: Network streams were designed and optimized for lossless, high throughput data communication where the programmer doesn’t want to deal with the complexity of using TCP. This protocol can transfer most LabVIEW data types, without having to flatten and in-flatten the data to and from a string, including clusters and arrays over the network, but stream are most efficient with the following data types:
network-streams - diagram

  • Numeric scalars
  • Booleans
  • 1D arrays of numeric scalars
  • 1D arrays of Booleans

- Network-published shared variables: Network-published shared variables are an easy-to-use LabVIEW tool for sharing data. They are straightforward to implement and support most LabVIEW data types and custom type definitions. it is most suitable for process data communication when the latest value of a process variable is important. Moreover, it is important to know that Shared Variables cannot guarantee high throughput or low latency.

However, overuse and misuse of Shared Variables are very common in most application. As a result, in some cases, the system can crashes.  Typical misuses include using too many Shared Variables or attempting to push too much data through a single Shared Variable.  For example, in applications deployed to small Real-Time targets such as Compact RIO, no more than 25 variables should be used.  In applications deployed to large Real-Time targets such as PXI or Industrial Controllers, no more than 150 Shared Variable should be used.
- Time-triggered shared variables: With the time-triggered network, two or more LabVIEW Real-Time PXI or PC targets can transfer data deterministically over a private Ethernet network. This protocol is normally used to solve applications that require deterministic operation, increased reliability, and autonomous operation. However, the important thing needed to know is that this protocol requires q dedicated secondary Ethernet network – only work for target that has two or more Ethernet ports.
- TCP/IP: TCP is a reliable point-to-point communication protocol; data is delivered in an ordered, loss-less manner. This protocol is a good candidate to use when transferring large amounts of data between systems, for instance, transferring several images at the “same” time from one to the other machines.  Because TCP/IP is available on most computers, it can transfer information among diverse systems.
tcp

- UDP: UDP differs from TCP in that it will publish data to a specified port but does not require a connection with a client before sending the data. If there is no connection to receive the data at its destination, the data is simply discarded; there is no check for successful delivery. Therefore, UDP is used in applications in which reliability is not critical. For example, an application might transmit informative data to a destination frequently enough that a few lost segments of data are not problematic.

- VI Server:  This protocol is used to monitor and control VIs on an RT target. Using VI Server, a LabVIEW VI can invoke RT target VIs remotely. The LabVIEW VI can pass parameter values to and from the RT target VIs, creating a distributed application.

vi server

Using the VI Server is that the VI Server allows us to access the functionality of TCP while working within the framework of LabVIEW. However, the VI Server is non-deterministic and using VI Server communication can affect the determinism of the VI.

- Web Services: Web services allow us to create Web applications that communicate over the network with any HTTP-capable Web client, which includes standard web browsers. Many users can monitor one or many application from many different platforms and locations. Data is exchanged with the Web method VI using a URL and standard HTTP methods.

Conclusion

There are several models as well as networking protocols that we can use to perform communication tasks. Each model or protocol has different advantages and disadvantages, using which one are strongly depend on the requirements of the application, which should be analyzed carefully as a first stage of design an application. For example, in my project, determinism and loss-less are very important. In addition, images, which are large amount of data, are transferred  between PC and RT Controllers. So, I chose Process Data communication model – Bi-Directional Communication Architecture and relied on TCP/IP and Network-published shared variables protocols.

[1] LabVIEW Real-Time Application Development Course Manual, National Instruments, 2008

[2] http://www.ni.com/white-paper/12079/en – Using the right networking protocols

[3] http://www.ni.com/white-paper/3098/en – Command-based communication using simple TCP/IP messaging

[4] CompactRIO Developers Guide, National Instruments, 2008

[5] http://zone.ni.com/reference/en-XX/help/371361G-01/lvconcepts/choosing_lv_comm/

[6] http://zone.ni.com/reference/en-XX/help/371361J-01/lvconcepts/networkstreams/

[7] http://www.ni.com/white-paper/12267/en – Loss-less Communication with Network Streams

[8] http://www.ni.com/white-paper/4679/en – Using the LabVIEW Shared Variable

[9] http://www.ni.com/white-paper/12176/en

[10] http://www.ni.com/white-paper/4720/en

[11] http://www.facstaff.bucknell.edu/mastascu/elessonsHTML/Network/Network2DataServers.htm

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: