There’s an old joke that everyone wants to go to Heaven but no one wants to die. It’s also true that there is one sure fire way to avoid all the pains and suffering of old age – die young. I think I’ll pass on that.
I got to thinking about this today as I looked through some of the emails we get from customers. It seems that the majority of them want some form of Modbus connected to devices on all sorts of other networks. Why is that? Well Modbus has a lot of advantages:
1. It’s small – you can easily fit it into the smallest of processors. No big RAM or ROM requirements.
2. It’s cheap – you can build it yourself or you can buy it for a very small charge.
3. It works with all processors – anything that has a UART can run Modbus.
4. It’s simple to deploy – it’s just daisy chained RS485. Wire from one device to the next to the next.
5. Very simple data typing, memory map and operating functions – it’s simple enough that most competent programmers can implement it within a week or so.
6. There’s a lot of it out there – you can’t go wrong with a Modbus interface. Everybody understands it and can usually find a way to move the data where it needs to go.
When you think about this, it’s really true, MODBUS WILL LIVE FOREVER. A big reason for that is the guys that build devices are not network communication experts. They are domain experts in pumps, chillers or drives or whatever. They need a way to talk to their device. Something simple, that isn’t going to cost too much and that they can get implemented quickly. The answer for the last 30 years has been Modbus and I see no reason for it to change now.
Let’s review this protocol that will live forever and take a look at both Modbus RTU and Modbus TCP.
Modbus is considered an application layer messaging protocol, providing Master/Slave communication between devices connected together through buses or networks. Modbus is intended to be a request/reply protocol and delivers services specified by function codes. The function codes of Modbus are elements of Modbus’s request/reply PDUs (Protocol Data Unit).
In order to build the Modbus application data unit, the Client (or Master) must initiate a Modbus transaction - the function that informs the Server (or Slave) of which action to perform. The format of a request initiated by a Client is established by the Modbus application protocol. The function code field is coded into one byte. Only codes between 1 and 255 are considered valid, with 128-255 being reserved for exception responses. When the Client sends a message to the Server, the function code field informs the Server what type of action to perform.
To define multiple actions, some functions have sub-function codes added to them. For instance, the Client is able to read the ON/OFF states of a group of discreet outputs or inputs. It can also read or write the data contents of a group of Modbus registers. When the Client receives the Server response, the Server uses the function code field to indicate either an error-free response or an exception response. The Server echoes the request of the initial function code in the case of a normal response.
Modbus packets are only intended to send data; they do not have the capability to send parameters such as point name, resolution, units, etc. If the ability to send such parameters is needed, one should investigate BACnet, EtherNet/IP, or other modern protocols.
Despite the limitations of Modbus RTU, there are still many good reasons it is still a contender among other industrial automation protocols. For one, Modbus RTU is much easier to implement than newer protocols, and it is a dominant force in the market place. Modbus RTU also requires significantly less memory than most other solutions. To implement Modbus RTU, you can fit the necessary 2Kb on a small 8-bit CPU or PIC processor, whereas with BACnet and EtherNet/IP, you may require 30-100Kb of memory.
Standard Modbus RTU node addresses are 1 to 254, with 0 being reserved for broadcast messages and write only. However, the 0 address is rarely used due to the fact that there is no confirmation that the message was properly received at the Server node. This doesn’t have much affect if your physical layer is RS-232 as only one node can be implemented anyway. RS-485 limits the number of nodes to 32, though some drivers will allow you to extend the amount.
There are two basic data types in Modbus; Modbus Coils and Modbus Registers. Coils are bits – either input status bits or output control bits. Registers are 16-bit unsigned data items. That’s it, just two data types. Modbus has the simplest data scheme of any widely used communication protocol.
The Ethernet version of Modbus is Modbus TCP/IP. A Modbus packet in Modbus TCP/IP is nearly identical to a Modbus RTU Packet. The only difference is that the CRC (cyclic redundancy check) is not used with the Modbus packets in the Modbus TCP message.