Editing Modbus (section)

==Protocol description==
[[File:MODBUS communication stack.png|thumb|alt=MODBUS communication stack|MODBUS communication stack]]
Modbus standards or buses include:{{Sfn|MODBUS Application Protocol|2012|p=2}}
* TCP/IP over Ethernet
* Asynchronous serial communication in a wide range of standards, technologies: EIA/TIA-232-E, EIA-422, EIA/TIA-485-A, fiber, radio frequency,...
* MODBUS PLUS, a high speed token passing network.
[[File:MODBUS Network Architecture.png|thumb|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).

=== PDU and ADU ===
Modbus defines a ''client'' which is an entity that initiates a transaction to request any specific task from its ''request receiver''.{{Sfn|MODBUS Application Protocol|2012|p=4|ps=, "4.1 Protocol description"}} The client's "request receiver", which the client has initiated the transaction with, is then called the ''server''.{{Sfn|MODBUS Application Protocol|2012|p=4|ps=, "4.1 Protocol description"}} For example, when a [[Microcontroller unit]] (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. In former terminology, the client was named master and the server named slave.

Modbus defines a [[protocol data unit]] (PDU) independently to its lower layer protocols in its protocol stack. Mapping MODBUS protocol on specific buses or networks requires some additional fields, defined as the application data unit (ADU). The ADU is formed by a ''client'' inside a Modbus network when the client initiates a transaction. Contents are:{{Sfn|MODBUS Application Protocol|2012|p=3|ps=, "4.1 Protocol description"}}
* PDU = Function code + data
* ADU = Additional address + PDU + error check

The ADU is officially called a ''Modbus frame'' by the Modbus Organization,{{Sfn|MODBUS Application Protocol|2012|p=3|ps=, "4.1 Protocol description"}} 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.{{Sfn|MODBUS Application Protocol|2012|p=5|ps=, "4.1 Protocol description"}}

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.{{Sfn|MODBUS Application Protocol|2012|p=5|ps=, "4.1 Protocol description"}}

''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).{{Sfn|MODBUS Application Protocol|2012|p=7|ps=, "4.4 MODBUS Addressing model"}} 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.{{Sfn|MODBUS Application Protocol|2012|p=4|ps=, "4.1 Protocol description"}}

=== Modbus transaction and PDU ===
A Modbus transaction between client and server includes:{{Sfn|MODBUS Application Protocol|2012|p=4|ps=, "4.1 Protocol description"}}{{Sfn|MODBUS Application Protocol|2012|p=9|ps=, "Figure 9 MODBUS Transaction state diagram"}}

* Step 1: Client initiates a request with PDU = Function code + data request
* Step 2: Server receives the request from client. Server will then read/parse the function code, get the address of the data field of the PDU, then get this data field value and finally perform the action based on the function code. If there is no error during those steps, the server will respond with PDU = Function code + data response. As long as there is no error during those steps, the server's responding function code will also be the function code sent from the client. If there is any error during those steps, the server will respond with  PDU = Exception Function code + Exception code (Reference to PDU mb_excep_rsp_pdu defined below).
* Step 3: Client receives the response and ends the transaction.

Based on that, Modbus defines 3 PDU types:{{Sfn|MODBUS Application Protocol|2012|p=5|ps=, "4.1 Protocol description"}}
* MODBUS Request PDU, mb_req_pdu
* MODBUS Response PDU, mb_rsp_pdu
* MODBUS Exception Response PDU, mb_excep_rsp_pdu

: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 values, data offset, and sub-function codes.{{Sfn|MODBUS Application Protocol|2012|p=5|ps=, "4.1 Protocol description"}}

: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 values, data offset, and sub-function codes.{{Sfn|MODBUS Application Protocol|2012|p=5|ps=, "4.1 Protocol description"}}

:mb_excep_rsp_pdu = Exception Function code (1 byte) + exception code (1 byte)
::''Exception Function code'' = Function code (1 byte) + 0x80. ''Exception Function code'' is equal to the Function code, except that its MSB is set to 1.
::Exception code (1 byte) of mb_excep_rsp_pdu is defined in the [[Modbus#Exception responses|MODBUS Exception Codes]] table.

=== Modbus data model ===
Modbus defines its data model based on a series of tables of four primary types:{{Sfn|MODBUS Application Protocol|2012|p=6|ps=, "4.3 MODBUS Data model"}}
{| class="wikitable"
! Primary tables
! Access
! Size
!Features
|-
| Discrete input
| R
|1 bit (0–1)
|Read on/off value
|-
| Coil (discrete output)<ref>{{Cite web |title=Modpoll Modbus Master Simulator |url=https://www.modbusdriver.com/modpoll.html |access-date=2023-10-13 |website=modbusdriver.com |postscript="-t 0" is for "Discrete output (coil) data type"}}</ref>
| R/W
| 1 bit (0–1)
|Read/Write on/off value
|-
|Input register
|R
|16 bit words (0–65,535)
|Read measurements and statuses
|-
|Holding register
|R/W
|16 bit words (0–65,535)
|Read/Write configuration values
|}
For each of the primary tables, the protocol allows individual selection of 65536 data items,
and the operations of read or write of those items are designed to span multiple consecutive
data items up to a data size limit which is dependent on the transaction function code.{{Sfn|MODBUS Application Protocol|2012|p=6|ps=, "4.3 MODBUS Data model"}}