Modbus

Modbus is a serial communications protocol originally published by Modicon (now Schneider Electric) in 1979 for use with its programmable logic controllers (PLCs). Simple and robust, it has since become a de facto standard communication protocol, and it is now a commonly available means of connecting industrial electronic devices. The main reasons for the use of Modbus in the industrial environment are:

• It has been developed with industrial applications in mind
• It is openly published and royalty-free
• It is easy to deploy and maintain
• It moves raw bits or words without placing many restrictions on vendors

Modbus allows for communication between many (approximately 240) devices connected to the same network, for example a system that measures temperature and humidity and communicates the results to a computer. Modbus is often used to connect a supervisory computer with a remote terminal unit (RTU) in supervisory control and data acquisition (SCADA) systems. Many of the data types are named from its use in driving relays: a single-bit physical output is called a coil, and a single-bit physical input is called a discrete input or a contact.

The development and update of Modbus protocols has been managed by the Modbus Organization since April 2004, when Schneider Electric transferred rights to that organization, signaling a clear commitment to openness. The Modbus Organization is an association formed of independent users and suppliers of Modbus compliant devices that seeks to drive the adoption of the Modbus communication protocol suite, and its evolution to address architectures for distributed automation systems across multiple market segments.

Communication and devices

Each device intended to communicate using Modbus is given a unique address. In serial and MB+ networks only the node assigned as the Master may initiate a command, but on Ethernet, any device can send out a Modbus command, although usually only one master device does so. A Modbus command contains the Modbus address of the device it is intended for. Only the intended device will act on the command, even though other devices might receive it (an exception is specific broadcastable commands sent to node 0 which are acted on but not acknowledged). All Modbus commands contain checking information, ensuring that a command arrives undamaged. The basic Modbus commands can instruct an RTU to change a value in one of its registers, control or read an I/O port, as well as commanding the device to send back one or more values contained in its registers.

There are many modems and gateways that support Modbus, as it is a very simple protocol and often copied. Some of them were specifically designed for this protocol. Different implementations use wireline, wireless communication, such as in the ISM band, and even SMS or GPRS. One of the more common designs of wireless networks makes use of the mesh topology. Typical problems the designers have to overcome include high latency and timing problems.

Frame format

All Modbus variants choose different frame formats.

Modbus RTU Frame Format
Name	Length	Function
Start	3.5c idle	at least 3-1/2 character times of silence (MARK condition)
Address	8 bits	Station Address
Function	8 bits	Indicates the function codes like read coils / inputs
Data	n * 8 bits	Data + length will be filled depending on the message type
CRC	16 bits	Error checks
End	3.5c idle	at least 3-1/2 character times of silence between frames

Modbus ASCII Frame Format
Name	Length	Function
Start	1 char	starts with colon ( : ) (ASCII value is 0x3A)
Address	2 chars	Station Address
Function	2 chars	Indicates the function codes like read coils / inputs
Data	n chars	Data +length will be filled depending on the message type
LRC	2 chars	Error checks
End	2 chars	carriage return – line feed(CR/LF) pair (ASCII values of 0x0D & 0x0A)

Modbus TCP Frame Format
Name	Length	Function
Transaction Identifier	2 bytes	For synchronization between messages of server & client
Protocol Identifier	2 bytes	Zero for Modbus/TCP
Length Field	2 bytes	Number of remaining bytes in this frame
Unit Identifier	1 byte	Slave Address (255 if not used)
Function code	1 byte	Function codes as in other variants
Data bytes	n bytes	Data as response or commands

Unit identifier is used with Modbus/TCP devices that are composites of several Modbus devices, e.g. on Modbus/TCP to Modbus RTU gateways. In such case, the unit identifier tells the Slave Address of the device behind the gateway. Natively Modbus/TCP-capable devices usually ignore the Unit Identifier.

The byte order is Big-Endian (first byte contains MSB).

Note: The "Function code" field is part of the PDU and not part of the transport (TCP) header.

Supported function codes

The various reading, writing and other operations are categorised as follows. The most primitive reads and writes are shown in bold. A number of sources use alternative terminology, for example Force Single Coil where the standard uses Write Single Coil.

			Function Name	Function Code
Data Access	Bit access	Physical Discrete Inputs	Read Discrete Inputs	2
		Internal Bits or Physical Coils	Read Coils	1
			Write Single Coil	5
			Write Multiple Coils	15
	16-bit access	Physical Input Registers	Read Input Register	4
		Internal Registers or Physical Output Registers	Read Holding Registers	3
			Write Single Register	6
			Write Multiple Registers	16
			Read/Write Multiple Registers	23
			Mask Write Register	22
			Read FIFO Queue	24
	File Record Access		Read File Record	20
			Write File Record	21
Diagnostics			Read Exception Status	7
			Diagnostic	8
			Get Com Event Counter	11
			Get Com Event Log	12
			Report Slave ID	17
			Read Device Identification	43
Other			Encapsulated Interface Transport	43

Implementations

Almost all implementations have variations from the official standard. Different varieties might not communicate correctly between equipment of different suppliers. Some of the most common variations are:

• Data types
  • Floating point IEEE
  • 32-bit integer
  • 8-bit data
  • Mixed data types
  • Bit fields in integers
  • Multipliers to change data to/from integer. 10, 100, 1000, 256 ...
• Protocol extensions
  • 16-bit slave addresses
  • 32-bit data size (1 address = 32 bits of data returned.)
  • Word swapped data

Limitations

• Since Modbus was designed in the late 1970s to communicate to programmable logic controllers, the number of data types is limited to those understood by PLCs at the time. Large binary objects are not supported.
• No standard way exists for a node to find the description of a data object, for example, to determine if a register value represents a temperature between 30 and 175 degrees.
• Since Modbus is a master/slave protocol, there is no way for a field device to "report by exception" (except over Ethernet TCP/IP, called open-mbus)- the master node must routinely poll each field device, and look for changes in the data. This consumes bandwidth and network time in applications where bandwidth may be expensive, such as over a low-bit-rate radio link.
• Modbus is restricted to addressing 247 devices on one data link, which limits the number of field devices that may be connected to a master station (once again Ethernet TCP/IP proving the exception).
• Modbus transmissions must be contiguous which limits the types of remote communications devices to those that can buffer data to avoid gaps in the transmission.
• Modbus protocol provides no security against unauthorized commands or interception of data.

Trade group

The Modbus organization is a trade association for the promotion and development of Modbus protocol.

External links

• Modbus Organization site
• Modbus Communication Monitor
• Cost free Modbus RTU Device Testing Software
• Modbus Source Code
• Free Modbus Guide for Field Technician
• uTasker MODBUS extension module for Kinetis, Coldfire, SAM7x, LPC2xxx, LPC17xx, Stellaris, STM32
• Simple modbus/TCP client for Linux
• Perl module for Modbus/TCP
• Android based Modbus TCP Master