History of the Modbus protocol

Some communication standards just emerge. Not because they are pushed by a large group of vendors or a special standards
organisation. These standards—like the Modbus interface—emerge because they are good, simple to implement and are
therefore adapted by many manufacturers. Because of this, Modbus became the first widely accepted fieldbus standard.

Modbus has its roots in the late seventies of the previous century. It is 1979 when PLC manufacturer Modicon—now a brand of
Schneider Electric's Telemecanique—published the Modbus communication interface for a multidrop network based on a
master/client architecture. Communication between the Modbus nodes was achieved with messages. It was an open standard
that described the messaging structure. The physical layer of the Modbus interface was free to choose. The original Modbus
interface ran on RS-232, but most later Modbus implementations used RS-485 because it allowed longer distances, higher
speeds and the possibility of a true multi-drop network. In a short time hundreds of vendors implemented the Modbus
messaging system in their devices and Modbus became the de facto standard for industrial communication networks.

The nice thing of the Modbus standard is the flexibility, but at the same time the easy implementation of it. Not only intelligent
devices like microcontrollers, PLCs etc. are able to communicate with Modbus, also many intelligent sensors are equipped with a
Modbus interface to send their data to host systems. While Modbus was previously mainly used on wired serial communication
lines, there are also extensions to the standard for wireless communications and TCP/IP networks.
General

Modbus is one of the oldest fieldbuses on the market. It was developed in 1978 by the engineers at Modicon... originators of
the first PLC. It's primary purpose was, of course, to exchange data between PLCs and other devices on the production floor.
Since it is one of the oldest communication protocols it uses a more traditional approach to connecting devices. That approach
is typically based upon a master/slave system over a serial line.(RS-232/485). Depending upon which Modbus protocol is used,
the communication can be either simple or peer-to-peer. The protocols available include ASCII/RTU or Modbus Plus.
(Modbus/TCP is also available to talk on an ethernet line).

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.

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.

Modbus controllers use a master/slave communication method. This means that only one device (ie. the master) can initiate
communication. The other devices (ie. slaves) respond to the masters communication messages. They either send back the
requested data or perform the requested operation. The master can talk with individual slave units or all slave units at one time
(ie. broadcast messages). Regardless of the transmission 'mode' (ie. ASCII or RTU) the communication cycle and contents
remains the same. The frame of the message looks like this:

Device Address
Function Code
8-bit Data Bytes
Error Checking

The master sends the above, the slave receives it and replies back in the same format. It's important to note that the messages
all have a known starting and ending point. This allows the receiving devices to know that a message has arrived, figure out if
it's for them or not, and know that the message has been completely received.