Field-Bus Protocol Design

The company required a communications protocol to be designed to link field-bus devices on a peer-peer network. We designed this, which was used on 9600 baud RS-485, encapsulated in ARCNET over RS-485, and ecapsulated in LON packets. This allowed the company to offer the three communications options for the same products, and therefore to offer a differential pricing structure, depending on the network chosen by the customer.

Introduction

We designed the communications routers for the standard and ARCNET network options, which featured dynamic routing, learning the topology of the network automatically and maintaining internal routing tables. We also designed and developed an open communications server for the Windows platform.

This software application was written to run as a Windows service and provides an interface to other programs and scripts to allow them to access the hardware (field-bus devices) in a generic way, no matter which field-bus protocol they are running. The software was later enhanced to allow the PC to connect directly to the field-bus network using a PCI card specific to the network. It was written to handle messages from the devices in a number of different protocols and to present a more simple interface to external programs using Microsoft's COM technology. In this way it was very simple to create small scripts and other software applications that could communicate with the field-bus devices through the communications server, as well as allow multiple programs to access the field devices at the same time.

The server was created as a multi-threaded application using MFC and ATL to expose its COM objects to external applications. The server was later enhanced to provide a DCOM interface. This allows networked PCs to make use of the communications server running on a single "gateway" PC.

The server has a simple GUI interface to allow it to be configured and can manage many connected networks at once. The software provides an visual indication of the network traffic to the user by flickering lights in the system tray.

Each network is configured to be a serial connection, a modem connection through TAPI, an ARCNET connection through a PCI card (from Contemporary Controls) or a LON card (from Echelon Corporation). Each communication protocol was provided as a plug-in DLL to the main server application. A defined interface between the two allows the number of network protocols to be added to in the future without the need to re-build the communications server. In addition, a software licensing system was applied to individual modules, so for example a premium could be charged by the company for any customer requiring LON support.

In this project we were successful in developing the communications server to provide a simple DCOM interface to other software. This approach was especially successful because the program exposes its properties and methods to C++, VB, and to scripting languages such as PHP, JavaScript and VBScript. This allowed it to be used in many other applications. For example, the software is now running on many test systems on the company's production line for functional testing of their hardware devices. Their Test department have a knowledge of VB programming, but not of the communications protocols of the hardware devices themselves. By providing a simple software interface to VB applications it was easy for the Test department to automate much of their process using the communications server we developed.

Technology

• Visual C++ 6.
• ATL COM / DCOM
• ARCNET. (Peer-Peer protocol design)
• LON. (Integration of controllers with Echelon network)
• TCP/IP. Wrapped controller protocol packets in TCP/IP

Benefits

• Single communications server application for any protocol.
• Allowed differential pricing, depending on protocol.
• Easy to use, reducing support calls.
• Written as COM component. Used in other applications requiring access to controller network