Modbus

Modbus is a data communications protocol originally published by Modicon (now Schneider Electric) in
1979 for use with its programmable logic controllers (PLCs). Modbus has become a de facto standard
communication protocol and is now a commonly available means of connecting industrial electronic
devices.[1]

Modbus is popular in industrial environments because it is openly published and royalty-free. It was
developed for industrial applications, is relatively easy to deploy and maintain compared to other standards,
and places few restrictions on the format of the data to be transmitted.

The Modbus protocol uses character serial communication lines, Ethernet, or the Internet protocol suite as a
transport layer. Modbus supports communication to and from multiple devices connected to the same cable
or Ethernet network. For example, there can be a device that measures temperature and another device to
measure humidity connected to the same cable, both communicating measurements to the same computer,
via Modbus.

Modbus is often used to connect a plant/system supervisory computer with a remote terminal unit (RTU) in
supervisory control and data acquisition (SCADA) systems. Many of the data types are named from
industrial control of factory devices, such as ladder logic because of 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 have been managed by the Modbus Organization[2]
since April 2004, when Schneider Electric transferred rights to that organization.[3] The Modbus
Organization is an association of users and suppliers of Modbus-compliant devices that advocates for the
continued use of the technology.[4] Modbus Organization, Inc. is a trade association for the promotion and
development of the Modbus protocol.[2]

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
learn that a register value represents a temperature between 30 and 175 degrees.
Since Modbus is a client/server (formerly master/slave) protocol,[5] there is no way for a field
device to get data by the event handler mechanism (except over Ethernet TCP/IP, called
open-mbus) as the client 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 parent station (again, Ethernet TCP/IP is an
exception).
 Modbus protocol itself provides no security against unauthorized commands or interception
of data.[6]

Modbus object types

The following object types may be provided by a Modbus server to a Modbus client device:[7] The
addresses are representative of the original Modicon specification. Under the current standard the address
can be 0 - 65535 with the object type identified by the command used to read or write the coil or register.

Object type Access Size

Coil Read-write 1 bit

Discrete input Read-only 1 bit

Input register Read-only 16 bits

Holding register Read-write 16 bits

Protocol versions
Versions of the Modbus protocol exist for serial ports, and for Ethernet and other protocols that support the
Internet protocol suite. There are many variants of Modbus protocols:

Modbus RTU (Remote Terminal Unit) – used in serial communication, and is the most
common implementation available for Modbus. Modbus RTU makes use of a compact,
binary representation of the data for protocol communication. The RTU format follows the
commands/data with a cyclic redundancy check checksum as an error check mechanism to
ensure the reliability of data. A Modbus RTU message must be transmitted continuously
without inter-character hesitations. Modbus messages are framed (separated) by idle (silent)
periods.
Modbus ASCII – used in serial communication and makes use of ASCII characters for
protocol communication. The ASCII format uses a longitudinal redundancy check checksum.
Modbus ASCII messages are framed by a leading colon (":") and trailing newline (CR/LF).
Modbus TCP/IP or Modbus TCP – a Modbus variant used for communications over TCP/IP
networks, connecting over port 502.[8] It does not require a checksum calculation, as lower
layers already provide checksum protection.
Modbus over TCP/IP, Modbus over TCP, or Modbus RTU/IP – a variant that differs from
Modbus TCP in that a checksum is included in the payload, as with Modbus RTU.
Modbus over UDP – some have experimented with using Modbus over UDP on IP networks,
which removes the overhead of TCP.[9]
Modbus Plus (Modbus+, MB+, or MBP) – Modbus Plus is proprietary to Schneider Electric
and unlike the other variants, it supports peer-to-peer communications between multiple
clients.[10] It requires a dedicated co-processor to handle fast HDLC-like token rotation. It
uses twisted pair at 1 Mbit/s and includes transformer isolation at each node, which makes it
transition/edge-triggered instead of voltage/level-triggered. Special hardware is required to
connect Modbus Plus to a computer, typically a card made for the ISA, PCI, or PCMCIA bus.
Pemex Modbus – an extension of standard Modbus with support for historical and flow data.
It was designed for the Pemex oil and gas company for use in process control and never
gained widespread adoption.
Enron Modbus – another extension of standard Modbus developed by Enron with support for
32-bit integer and floating-point variables, and historical and flow data. Data types are
 mapped using standard addresses.[11] The historical data serves to meet an American
Petroleum Institute (API) industry standard for how data should be stored.

Data models and function calls are identical for the first four variants listed above; only the encapsulation is
different. However the variants are not interoperable, nor are the frame formats.

Communications and devices

Each device communicating (i.e., transferring data) on a Modbus is given a unique address.

In Modbus RTU, Modbus ASCII, and Modbus Plus (which are all RS-485 single-cable multi-drop
networks), only the node assigned as the 'client' may initiate a command.[5] All other devices are 'servers'
and respond to requests and commands. (Note that this client/server naming convention inverts the common
English understanding and Latin origin that there are multiple clients and only one server/patron/business.
To avoid this confusion, the RS-485 transport layer uses the terms 'node' or 'device' instead of 'server', and
the 'client' is not a 'node').

"The (Modbus Organization) is using "client-server" to describe Modbus communications,

characterized by communication between [client device (s), which initiates communication and
makes requests of server device(s), which process requests and return an appropriate response
(or error message)." [5]

Nomenclature is the same as for the protocols using Ethernet, such as Modbus TCP. Here any device can
send out a Modbus command, and as is usual in computer networks, the device sending the command is the
'client' and the response comes from a 'server'.[12]

Many modems and gateways support Modbus, as it is a simple and often-copied protocol. Some of them
were specifically designed for this protocol. Different implementations use wireline or wireless
communication, such as in the ISM radio band, and even Short Message Service (SMS) or General Packet
Radio Service (GPRS).

Commands
Modbus commands can instruct a Modbus device to:

change the value in one of its registers, by write to Coil or Holding register
send back one or more contained values, by read from Coil or Holding register
read a physical input port, by read from Discrete Input or Input register

A Modbus command contains the Modbus address of the device it is intended for (1 to 247). Only the
addressed device will respond and 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 checksum information to allow the recipient to detect transmission errors.

Frame formats
A Modbus "frame" consists of an Application Data Unit (ADU), which encapsulates a Protocol Data Unit
(PDU):[8]

ADU = Address + PDU + Error check.

 PDU = Function code + Data.

In Modbus data frames, the most significant byte of a multi-byte value is sent before the others.

All Modbus variants use one of the following frame formats.[1]

Modbus RTU frame format

This format is primarily used on asynchronous serial data lines such as RS-485/EIA-485. Its name refers to
a remote terminal unit.

Name Length (bits) Function

Start 3.5 x 8 At least 31⁄2 character times (28 bits) of silence (mark condition)
Address 8 Station address

Function 8 Indicates the function code e.g. "read coils"

Data n×8 Data + length will be filled depending on the message type
CRC 16 Cyclic redundancy check

End 3.5 x 8 At least 31⁄2 character times (28 bits) of silence (mark condition) between frames

CRC calculation:

Polynomial: x16 + x15 + x2 + 1 (CRC-16-MODBUS, normal hexadecimal algebraic

polynomial being 8005 and reversed A001).
Initial value: 65,535.
Example of frame in hexadecimal: 01 04 02 FF FF B8 80 (CRC-16-MODBUS
calculation for the 5 bytes from 01 to FF gives 80B8, which is transmitted least significant
byte first).

Modbus ASCII frame format

Primarily used on 7-bit or 8-bit asynchronous serial lines.

Name Length (bytes) Function

Start 1 Colon : (ASCII value 3A16)

Address 2 Station address

Function 2 Indicates the function code e.g. "read coils"

Data n×2 Data + length will be filled depending on the message type

LRC 2 Checksum (longitudinal redundancy check)

End 2 Carriage return + line feed (CR/LF) pair (ASCII values 0D16 and 0A16)

Address, Function, Data, and LRC are ASCII hexadecimal encoded values, whereby 8-bit values (0–255)
are encoded as two human-readable ASCII characters from the ranges 0–9 and A–F. For example, a value
of 122 (7A16 ) is encoded as two ASCII characters, "7" and "A", and transmitted as two bytes, 55 (3716 ,
ASCII value for "7") and 65 (4116 , ASCII value for "A").
LRC is calculated as the sum of 8-bit values (excluding the start and end characters), negated (two's
complement) and encoded as an 8-bit value. For example, if Address, Function, and Data are 247, 3, 19,
137, 0, and 10, the two's complement of their sum (416) is −416; this trimmed to 8 bits is 96 (256 × 2 − 416
= 6016 ), giving the following 17 ASCII character frame: :F7031389000A60␍␊. LRC is specified for
use only as a checksum: because it is calculated on the encoded data rather than the transmitted characters,
its 'longitudinal' characteristic is not available for use with parity bits to locate single-bit errors.

Modbus TCP frame format

Primarily used on Ethernet networks.

Name Length (bytes) Function

Transaction identifier 2 For synchronization between messages of server and client

Protocol identifier 2 0 for Modbus/TCP

Length field 2 Number of remaining bytes in this frame

Unit identifier 1 Server address (255 if not used)

Function code 1 Function codes as in other variants

Data bytes n Data as response or commands

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

Functions and commands

Prominent conceptual entities in a Modbus server include the following:

Coils: readable and writeable, 1 bit (off/on)

Discrete Inputs: read-only, 1 bit (off/on)
Input Registers: read-only measurements and statuses, 16 bits (0–65,535)
Holding Registers: readable and writeable configuration values, 16 bits (0–65,535)

The commands to read and write these entities are summarized in the following table.[7] The most primitive
reads and writes are shown in bold.

Some sources use terminology that differs from the standard; for example Force Single Coil instead of Write
Single Coil.[13]

There are three categories of Modbus function codes: public, user-defined and reserved.
 Public Modbus function codes
Function
Function type Function name Comment
code

Physical Discrete Inputs Read Discrete Inputs 2

Bit Read Coils 1

access Internal Bits or Physical Coils Write Single Coil 5

Write Multiple Coils 15

Physical Input Registers Read Input Registers 4

Read Multiple Holding
3
Registers

Write Single Holding

Data 6
Register
Access
16-bit
Internal Registers or Physical Write Multiple Holding
access 16
Output Registers Registers
Read/Write Multiple
23
Registers

Mask Write Register 22

Read FIFO Queue 24

Read File Record 20
File Record Access
Write File Record 21

Read Exception Status 7 serial only

Diagnostic 8 serial only

Get Com Event Counter 11 serial only

Diagnostics Get Com Event Log 12 serial only

Report Server ID 17 serial only

Read Device
43
Identification
Encapsulated Interface
Other 43
Transport

Format of requests and responses

Requests and responses follow the frame formats described above. This section gives details of the data
formats of the most often used function codes.

Function codes 1 (read coils) and 2 (read discrete inputs)

Request:

Address of first coil/discrete input to read (16-bit)

Number of coils/discrete inputs to read (16-bit)

Normal response:
 Number of bytes of coil/discrete input values to follow (8-bit)
Coil/discrete input values (8 coils/discrete inputs per byte)

Value of each coil/discrete input is binary (0 for off, 1 for on). First requested coil/discrete input is stored as
least significant bit of first byte in reply. If number of coils/discrete inputs is not a multiple of 8, most
significant bit(s) of last byte will be stuffed with zeros.

For example, if eleven coils are requested, two bytes of values are needed. Suppose states of those
successive coils are on, off, on, off, off, on, on, on, off, on, on, then the response will be 02 A7 03 in
hexadecimal.

Because the byte count returned in the reply message is only 8 bits wide and the protocol overhead is 5
bytes, a maximum of 2008 (251 x 8) discrete inputs or coils can be read at once.

Function code 5 (force/write single coil)

Request:

Address of coil (16-bit)

Value to force/write: 0 for off and 65,280 (FF00 in hexadecimal) for on

Normal response: same as request.

Function code 15 (force/write multiple coils)

Request:

Address of first coil to force/write (16-bit)

Number of coils to force/write (16-bit)
Number of bytes of coil values to follow (8-bit)
Coil values (8 coil values per byte)

The value of each coil is binary (0 for off, 1 for on). The first requested coil is stored as the least significant
bit of the first byte in the request. If a number of coils is not a multiple of 8, the most significant bit(s) of the
last byte should be stuffed with zeros. See example for function codes 1 and 2.

Normal response:

Address of first coil (16-bit)

Number of coils (16-bit)

Function codes 4 (read input registers) and 3 (read holding registers)

Request:

Address of first register to read (16-bit)

Number of registers to read (16-bit)

Normal response:
 Number of bytes of register values to follow (8-bit)
Register values (16 bits per register)

Because the maximum length of a Modbus PDU is 253 (inferred from the maximum Modbus ADU length
of 256 on RS485), up to 125 registers can be requested at once when using the RTU format, and up to 123
over TCP.[7]

Function code 6 (preset/write single holding register)

Request:

Address of holding register to preset/write (16-bit)

New value of the holding register (16-bit)

Normal response: same as request.

Function code 16 (preset/write multiple holding registers)

Request:

Address of first holding register to preset/write (16-bit)

Number of holding registers to preset/write (16-bit)
Number of bytes of register values to follow (8-bit)
New values of holding registers (16 bits per register)

Because the maximum length of a Modbus PDU is 253 (inferred from the maximum Modbus ADU length
of 256 on RS485), up to 123 registers can be written at once.[7]

Normal response:

Address of first preset/written holding register (16-bit)

Number of preset/written holding registers (16-bit)

Exception responses
For a normal response, the server repeats the function code. Should a server want to report an error, it will
reply with the requested function code plus 128 (hex 0x80) (3 becomes 131 = hex 0x83), and will only
include one byte of data, known as the exception code.

Main Modbus exception codes

Code Text Details

1 Illegal Function Function code received in the query is not recognized or allowed by server
Data address of some or all the required entities are not allowed or do not exist in
2 Illegal Data Address
server

3 Illegal Data Value Value is not accepted by server

Server Device Unrecoverable error occurred while server was attempting to perform requested
4
Failure action
Server has accepted request and is processing it, but a long duration of time is
required. This response is returned to prevent a timeout error from occurring in
5 Acknowledge
the client. client can next issue a Poll Program Complete message to determine
whether processing is completed

Server is engaged in processing a long-duration command; client should retry

6 Server Device Busy
later
Negative Server cannot perform the programming functions; client should request
7
Acknowledge diagnostic or error information from server

8 Memory Parity Error Server detected a parity error in memory; client can retry the request

Gateway Path
10 Specialized for Modbus gateways: indicates a misconfigured gateway
Unavailable
Gateway Target
11 Device Failed to Specialized for Modbus gateways: sent when server fails to respond
Respond

Entity numbers and addresses

The Modbus Organization mentions the following in the Modbus Application Protocol v1.1b:[7]

The Modbus application protocol defines the PDU addressing rules: In a PDU, each data
item is addressed from 0 to 65535.
It also defines a MODBUS data model composed of four blocks that comprise several
elements numbered from 1 to n.
In the Modbus data model, each element within a data block is numbered from 1 to n.

Some conventions govern how Modbus entities (coils, discrete inputs, input registers, holding registers) are
referenced.

It is important to make a distinction between entity number and entity address:

Entity numbers combine entity type and entity location within their description table
Entity address is the starting address, a 16-bit value in the data part of the Modbus frame,
ranging from 0 to 65,535 (0000 to FFFF in the packets)
In the traditional convention, entity numbers start with a digit representing the entity type, followed by four
digits representing the entity location:

coils numbers start with 0 and span from 00001 to 09999,

discrete input numbers start with 1 and span from 10001 to 19999,
input register numbers start with 3 and span from 30001 to 39999,
holding register numbers start with 4 and span from 40001 to 49999.

For data communications, the entity location (1 to 9,999) is translated into a 0-based entity address (0 to
9,998) by subtracting 1. For example, in order to read holding registers starting at number 40001, the data
frame will contain function code 3 (as seen above) and address 0. For holding registers starting at number
40100, the address will be 99.

This limits the number of addresses to 9,999 for each entity. A de facto standard extends this to 65,536[14]
by adding one digit to the previous list:

coil numbers span from 000001 to 065536,

discrete input numbers span from 100001 to 165536,
input register numbers span from 300001 to 365536,
holding register numbers span from 400001 to 465536.

When using extended referencing, all number references must have exactly 6 digits to avoid confusion
between coils and other entities. For example, to distinguish between holding register #40001 and coil
#40001, if coil #40001 is the target, it must appear as #040001.

Another way to note the data addresses is to use the hexadecimal value, which clarifies the use of the four
digits in the traditional convention mentioned previously.

coil numbers span from 0x0000 to 0xFFFF

discrete input numbers span from 1x0000 to 1xFFFF
input register numbers span from 3x0000 to 3xFFFF
holding register numbers span from 4x0000 to 4xFFFF

The advantage of this notation is that the same numbers are found when decoding Modbus packets.

JBUS mapping

Another de facto protocol closely related to Modbus appeared later, and was defined by PLC maker April
Automates, the result of a collaborative effort between French companies Renault Automation and Merlin
Gerin et Cie in 1985: JBUS. Differences between Modbus and JBUS at that time (number of entities,
server stations) are now irrelevant as this protocol almost disappeared with the April PLC series, which
AEG Schneider Automation bought in 1994 and then made obsolete. However, the name JBUS has
survived to some extent.

JBUS supports function codes 1, 2, 3, 4, 5, 6, 15, and 16 and thus all the entities described above, although
numbering is different:

Number and address coincide: entity #x has address x in the data frame.
Consequently, entity number does not include the entity type. For example, holding register
#40010 in Modbus will be holding register #9, at address 9 in JBUS.
 Number 0 (and thus address 0) is not supported. The server should not implement any real
data at this number and address, and it can return a null value or throw an error when
requested.

Implementations
Almost every implementation has 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
IEEE 754 floating-point number
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 server addresses
32-bit data size (1 address = 32 bits of data returned)
Word-swapped data

Modbus Plus
Despite the name, Modbus Plus[15] is not a variant of Modbus. It is a different protocol, involving token
passing. It is a proprietary specification of Schneider Electric, though it is unpublished rather than patented.
It is normally implemented using a custom chipset available only to partners of Schneider.

See also
CAN bus

References
1. Drury, Bill (2009). Control Techniques Drives and Controls Handbook (https://app.knovel.co
m/kn/resources/kpCTDCHE08/toc) (PDF) (2nd ed.). Institution of Engineering and
Technology. pp. 508–.
2. "Modbus home page" (https://modbus.org/). Modbus. Modbus Organization, Inc. Retrieved
2 August 2013.
3. "Modbus FAQ" (https://modbus.org/faq.php). Modbus. Modbus Organization, Inc. Retrieved
1 November 2012.
4. "About Modbus Organization" (https://modbus.org/about_us.php). Modbus. Modbus
Organization, Inc. Retrieved 8 November 2012.
5. "Modbus Organization Replaces Master-Slave with Client-Server (press release)" (https://m
odbus.org/docs/Client-ServerPR-07-2020-final.docx.pdf) (PDF). modbus.org. 9 July 2020.
Retrieved 11 July 2023.
 6. Palmer; Shenoi, Sujeet, eds. (23–25 March 2009). Critical Infrastructure Protection III. Third
IFIP WG 11. 10 International Conference. Hanover, New Hampshire: Springer. p. 87.
ISBN 978-3-642-04797-8.
7. "Modbus Application Protocol V1.1b3" (https://modbus.org/docs/Modbus_Application_Proto
col_V1_1b3.pdf) (PDF). Modbus. Modbus Organization, Inc. Retrieved 2 August 2013.
8. Modbus Messaging on TCP/IP Implementation Guide V1.0b (https://modbus.org/docs/Modb
us_Messaging_Implementation_Guide_V1_0b.pdf) (PDF), Modbus Organization, Inc.,
October 24, 2006, retrieved 2017-01-07
9. "Java Modbus Library - About" (http://jamod.sourceforge.net). 2010. Retrieved 2017-02-07.
10. "What is the difference between Modbus and Modbus Plus?" (https://www.se.com/ca/en/faq
s/FA198221/). Schneider Electric. 21 August 2004. Retrieved 2017-02-07.
11. "Simply Modbus - About Enron Modbus" (https://www.simplymodbus.ca/Enron.htm). Simply
Modbus. Retrieved 2017-02-07.
12. Prat, Jérôme (13 February 2017). "Crash Course: Client/Server/Master/Slave" (https://www.p
rosoft-technology.com/insights/technology-focus/#). ProSoft Technology. Retrieved
2022-10-17.
13. Clarke, Gordon; Reynders, Deon (2004). Practical Modern Scada Protocols: Dnp3, 60870.5
and Related Systems (https://books.google.com/books?id=ENqyW8fExswC&pg=PA45).
Newnes. pp. 47–51. ISBN 0-7506-5799-5.
14. "Modbus 101 – Introduction to Modbus" (https://www.csimn.com/CSI_pages/Modbus101.htm
l). Control Solutions, Inc.
15. "Modbus Plus - Modbus Plus Network - Products overview - Schneider Electric United
States" (https://www.se.com/us/en/product-range/576-modbus-plus/). Schneider-
electric.com. Retrieved 2014-01-03.

External links
Specifications

Modbus Organization (https://modbus.org/) – links to protocol specifications

Modbus over serial line V1.02 (https://modbus.org/docs/Modbus_over_serial_line_V1_02.pd
f) – Modbus Organization (2006)
Modicon Modbus Protocol Reference Guide (https://modbus.org/docs/PI_MBUS_300.pdf) –
Modbus Organization (1996). This is an obsolete Modbus specification, should only be used
to address legacy issues.

Other

Modbus for Field Technicians (http://www.modbusbacnet.com/includes/pdf/MODBUS_2010

Nov12.pdf) at modbusbacnet.com
Modbus tutorial (https://www.rfwireless-world.com/Tutorials/Modbus-Protocol-tutorial.html) at
RF Wireless World

Retrieved from "https://en.wikipedia.org/w/index.php?title=Modbus&oldid=1173181062"