A CVT Client Communication Interface

In distributed applications using the current value table (CVT) there is a fundamental need to pass CVT data between hosts. This document describes one method of communication between CVT instances using a TCP/IP client/server protocol. As an example, this document uses a machine control system consisting of a machine controller and an HMI. It assumes the reader is generally familiar with the machine control reference architecture. Throughout this document the term client refers to the device that serves as the HMI and the term server refers to the device that contains the logic and I/O for handling the machine control.

Purpose:

The primary function of the client communication interface is to share information between CVT instances on the server and the client.  This is done by mirroring portions of the CVT from one side to the other and vice versa.  Generally speaking, there will be certain tags on the server that the client has an interest in.  By the same token, there will be information on the client that needs to be passed down to the server.  For example, if we want to control temperature, then the client needs to send setpoints to the server and then monitor the temperature readings returned by the server.

In applications involving hundreds or perhaps thousands of tags, the importance of efficient communication becomes obvious.  TCP/IP is a standard protocol that is relatively simple yet it offers high throughput and scales well for high-channel-count systems.

Implementation:

The CVT client communication interface is made up of two separate elements.  The server portion of the interface acts as a TCP server and consists of a command parser which processes requests for data from the client.  The client portion of the interface acts as the TCP client and initiates the communication with the server.  It then sends commands to the server for configuring and sending/receiving data.

Figure 1 - CVT Client Communication Overview

The client communication protocol implementation emphasizes performance optimization by configuring as much as possible on the first call, leaving the repetitive operations with less work to do.  Accordingly, the protocol is implemented in such a way that the client must first identify all of the tags of interest.  This is done by creating tags with “PAC (CCC)” as the protocol and the name of the server tag to bind to as the address.  On the first execution the server looks up the tags by their index in the CVT.  From that point forward, only the CVT index API is used to ensure the highest possible performance.

On both the client and server components, all of the repetitive operations are implemented with determinism in mind.  They allocate all of the necessary resources on the first call of each function and use a functional global variable to store blocks of data between iterations, ensuring that no memory allocation takes place after the first iteration.

The underlying implementation is TCP/IP.  Specifically, it is an adaptation of the Simple TCP Messaging (STM) protocol, which offers a platform-independent way of sending messages by name while maintaining the performance and throughput of raw TCP communication.

The STM messages for the CVT client communication interface are:

API:

The server API is a single VI that is designed to run in parallel with the rest of the server application.  This allows the rest of the machine control to execute asynchronously, offering better control over the application timing.  The CVT needs to be initialized prior to calling CCC Server.vi.  The server API is stopped using a notifier.

Figure 2 - CCC Server.vi

The client API follows the familiar LabVIEW style of Initialize, Write, Read, and Close.  CCC Client Init.vi is responsible for initiating the connection with the server.  The input “HMI DataEngine Tag List” can be created manually or obtained from the load function provided with the Tag Configuration Editor.

Figure 3 - CCC Client Init.vi

CCC Client Write.vi configures and writes a block of data to the server.  Any client tags that are configured to use the “PAC (CCC)” protocol and are designated as “write” tags will be sent to the server.

Figure 4 - CCC Client Write.vi

CCC Client Read.vi configures and reads a block of data from the server.  Any client tags that are configured to use the “PAC (CCC)” protocol and are designated as “read” tags will be read from the server.

Figure 5 - CCC Client Read.vi

CCC Client Close.vi simply closes the connection to the server.

Figure 6 - CCC Client Close.vi

 

Example:

In most cases both the server and client elements of the interface can be used as drop-in components.  The server needs only to have the TCP port configured (default is 5555) and the client will need the server’s IP address and port number.  This example shows the CCC Server running in parallel with the main program code.

[+] Enlarge Image

Figure 7 - CCC Example - Server.vi

In the corresponding client application, you can see that the CCC write and read operations are done in series with the rest of the HMI code.  This ensures that the values for both the read and the write tags are updated on each iteration.

[+] Enlarge Image

Figure 8 - CCC Example - Client.vi

The client tag list is shown here for reference.  As you can see, each tag that uses the “PAC (CCC)” protocol has a corresponding server tag’s name in the “Target Address” field.

[+] Enlarge Image

Figure 9 - Client Tag List

 

Download Link: CVT Client Communication (CCC) Component

             

Reader Comments | Submit a comment »