INTRODUCTION

TO
MODBUS
PROTOCOL

SHIVAM
SINGH

+91-

8527199116

OVERVIEWABBREVIATIONS

ADU: Application Data Unit

IETF: Internet Engineering Task Force

IP: Internet Protocol

MAC: Medium Access Control

MB: MODBUS

MBAP: MODBUS Application Protocol

PDU: Protocol Data Unit

PLC: Programmable Logic Controller

TCP: Transport Control Protocol

BSD: Berkeley Software Distribution

MSL: Maximum Segment Lifetime

OVERVIEW

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 industrys serial de facto standard since 1979, MODBUS 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.

OVERVIEW
It is currently implemented
using:

TCP/IP over Ethernet.

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

MODBUS PLUS, a high speed

token passing network.

Network Architecture of MODBUSEvery type of devices (PLC, HMI,

Control Panel, Driver, Motion control,
I/O Device) can use MODBUS
protocol to initiate a remote
operation.

The same communication can be

done as well on serial line as on an
Ethernet TCP/IP networks. Gateways
allow a communication between
several types of buses or network
using the MODBUS protocol.

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

Protocol Description

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.

Protocol Description

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.

Protocol Description

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.

Protocol Description

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.

MODBUS TCP/IPA communicating system over

MODBUS
TCP/IP
may
include
different types of device:

A MODBUS TCP/IP Client and

Server devices connected to a
TCP/IP network

The Interconnection devices like

bridge, router or gateway for
interconnection
between
the
TCP/IP network and a serial line
sub-network
which
permit
connections of MODBUS Serial line
Client and Server end devices.

MODBUS Data ModelMODBUS 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.

MODBUS Addressing ModelThe 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 (IEC61131 object, or other application model).

The pre-mapping between the MODBUS

data model and the device application is
totally vendor device specific.

Modbus Component Architecture

ModelCommunication Application Layer - A MODBUS device may provide a client
and/or a server MODBUS interface. A MODBUS backend interface can be
provided allowing indirectly the access to user application objects. Four
areas can compose this interface: input discrete, output discrete (coils),
input registers and output registers. A pre-mapping between this interface
and the user application data has to be done (local issue).
MODBUS Client - The MODBUS Client allows the user application to explicitly
control information exchange with a remote device. The MODBUS Client
builds a MODBUS request from parameter contained in a demand sent by the
user application to the MODBUS Client Interface. The MODBUS Client uses a
MODBUS transaction whose management includes waiting for and processing
of a MODBUS confirmation.
MODBUS Client Interface - The MODBUS Client Interface provides an interface
enabling the user application to build the requests for various MODBUS
services including access to MODBUS application objects. The MODBUS Client
interface (API) is not part of this Specification, although an example is
described in the implementation model.

Modbus Component Architecture

Model.
MODBUS Server - On reception
of a MODBUS request this
module activates a local
action to read, to write or to
achieve some other actions.
The processing of these
actions
is
done
totally
transparently
for
the
application programmer. The
main MODBUS server functions
are to wait for a MODBUS
request on 502 TCP port, to
treat this request and then to
build a MODBUS response
depending on device context.

Modbus Component Architecture

Model.
MODBUS Backend Interface - The MODBUS Backend Interface is an
interface from the MODBUS Server to the user application in which
the application objects are defined.

Modbus Component Architecture

Model.
TCP Management Layer Establishment, ending and to manage the data flow on
established TCP connections.
Connection Management - A communication between a client and server MODBUS
Module requires the use of a TCP connection management module. It is in charge
to manage globally messaging TCP connections.
The listening TCP port 502 is reserved for MODBUS communications. Two
possibilities are proposed for the connection management. Either the user
application itself manages TCP connections or the connection management is
totally done by this module and therefore it is transparent for the user
application. The last solution implies less flexibility.
It is mandatory to listen by default on that port. However, some markets or
applications might require that another port is dedicated to MODBUS over TCP.
For that reason, it is highly recommended that the clients and the servers give
the possibility to the user to parameterize the MODBUS over TCP port number. It
is important to note that even if another TCP server port is configured for
MODBUS service in certain applications, TCP server port 502 must still be
available in addition to any application specific ports.

Modbus Component Architecture

Model.
Access Control Module - In certain critical contexts, accessibility to
internal data of devices must be forbidden for undesirable hosts. Thats
why a security mode is needed and security process may be implemented
if required.
TCP/IP Stack Layer - The TCP/IP stack can be parameterized in order to
adapt the data flow control, the address management and the connection
management to different constraints specific to a product or to a system.
Generally the BSD socket interface is used to manage the TCP
connections.
Resource Management and Data Flow Control - In order to equilibrate
inbound and outbound messaging data flow between the MODBUS client
and the server, data flow control mechanism is provided in all layers of
MODBUS messaging stack.
The resource management and flow control module is first based on TCP
internal flow control added with some data flow control in the data link
layer and also in the user application level

The Two Serial Transmission Modes

Controllers can be setup to communicate on standard Modbus

networks using either of two transmission modes: ASCII or RTU.
Users select the desired mode, along with the serial port
communication parameters (baud rate, parity mode, etc.), during
configuration of each controller.

The mode and serial parameters must be the same for all devices
on a Modbus network. The selection of ASCII or RTU mode
pertains only to standard Modbus networks.

It defines the bit contents of message fields transmitted serially

on those networks. It determines how information will be packed
into the message fields and decoded.

On other networks like MAP and Modbus Plus, Modbus messages

are placed into frames that are not related to serial transmission.

For example, a request to read holding registers can be handled

between two controllers on Modbus.

The Two Serial Transmission Modes..

ASCII ModeWhen controllers are setup to communicate on a Modbus network using
ASCII (American Standard Code for Information Interchange) mode, each
8bit byte in a message is sent as two ASCII characters. The main
advantage of this mode is that it allows time intervals of up to one second
to occur between characters without causing an error.
The format for each byte in ASCII mode is:
Coding System: Hexadecimal, ASCII characters 09, AF. One hexadecimal
character contained in each ASCII character of the message.
Bits per Byte: 1 start bit
7 data bits, least significant bit sent first
1 bit for even/odd parity; no bit for no parity
1 stops bit if parity is used; 2 bits if no parity
Error Check Field: Longitudinal Redundancy Check (LRC)

The Two Serial Transmission Modes..

RTU ModeWhen controllers are setup to communicate on a Modbus network using RTU
(Remote Terminal Unit) mode, each 8bit byte in a message contains two 4bit
hexadecimal characters. The main advantage of this mode is that its greater
character density allows better data throughput than ASCII for the same baud
rate. Each message must be transmitted in a continuous stream.
The format for each byte in RTU mode is:
Coding System: 8bit binary, hexadecimal 09, AF. Two hexadecimal characters
contained in each 8bit field of the message.
Bits per Byte: 1 start bit
8 data bits, least significant bit sent first
1 bit for even/odd parity; no bit for no parity
1 stops bit if parity is used; 2 bits if no parity
Error Check Field: Cyclical Redundancy Check (CRC)