35 Jan
PLC vs customer controller

Posted by Admin 

Some of us remember using RS232 at 9600 baud or slower. At that time, RS232 was very popular and was used in many field. When it came to multi-node communication, RS485 was the alternative to RS232. Modbus, Device net, RIO, CAN, J1850, are some of the protocols that were used and some are still used in automation, automotive and several other industries.
Efficiently and properly communicating over these physical layers requires the use of a layered protocols. In the automation and controls areas, the communication protocol layers are transparent to the end user. Configuring the node addresses along with a few parameters is often as complicated as it gets. However, what if there is a need for a custom communication protocol. Will the PLC be the stumped?

Why Custom communication protocols

Some sensors and devices use custom serial communication protocols on standard physical layers. This is often done to package and deliver the data efficiently or with added features for robustness and reliability. A sensor sending 2 bytes of data every 100ms can use as little as three bytes; the first byte would be its ID and the next two bytes would be the actual data. One can add a 4th byte to checksum the message and prevent the clients from processing corrupted information. A simple protocols like the one mentioned can quickly expand to include message IDs, Diagnostic sessions, fault recovery, transmit and receive headers, and so on. Unfortunately, custom communication protocols are developed on a daily basis and may need to interface with them as one point or another.

Are PLCs flexible enough to reasonably accommodate a custom communication protocol?

Some PLCs have expansion nodes to handle different communication protocol physical layers like Ethernet, RS232, RS485, CAN (or device net), etc. If a custom physical layer is used, then it is obviously unrealistic to expect an off the shelf PLC to accommodate such a system.
Data, link, and network layers tend to be standard and PLC would support them at a low level. The user will not be able to access these layers. This is true for most off the shelf protocols.
For some protocols, the transport layer may be developed or customized to fit the application. In the case of Ethernet, it is unlikely to change the UDP or TCP/IP transport layers for example, but custom transport layers are developed for RS485 and other serial protocols. Some of these transport layers like Modbus for RS485 or KW2000 for CAN are standard and may be support buy some PLCs. PLC with scripting options, can provide means for the end user to develop custom scripts that can accommodate custom transport layers. As far as we know, there are limited options for such initiatives and this type of task can be very inefficient when done using a PLC script and/or ladder logic. We talking about communication protocols, PLCs tend to take the back seat and the custom protocol board tend to take the lead.
For now, custom communication protocols should be handled using a custom controller. Using C++ or other high level programming languages are a lot more flexible when it comes to protocol development and integration. From the presentation layer all the way down to the data link layer, these protocol can be complex and outside the scope of the capabilities of a PLC.
PLCs are not the best option for communication in real time systems where deterministic messaging is needed. If a PLC has to receive and process the data, then a gateway needs to be developed to mirror the custom protocol into a standard Modbus or device net and Ethernet IP protocols that the PLC can easily understand.