Using the Right Networking Protocol

Each type of communication involves targets (usually data acquisition system or controllers) and hosts (usually displaying the HMI) that can be arranged in several possible configurations. You can have communication between a single target and a single host (1:1); between multiple targets and a single host (N:1), or communication between single target and multiple hosts (1:N). The following section describes each communication type used in machine control applications, their common systems configurations, and their networking and data transfer requirements.

Command or Message-Based Communication

Command or message-based communication is infrequent information transfer triggered by a specific event. This could be a button press or an alarm, which then triggers a specific response. In command-based architecture there are two systems types involved: a commander system (host) and a worker system (target). The commander sends instructions that the worker must execute. Commands must be delivered in a lossless manner and should have minimal latency. For example, when an operator pushes a button, they expect the associated action to be executed without having to the push the button again. They also expect the system to respond in a reasonable time frame. The most common configuration is 1:1, but N:1 and 1:N are also possible.

Process Data Communication

Process data communication consists of periodic transfer of the latest values of process variables. This type of communication is the most common communication and is useful for control applications and for HMIs used for displaying current system states.  For instance this would be used for periodic updates sent from one or many embedded controllers to an HMI, which monitors the status of the machine(s).  The operator needs to see the current state of the machines so lossless transmission is not a requirement because the real-time controller or HMI is only acting upon the latest value.

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 an HMI.  This type of communication involves slower update rates because the data is being viewed by humans. Update rates of 1 to 30 Hz are usually sufficient; anything faster taxes CPU and memory resources, and is more information than the human operator can visually process. A good rule of thumb is that numeric displays should be updated at rates no faster than 1-2 Hz, and for graphical displays, 30 Hz provides smooth updates.

Streaming/Buffered Communication

When streaming data, large amounts of information are sent continuously but not necessarily in real time. This type of communication is useful when you want to send lots of data and you need to capture each data point. Often, though not always, streaming is unidirectional and has a 1:1 configuration. It involves continuous buffering of the data so no data is lost. A common use of streaming communication is when a target is doing high speed data acquisition, and the data must be transferred to the host for logging or post-processing.

Table 1.1. Summary of Machine Control Communication Types

When choosing a networking protocol for your application there are a number of factors you should evaluate, including:

• Communication type
• System configuration
• Performance
• Ease of use
• Supported 3^rd party APIs

The communication types and system configurations discussed above will be the largest determining factor in choosing the networking protocol for your application. Performance and ease-of-use requirements will be dictated by your specific application and programming experience. Finally, if you plan on developing your application to communicate with 3^rd party applications such as those developed with C or VB, you will need to use networking protocols that can interface with 3^rd party APIs. By examining these factors, you will be able to make the correct decision for your application. Refer to Table 1.2 for a summary of each networking protocol as it relates to the above factors.

Table 1.2. Summary of Networking Protocols ( = Best,  = Better,  = Good, * = depends on what action is being completed in the web service)

TCP and UDP

TCP and UDP Internet protocols are low level building blocks used by all the networking protocols discussed in this document. All other protocols provide an ease-of-use abstraction on top of these protocols; because of this TCP and UDP offer the highest performance, and provide low-level control allowing the greatest flexibility. TCP and UDP can be used to construct your own custom protocol, such as STM.

TCP

TCP is a reliable point-to-point communication protocol; data is delivered in an ordered, lossless manner. It is a connection-based protocol, which means that a connection between the client and the server must be established before transferring data. To ensure data delivery, TCP retransmits the data until it receives an acknowledgement. The TCP client and server communicate over a specified port.

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 should not be used in applications where lossless data transfer is critical.

UDP functions can be used to communicate with a single client, or data can be broadcast to several clients. UDP multicast is a mode used to efficiently communicate between a single sender and multiple clients on a network, without requiring the sender to maintain a list of clients. UDP has the highest transfer rates of all protocols discussed here, but it does not ensure lossless data transmission.

TCP and UDP are high throughput networking protocols, but this comes at the cost of ease of implementation. The network connection requires manual management, and each connection consumes a port. TCP and UDP require all data be sent in string format. This means the sender must flatten all data to a string and the receiver must unflatten the data from string. This adds an extra layer of complexity to non-string data transmission.

TCP and UDP are good tools for message-based communication and custom streaming applications. They support all types of configurations, and since they are industry standards, they can be used with 3^rd party applications.

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.

The network variable in LabVIEW is made up of three parts: network variables nodes, the Shared Variable Engine, and the NI Publish-Subscribe Protocol (NI-PSP). The network variables nodes are placed on the block diagram to perform the variable’s read and write operations. The Shared Variable Engine is the software component hosting the published data. This can be hosted on real-time targets or Windows PCs, but must be running on at least one networked machine.  NI-PSP is a proprietary networking protocol that optimizes the transport of network shared variables. This protocol is based on TCP/IP, which allows it to efficiently and reliably transmit data over the network.

You can enable buffering on Network-Published Shared Variables, which is appropriate when you need an easy way of implementing pseudo-lossless N:1 and 1:N communication. Shared variable buffering can help prevent data loss due to temporary network delays, but it does not guarantee lossless data transfer. If a client writes data faster than another client is reading data, an overflow will eventually occur and data will be lost; data flow is not managed to prevent overflow. Even if all clients are reading at a fast enough rate, data may still be lost if data is being transmitted while the underlying TCP connection is interrupted due to network outages. Network streams are recommended when lossless, point-to-point data transfer is desired. Network-published shared variables are most suitable for process data communication when the latest value of a process variable is important.

Network Streams

Network streams are a LabVIEW feature released in LabVIEW 2010 designed to provide efficient data streaming.  They provide easy to use higher level abstractions to handle connections, disconnections, and data flow control, while still maintaining similar throughput of raw TCP/UDP. They are a lossless, unidirectional, one-to-one communication channel that consists of a writer and a reader endpoint. Because of their lossless nature they can also be used as a foundation for message-based communication.

Network streams can transfer most LabVIEW data types including clusters and arrays over the network, but stream are most efficient with the following data types:

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

You can use network streams to pass data from computer to computer, computer to real-time target, or real-time target to real-time target. Since network streams are unidirectional, if you want to pass data both ways between your endpoints, you will need to open two streams. Similarly, if you need to pass data to multiple targets you need to open multiple streams.

Web Services

Web services allow you to create Web applications that communicate over the network with any HTTP-capable Web client, including standard web browsers. LabVIEW allows you to publish a VI as a server-side Web service; this VI is referred to as a Web method VI. This Web service is deployed to an executables own web server or to the Application Web Server, and can be hosted on Windows PCs and NI Real-Time computing platforms. This LabVIEW feature has the advantage of being capable of interfacing with numerous HTTP-capable devices and applications, which are not limited to National Instruments products. Many users can monitor one or many application from many different platforms and locations. The ease-of-use and efficiency will depend on the Web client and your familiarity with programming Web applications.

Data is exchanged with the Web method VI using a URL and standard HTTP methods. For example, you can provide input data for the controls in the Web method VI from a Web client using standard HTTP methods, such as POST. Data is returned to the HTTP client either through the VI’s output terminals or by streaming data through the Web server.  With the terminal method, when the Web server receives a request, it returns any data wired to an output terminal to the Web client as an extensible markup language (XML) string. The Web service can also be configured to return data in hypertext markup language (HTML), JavaScript Object Notation (JSON), or text format. A Web method VI can also be configured to use stream output mode. This output mode allows you to return data in a customized format; you can implement buffering and use custom HTML headers. With these two available output modes, Web services are suited for monitoring or streaming applications.

The following summarizes which networking protocol is best suited for each communication type in machine control applications.

Command or Message-Based Communication

Message-based communication requires reliable transmission and quick transfer rates. Table 1.3 lists all options for message-based communication. This application is best served by Network Streams; they are reliable, easy to use, and can offer rapid transfer rates. If however, you require a 1:N or N:1 system configuration or you need to transfer data with 3^rd party applications, TCP/UDP are more appropriate. For ease-of-use, multiple network streams may still be used if N is small. Web services can be used with performance similar to that of TCP with parsing but can be easier to use.

Table 1.3 Networking Protocols Suited to Message-Based Communication

Process-Data Communication

Process-data communication is only interested in the latest value. Therefore, guaranteed delivery and transfer rates are not as important. Table 1.4 lists all options for process-data communication. Shared variables are the recommended LabVIEW feature for this application. They are easy to use and allow numerous system configurations. They also automatically manage the network connection. Web services should be used when the data must be monitored from multiple locations on computers without LabVIEW. Similarly, TCP/UDP should be used if the data will be monitored by 3^rd party applications.

Table 1.4 Networking Protocols Suited to Process-Data Communication

Streaming/Buffered Communication

Streaming communication requires fast transfer rates and reliable transmission. Table 1.5 lists all options for streaming/buffered communication. Network streams are recommended for this application. TCP/UDP should be used for N:1 or 1:N configurations and if you need to stream data to a 3^rd party application.

Table 1.5 Networking Protocols Suited to Streaming/Buffered Communication