Fieldservers and Protocol Converters

Today’s topic derives from a project I have become involved in in my “spare” time. Lately I have been spending a lot more time teaching classes. My project in Miami is mostly complete, so I have been able to get involved in a few smaller projects.

This project involves Building Automation, a field that I don’t know much about but plan on learning more of. I was called in because this project involves an Allen-Bradley PLC, something that is a bit unusual in the Building Automation world.

While PLCs are common in the industrial world, when it comes to controlling buildings and campuses in the commercial space the landscape looks a bit different. Instead of production machinery, the equipment and facilities involve environmental controls; boiler rooms, chilling plants, lighting controllers, security systems etc. HVAC systems, computer UPS systems and gas monitoring are also tied into the network.

There are many different manufacturers and vendors in this space that may use different protocols for communications between systems and devices. Some may be the same as those in industry; ProfiBUS and Modbus are common. Others, such as BACnet, are specific to the building automation and control world.

In a previous post on serial devices I mentioned using An RTA (Real-Time Automation, www.rtaautomation.com) protocol converter for an application. In that case the task was to convert a text string formatted in a series of PLC STRING registers from EthernetIP into RS232. Since the string was built specifically for a specific target, a label printer in this case, it was not necessary to exchange queries back and forth from the device. Messages were mostly predefined with just a few changes in the data such as the date and serial number. But what if you need to map tags back and forth from two systems that speak different languages and have different data structures? That’s where FieldServers come in.

Back in the 1990s I did a few projects where data had to be exchanged and converted. It involved working with things like Allen-Bradley’s SLC based BASIC module and writing computer code on a dedicated PC. This was very time-consuming, hence expensive. Now the cost and time involved has been reduced significantly due to devices like FieldServers.

A FieldServer is a type of communications bridge or gateway. Some do a very similar thing to the RTA device, simply converting one protocol to another as the messages are sent. Others, such as the one I am working on, actually map tags from different devices to one another and handle communications in both directions. This involves onboard memory and a bit more configuration. In my case I am mapping several hundred PLC tags in a ControlLogix PLC to a Siemens building automation controller. The tag structures are different as are the speed and language of the devices. Fortunately ProSoft, a well known provider of Allen-Bradley and other PLC devices, has made a widget specifically for BACnet.

A cool thing about this device is that it uses three different sets of registers; the server side mapped to the PLC and specific to it’s names and structures, an intermediate internal register which can be manipulated by doing math or swapping bytes with each tag or group, and the client side mapped via BACnet to the building control system. This allows the naming conventions and structures to be dictated by both parties involved.

In my particular application there is a bit more involved since the integrator who built the PLC side used UDTs and AOIs extensively in their code. The FieldServer can only read “flat” tags, meaning that the tags all have to be mapped from their structured form into basic BOOLs, DINTs and REALs. While this is pretty easy, tags still have to be entered manually into the code by browsing for their location in the software. They also have to be typed into the FieldServer configuration file. I am in for a lot of copy and paste from Excel!

Still, a pretty cool application. I like learning new stuff, and in this case it has opened my view to the world of building automation. This coincides with doing some home automation of my own, as well as getting involved with building a Cisco network. I will be covering some of these topics in the future also.

If you are involved in the Building Automation or Home Automation industries I’d love to hear from you also. It seems like an interesting field and I’d like to learn more!