Modbus or MODBUS is a client/server data communications protocol in the application layer.[1] It was originally published by Modicon (now Schneider Electric) in 1979 for use with its programmable logic controllers (PLCs).[2] Modbus has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and network.[3][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 serial communication lines, Ethernet, or the Internet protocol suite as a transport layer.[1] 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[4] since April 2004, when Schneider Electric transferred rights to that organization.[5] The Modbus Organization is an association of users and suppliers of Modbus-compliant devices that advocates for the continued use of the technology.[6] Modbus Organization, Inc. is a trade association for the promotion and development of the Modbus protocol.[4]

Protocol description

MODBUS communication stack
MODBUS communication stack

Modbus standards or buses include:[1]

Architecture of a network for Modbus communication

To support Modbus communication on a network, many modems and gateways incorporate proprietary designs (refer to the diagram: Architecture of a network for Modbus communication). Implementations may deploy either wireline or wireless communication, such as in the ISM radio band, and even Short Message Service (SMS) or General Packet Radio Service (GPRS).


Modbus defines client which is an entity which initiates a transaction to request any specific task from its "request receiver".[7] The client's "request receiver", which the client has initiated the transaction with, is then called server.[7] For example, when a MCU connects to a sensor to read its data by Modbus on a wired network, e.g RS485 bus, the MCU in this context is the client and the sensor is the server.

Modbus defines a protocol data unit (PDU) independently to its lower layer protocols in its protocol stack. The mapping of MODBUS protocol on specific buses or network requires some additional fields, which are defined as application data unit (ADU). ADU is formed by a client inside a Modbus network when the client initiates a transaction. Contents are:[8]

ADU is officially called a Modbus frame by the Modbus Organization,[8] although frame is used as the data unit in the data-link layer in the OSI and TCP/IP model (while Modbus is an application layer protocol).

PDU max size is 253 bytes. ADU max size on RS232/RS485 network is 256 bytes, and with TCP is 260 bytes.[9]

For data encoding, Modbus uses a big-endian representation for addresses and data fields. Thus, for a 16-bit value, the most significant byte is sent first. For example, when a 16-bit register has value 0x1234, byte 0x12 is sent before byte 0x34.[9]

Function code is 1 byte which gives the code of the function to execute. Function codes are integer values, ranging from 1 to 255, and the range from 128 to 255 is for exception responses.

The data field of the PDU has the address from 0 to 65535 (not to be confused with the address of the Additional address field of ADU).[10] The data field of the PDU can be empty, and then has a size of 0. In this case, the server will not request any information and the function code defines the function to be executed. If there is no error during the execution process, the data field of the ADU response from server to client will include the data requested, i.e. the data the client previously received. If there is any error, the server will respond with an exception code.[7]

Modbus transaction and PDU

A Modbus transaction between client and server includes:[7][11]

Based on that, Modbus defines 3 PDU types:[9]

mb_req_pdu = Function code (1 byte) + request data (n bytes)

request data field's size depends on the function code and usually includes values like variable's value, data offset, sub-function codes,...

mb_rsp_pdu = Function code (1 byte) + response data (n bytes)

As in mb_req_pdu, response data field's size depends on the function code and usually includes values like variable's value, data offset, sub-function codes,...

mb_excep_rsp_pdu = Exception Function code (1 byte) + exception code (1 byte)

Exception Function code = Function code (1 byte) + 0x80

Exception Function code will then have MSB bit is 1, and its left bit is equal to the Function code.

Exception code (1 byte) of mb_excep_rsp_pdu is defined in the "MODBUS Exception Codes" table.

Modbus data model

Modbus defines its data model based on a series of table with four primary tables:[12]

Primary tables Access Size Features
Coil (discrete output)[13] Read-write 1 bit Read/Write on/off value
Discrete input Read-only 1 bit Read on/off value
Input register Read-only 16 bits (0–65,535) Read measurements and statuses
Holding register Read-write 16 bits (0–65,535) Read/Write configuration values

Function code

Modbus defines three types of function codes: Public, User-Defined and Reserved.[14]

Public function codes

Function type Function name Function code Comment
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 Registers 4
Internal Registers or Physical Output Registers Read Multiple Holding Registers 3
Write Single Holding Register 6
Write Multiple Holding 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 serial only
Diagnostic 8 serial only
Get Com Event Counter 11 serial only
Get Com Event Log 12 serial only
Report Server ID 17 serial only
Read Device Identification 43
Other Encapsulated Interface Transport 43

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

Function code 01 (read coils) as an example of public function code

Function code 01 (read coils) allow reading the state from 1 to 2000 coil of a remote device. mb_req_pdu (request PDU) will then have 2 bytes to indicate the address of the first coil to read (from 0x0000 to 0xFFFF), and 2 bytes to indicate the number of coils to read. mb_req_pdu defines coil address by index 0, i.e the 1st coil (the very first coil) has address 0x0. mb_rsp_pdu (response PDU) - if reading successfully - has 1 byte to indicate the number of bytes which is the number of coils that mb_req_pdu has required, and the left bytes store the status (on/off value) of those requested coils.[16] Specifically, mb_rsp_pdu and mb_rsp_pdu of function code 01 is:[16]



For instance, mb_req_pdu and mb_rsp_pdu to read coils status from 20-38 will be:[17]


Starting Address (2 bytes) is 0x0013, (or 19 in decimal) which is the 20th coil.

Quantity of Outputs (2 bytes) is 0x0013, (or 19 in decimal) which corresponds to 19 values of status of coils 20th to 38th.


As 19 coils (20-38) are required, 3 bytes is used to indicate the coil's state. So that Byte Count is 0x03. States of coil from 20 to 27 is 0xCD, which is 1100 1101 in binary. So coil 27 is MSb, and coil 20 is LSb. Same for coil 28 to 35. With coil from 36 to 38, the state will be 0x05, which is 0000 0101. Coil 38 state is the 3rd bit (count from the right), i.e 1, coil 37 is 0, and coil 36 state is LSb bit, i.e. 1. 5 left bits are all 0.

User-defined function codes

User-Defined Function Codes are function codes defined by users. Modbus gives two range of values for user-defined function codes: 65 to 72 and 100 to 110. Obviously, user-defined function codes are not unique.[14]

Reserved function codes

Reserved Function Codes are function codes used by some companies for legacy product and are not available for public use.[14]

Exception responses

When a client sends a request to a server, there can be four possible events for that request:[18]

Exception response message includes two other fields when compared to a normal response message:[18]

All Modbus exception code:[19]

Code Text Details
1 Illegal Function Function code received in the query is not recognized or allowed by server
2 Illegal Data Address Data address of some or all the required entities are not allowed or do not exist in server
3 Illegal Data Value Value is not accepted by server
4 Server Device Failure Unrecoverable error occurred while server was attempting to perform requested action
5 Acknowledge 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 the client. client can next issue a Poll Program Complete message to determine whether processing is completed
6 Server Device Busy Server is engaged in processing a long-duration command; client should retry later
7 Negative Acknowledge Server cannot perform the programming functions; client should request diagnostic or error information from server
8 Memory Parity Error Server detected a parity error in memory; client can retry the request
10 Gateway Path Unavailable Specialized for Modbus gateways: indicates a misconfigured gateway
11 Gateway Target Device Failed to Respond Specialized for Modbus gateways: sent when server fails to respond

Modbus over Serial Line protocol

Modbus standard also defines Modbus over Serial Line, a protocol over the data link layer of the OSI model for the Modbus application layer protocol to be communicated over a serial bus.[20] Modbus Serial Line protocol is a master-slave protocol which supports one master and multiple slaves in the serial bus.[21] With Modbus protocol on the application layer, client/server model is used for the devices on the communication channel. With Modbus over Serial Line, client's role is implemented by master, and the server's role is implemented by slave.[21][22]

The organization's naming convention inverts the common usage of having multiple clients and only one server. 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".[22]

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).

A serial bus for Modbus over Serial Line can have a maximum of 247 slaves communicating with 1 master. Those slaves have a unique address ranging from 1 to 247 (decimal value).[23] The master doesn't need to have an address.[23] The communication process is initiated by the master, as only it can initiate a Modbus transaction. A slave will never transmit any data or perform any action without a request from the master, and slaves cannot communicate with each other.[24]

In Modbus over Serial Line, the master initiates requests to the slaves in unicast or broadcast modes. In unicast mode, the master will initiate a request to a single slave with a specific address. Upon receiving and finishing the request, the slave will respond with a message to the master.[23] In this mode, a Modbus transaction includes two messages: one request from the master and one reply from the slave. Each slave must have a unique address (from 1 to 247) to be addressed independently for the communication.[23] In broadcast mode, the master can send a request to all the slaves, using the broadcast address 0,[23] which is the address reserved for broadcast exchanges (and not the master address). Slaves must accept broadcast exchanges but must not respond.[24] The mapping of PDU of Modbus to the serial bus of Modbus over Serial Line protocol results in Modbus Serial Line PDU.[23]

Modbus Serial Line PDU = Address + PDU + CRC (or LRC)

With PDU = Function code + data

On the Physical layer, MODBUS over Serial Line performs its communication on bit by RS485 or RS232, with TIA/EIA-485 Two-Wire interface as the most popular way. RS485 Four-Wire interface is also used. TIA/EIA-232-E (RS232) can also be used but is limited to point-to-point short-range communication.[21] MODBUS over Serial Line has two transmission modes RTU and ASCII which are corresponded to two versions of the protocol, known as Modbus RTU and Modbus ASCII.[25]

Modbus RTU

Modbus RTU (Remote Terminal Unit), which is the most common implementation available for Modbus, 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. Every 1 byte (8 bit) data/message of Modbus RTU needs to have 3 more bits to form the total 11 bits:[3][25]

A Modbus RTU frame then will be:[26]

Slave address Function Code Data CRC
1 byte 1 byte 0 - 252 byte 2 bytes: 1 CRC Low byte and 1 CRC High byte

The CRC calculation is widely known as CRC-16-MODBUS whose polynomial is x16 + x15 + x2 + 1 (normal hexadecimal algebraic polynomial being 8005 and reversed A001).[27]

Example of a Modbus RTU 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).

To ensure the Modbus frame integrity during the transmission, the time interval between two frames must be at least equal to the transmission time of 3.5 characters, and the time interval between two consecutive characters must be no more than the transmission time of 1.5 characters.[26]

For example with the default baudrate of 19200 bps, the transmission time of 3.5 (t3.5) and 1.5 (t1.5) characters are (note that each 8-bit character requires 3 extra framing bits to be transmitted):

For higher baudrates, Modbus RTU recommends to use the fixed values 750µs for t1.5 and 1.750ms for t3.5.[26]

Modbus ASCII

Modbus ASCII 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).

A Modbus ASCII frame includes:[28]

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 Messaging on TCP/IP

Modbus TCP

Modbus TCP or Modbus TCP/IP is a Modbus variant used for communications over TCP/IP networks, connecting over port 502.[29] It does not require a checksum calculation, as lower layers already provide checksum protection.

Modbus TCP nomenclature is the same as for the Modbus over Serial line protocol, as any device which send out a Modbus command, is the 'client' and the response comes from a 'server'.[30]

The ADU for Modbus TCP is officially called MODBUS TCP/IP ADU (or Modbus TCP/IP ADU) by the Modbus organization[31] and is also called Modbus TCP frame by other parties.[3]

MODBUS TCP/IP ADU = MBAP Header + Function code + Data

Where MBAP - which stands for MODBUS Application Protocol header - is the dedicated header used on TCP/IP to identify the MODBUS Application Data Unit.

The MBAP Header contains the following fields:[32]

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), treated like slave address in Modbus over Serial line

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.

A MODBUS TCP/IP ADU/Modbus TCP frame format then will be:[32][31]

Transaction identifier Protocol identifier Length Unit identifier Function code Data
2 bytes 2 bytes 2 bytes 1 byte 1 byte n bytes

Example of a Modbus TCP/IP ADU/Modbus TCP frame in hexadecimal:

12 34 00 00 00 06 01 03 00 01 00 01

Other Modbus protocol versions over TCP/IP

Other Modbus protocol versions

Besides the widely used Modbus RTU, Modbus ASCII and Modbus TCP, there are many variants of Modbus protocols:

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.

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:


See also


  1. ^ a b c d MODBUS Application Protocol 2012, p. 2.
  2. ^ MODICON, Inc. 1996, "Preface"
  3. ^ a b c Drury, Bill (2009). Control Techniques Drives and Controls Handbook (PDF) (2nd ed.). Institution of Engineering and Technology. pp. 508–.
  4. ^ a b "Modbus home page". Modbus. Modbus Organization, Inc. Retrieved 2 August 2013.
  5. ^ "Modbus FAQ". Modbus. Modbus Organization, Inc. Retrieved 1 November 2012.
  6. ^ "About Modbus Organization". Modbus. Modbus Organization, Inc. Retrieved 8 November 2012.
  7. ^ a b c d MODBUS Application Protocol 2012, p. 4, "4.1 Protocol description"
  8. ^ a b MODBUS Application Protocol 2012, p. 3, "4.1 Protocol description"
  9. ^ a b c MODBUS Application Protocol 2012, p. 5, "4.1 Protocol description"
  10. ^ MODBUS Application Protocol 2012, p. 7, "4.4 MODBUS Addressing model"
  11. ^ MODBUS Application Protocol 2012, p. 9, "Figure 9 MODBUS Transaction state diagram"
  12. ^ MODBUS Application Protocol 2012, p. 6, "4.3 MODBUS Data model"
  13. ^ "Modpoll Modbus Master Simulator". Retrieved 2023-10-13"-t 0" is for "Discrete output (coil) data type"((cite web)): CS1 maint: postscript (link)
  14. ^ a b c MODBUS Application Protocol 2012, p. 10, "5 Function Code Categories"
  15. ^ Clarke, Gordon; Reynders, Deon (2004). Practical Modern Scada Protocols: Dnp3, 60870.5 and Related Systems. Newnes. pp. 47–51. ISBN 0-7506-5799-5.
  16. ^ a b MODBUS Application Protocol 2012, p. 11
  17. ^ MODBUS Application Protocol 2012, p. 12, "6.1 01 (0x01) Read Coils"
  18. ^ a b MODBUS Application Protocol 2012, p. 47, "7 MODBUS Exception Responses"
  19. ^ MODBUS Application Protocol 2012, p. 48, "7 MODBUS Exception Responses"
  20. ^ MODBUS over Serial Line protocol 2006, p. 4
  21. ^ a b c MODBUS over Serial Line protocol 2006, p. 5
  22. ^ a b c "Modbus Organization Replaces Master-Slave with Client-Server (press release)" (PDF). 9 July 2020. Retrieved 11 July 2023.
  23. ^ a b c d e f MODBUS over Serial Line protocol 2006, p. 8
  24. ^ a b MODBUS over Serial Line protocol 2006, p. 7
  25. ^ a b MODBUS over Serial Line protocol 2006, p. 12
  26. ^ a b c MODBUS over Serial Line protocol 2006, p. 13, " MODBUS Message RTU Framing"
  27. ^ MODBUS over Serial Line protocol 2006, p. 39
  28. ^ MODBUS over Serial Line protocol 2006, p. 17, " MODBUS Message ASCII Framing"
  29. ^ MODBUS Messaging on TCP/IP 2006, p. 6
  30. ^ Prat, Jérôme (13 February 2017). "Crash Course: Client/Server/Master/Slave". ProSoft Technology. Retrieved 2022-10-17.
  31. ^ a b MODBUS Messaging on TCP/IP 2006, p. 4, "3.1.2 MODBUS On TCP/IP Application Data Unit"
  32. ^ a b MODBUS Messaging on TCP/IP 2006, p. 5, "3.1.3 MBAP Header description"
  33. ^ "Java Modbus Library - About". 2010. Retrieved 2017-02-07.
  34. ^ "What is the difference between Modbus and Modbus Plus?". Schneider Electric. 21 August 2004. Retrieved 2017-02-07.
  35. ^ "Modbus Plus - Modbus Plus Network - Products overview - Schneider Electric United States". Retrieved 2014-01-03.
  36. ^ "Simply Modbus - About Enron Modbus". Simply Modbus. Retrieved 2017-02-07.
  37. ^ 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.

Works cited