MODBUS_MANUAL

# MODBUS Manual

##

# Introduction

MODBUS is an application layer messaging protocol, positioned at level 7 of the OSI model, which provides client/server communication between devices connected on different types of buses or networks.
The industry’s serial de facto standard since 1979, MOD BUS continues to enable millions of automation devices to communicate. Today, support for the simple and elegant structure of MODBUS continues to grow. The Internet community can access MODBUS at a reserved system port 502 on the TCP/IP stack.
MODBUS is a request/reply protocol and offers services specified by function codes. MODBUS function codes are elements of MODBUS request/reply PDUs. The objective of this document is to describe the function codes used within the framework of MODBUS transactions.
MODBUS is an application layer messaging protocol for client/server communication between devices connected on different types of buses or networks.
It is currently implemented using:

- TCP/IP over Ethernet

- Asynchronous serial transmission over a variety of media (wire : EIA/TIA -232-E, EIA-422, EIA/TIA-485-A; fiber, radio, etc.)

- MODBUS PLUS, a high speed token passing network

# Protocol description

The MODBUS protocol defines a simple protocol data unit (PDU) independent of the underlying communication layers. The mapping of MODBUS protocol on specific buses or network can introduce some additional fields on the application data unit (ADU).
The MODBUS application data unit is built by the client that initiates a MODBUS transaction. The function indicates to the server what kind of action to perform. The MODBUS application protocol establishes the format of a request initiated by a client.
The function code field of a MODBUS data unit is coded in one byte. Valid codes are in the range of 1 ... 255 decimal (the range 128 – 255 is reserved and used for exception responses). When a message is sent from a Client to a Server device the function code field tells the server what kind of action to perform. Function code "0" is not valid.
Sub-function codes are added to some function codes to define multiple actions.
The data field of messages sent from a client to server devices contains additional information that the server uses to take the action defined by the function code. This can include items like discrete and register addresses, the quantity of items to be handled, and the count of actual data bytes in the field.
The data field may be nonexistent (of zero length) in certain kinds of requests, in this case the server does not require any additional information. The function code alone specifies the action.
If no error occurs related to the MODBUS function requested in a properly received MODBUS ADU the data field of a response from a server to a client contains the data requested. If an error related to the MODBUS function requested occurs, the field contains an exception code that the server application can use to determine the next action to be taken.
For example a client can read the ON / OFF states of a group of discrete outputs or inputs or it can read/write the data contents of a group of registers.
When the server responds to the client, it uses the function code field to indicate either a normal (error-free) response or that some kind of error occurred (called an exception response). For a normal response, the server simply echoes to the request the original function code.
For an exception response, the server returns a code that is equivalent to the original function code from the request PDU with its most significant bit set to logic 1.
Note: It is desirable to manage a time out in order not to indefinitely wait for an answer which will perhaps never arrive.
The size of the MODBUS PDU is limited by the size constraint inherited from the first MODBUS implementation on Serial Line network (max. RS485 ADU = 256 bytes).
Therefore:
MODBUS PDU for serial line communication = 256 - Server address (1 byte) - CRC (2 bytes) = 253 bytes.
Consequently:
RS232 / RS485 ADU = 253 bytes + Server address (1 byte) + CRC (2 bytes) = 256 bytes. TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.
The MODBUS protocol defines three PDUs. They are :
• MODBUS Request PDU, mb_req_pdu
• MODBUS Response PDU, mb_rsp_pdu
• MODBUS Exception Response PDU, mb_excep_rsp_pdu
The mb_req_pdu is defined as:
mb_req_pdu = {function_code, request_data}, where
function_code = [1 byte] MODBUS function code,
request_data = [n bytes] This field is function code dependent and usually contains information such as variable references, variable counts, data offsets, sub-function codes etc.
The mb_rsp_pdu is defined as:
mb_rsp_pdu = {function_code, response_data}, where function_code = [1 byte] MODBUS function code response_data = [n bytes] This field is function code dependent and usually contains information such as variable references, variable counts, data offsets, sub-function codes, etc.
The mb_excep_rsp_pdu is defined as:
mb_excep_rsp_pdu = {exception-function_code, request_data}, where exception-function_code = [1 byte] MODBUS function code + 0x80 exception_code = [1 byte] MODBUS Exception Code Defined in table.

# MODBUS Data model

MODBUS bases its data model on a series of tables that have distinguishing characteristics. The four primary tables are:
The distinctions between inputs and outputs, and between bit -addressable and word-addressable data items, do not imply any application behavior. It is perfectly acceptable, and very common, to regard all four tables as overlaying one another, if this is the most natural interpretation on the target machine in question.
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.
It’s obvious that all the data handled via MODBUS (bits, registers) must be located in device application memory. But physical address in memory should not be confused with data reference. The only requirement is to link data reference with physical address.
MODBUS logical reference numbers, which are used in MODBUS funct ions, are unsigned integer indices starting at zero.

# MODBUS Addressing model

The MODBUS application protocol defines precisely PDU addressing rules.
In a MODBUS PDU each data is addressed from 0 to 65535.
It also defines clearly a MODBUS data model composed of 4 blocks that comprises several elements numbered from 1 to n.
In the MODBUS data Model each element within a data block is numbered from 1 to n.
Afterwards the MODBUS data model has to be bound to the device application ( IEC -61131 object, or other application model).
The pre-mapping between the MODBUS data model and the device application is totally vendor device specific.

# Define MODBUS Transaction

The following state diagram describes the generic processing of a MODBUS transaction in server side.
Once the request has been processed by a server, a MODBUS response using the adequate MODBUS server transaction is built.
Depending on the result of the processing two types of response are built :
A positive MODBUS response :

- the response function code = the request function code

A MODBUS Exception response:

- the objective is to provide to the client relevant information concerning the error detected during the processing

- the exception function code = the request function code + 0x80

- an exception code is provided to indicate the reason of the error.