The History of Modbus RTU

Modbus RTU is an open, serial (RS-232 or RS-485) protocol based on

master/slave or client/server architecture. It is popular, well established,
relatively easy to implement and reliable. Since it is so easy to implement,
Modbus RTU has gained wide market acceptance wherever Industrial
Automation Systems (IAS) or Building Management Systems (BMS) need
to communicate with other devices. In fact, Modbus RTU is probably the
most implemented automation protocol of all, and a quick search of
Google will confirm this.

Modbus RTU messages, although simple, contain a 16-bit CRC (Cyclic-

Redundant Checksum) to ensure reliability.

The simplicity of Modbus RTU messages is a mixed blessing; on the one

hand, the simple message structure ensures widespread, rapid and
accurate implementation, but on the other hand, various companies have
corrupted the basic 16-bit Modbus RTU register structure to pack in
floating point, queues, ASCII text, tables and other types of non-Modbus
data.

ProtoCessor modules and FieldServers are user configurable and allow user adjustments to compensate for the above issues

The best source of Modbus RTU protocol specifications

One of the best sources for more detailed information is www.Modbus.org.

Source code for Modbus RTU can be found here.

Shortcomings of Modbus RTU

Report by Exception

As mentioned, Modbus RTU is a client/server or master/slave architecture. This means that in order for data to reach the client,
the client node needs to poll the server node. Modbus RTU can also be multi-dropped, or in other words, multiple slave devices
can exist on one Modbus RTU network, assuming that the physical layer allows this, usually via the use of RS-485, modems or
radio. Often dozens or hundreds of nodes are multi-dropped in this fashion, and at relatively low baud rates. Because of the low
speed and number of Modbus nodes involved, changes in the field nodes can take tens of seconds, or minutes, to reach the
client.

There have been various attempts to create Modbus RTU “report by exception” or “unsolicited message” enhancements.
However, as soon as this is done, the protocol is no longer Modbus RTU! Although the methodology may work if the same vendor
provides both the client and the server nodes, this approach almost guarantees incompatibilities.

If an application requires very fast data transfer it would probably be best to investigate a protocol that supports “report by
exception”, such as EtherNet/IP or BACnet.

Data Object Properties, or naming of the data

Modbus RTU packets only transfer data. There is no provision for parameters such as point name, units, resolution etc. Modern
protocols such as BACnet, EtherNet/IP and LonWorks all provide for these sorts of properties. In addition, there are various
committees that also create profiles for various types of devices, for example, thermostats, generators, light switches etc. The
LonMark organization (www.lonmark.org) does this for LonWorks. Once again, this has nothing to do with Modbus RTU.

Complexity of protocols that compete with Modbus RTU

At first glance the enhanced feature set mentioned above may seem to eliminate Modbus RTU as a contender for new designs.
However, Modbus RTU has been around much longer than these other protocols and currently has a larger market share. More
importantly, these other protocols are much harder to implement and support. For example, the source code for BACnet can be
had for about $20,000.00 and uses 32-100K of program memory. Also, there is no way that BACnet or EtherNet/IP can be fully
supported on a small 8-bit CPU or PIC processor, whereas Modbus RTU will easily fit into a spare 2K or so.

Maximum number of Modbus Addresses

Legal Modbus RTU node addresses are 1-254. 0 is reserved for broadcast messages, and useable for writes only. This is very
seldom used since there is no confirmation that the message was successfully received at the server node. If the physical later is
RS-232 then only one node can be implemented anyway. The RS-485 specification limits the number of nodes to 32, although
some RS-485 drivers will allow this limit to be extended somewhat.

Modbus RTU Conformance Testing

In order to guarantee compatibility, a Modbus Conformance Test Laboratory has been established at the University of Michigan.
See their website for more details. It needs to be remembered that although testing at this conformance test lab will guarantee
that the raw data reaches the other node, the other node may not understand what all the numbers mean. The receiver of the
 data still needs to know what the data points in the “Modbus Memory Map” mean. FieldServers and ProtoCessors provide user
configurable tables to allow users to “remap” the data. See the section on the “Modbus RTU Memory Map” later.

Modbus RTU Interoperability Testing

As mentioned in the above section, simply guaranteeing that the data reaches the other node is not enough to guarantee that
two dissimilar systems will work together. In addition to “Modbus RTU Conformance Testing”, devices need to go through a
process of “Modbus RTU Interoperability Testing”. To my knowledge, there is no such organizations that do this testing at this
time. Once again, ProtoCessors and FieldServers, through the configuration file, take the raw Modbus RTU data and provision it
with additional properties such as names, units, alarm limits etc. and make all these properties available to the more
sophisticated protocol.

Modbus RTU vs Modbus/TCP

Officially now known as “IEC Publicly Available Spec: IEC PAS 62030 (pre-standard)” Modbus TCP could almost be defined as
Modbus RTU inside a TCP/IP connection, with a 6 byte header to allow routing. For more information on Modbus/TCP see the
official Modbus website at www.modbus.org. Other names that have been used for Modbus/TCP are Modbus/IP, Modbus Ethernet
and Modbus TCP/IP.

The Modbus RTU Memory Map

As defined, this Modbus RTU standard provides data in four Modbus memory map groups or data types.

Modbus RTU Data Common name Starting

Type address
Modbus Coils Bits, binary values, flags 00001

Digital Inputs Binary inputs 10001

Analog Inputs Analog inputs 30001

Modbus Registers Analog values, variables 40001