Modbus RTU Protocol

Modbus RTU Protocol
Contents
1
Basic Principle of the Bus Access :
2
Transmission Mode RTU
2.1 Bit structure in the Byte:
3
Telegram Frame
3.1 Unit Address
3.2 Function Number
3.3 Data Structure
3.4 CRC
4
Algorithim to Establish the CRC Total
5
Synchronization of Query and
Response
6
Details on Telegram Synchronization
7
Protocol-Services
8
Broadcastmessage:
9
Parameters of the Modbus Protocol
10 Error Handling in general
11 Exception-Response-Telegram
Note:
This is a general description of the MODBUS protocol
in transmission mode „RTU“.
It does not specify the properties of the physical protocol layer or other hardware specific details. Unit specific profile characteristics of concrete Modbus compatible devices are also not covered by this description. For details on the profile of a specific device
please see the relevant manual.
2
TB Modbus RTU 01.02 E
1
Basic Principle of the Bus
Access
The Modbus is operating according to the Master/Slave – principle. Each bus is operated by exactly
one Modbus Master which can exchange data with
the other Modbus Slaves allocated to the bus. The
number of Slaves to be operated on the bus is defined
by the used physics of the bus.
With Modbus each action of the bus viewed follows
the same pattern. Firstly the Master sends a Query
which the Slave has to answer with a Response. Selection of the required Slave is realised by a unit address comprised in the Query and Response function.
This address has to be allocated clearly to any Slave
related to the bus. The Master in its turn has to know
each of the unit addresses on the bus which it wants to
contact.
Query
Master
Response
Slave 1
Slave 2
Figure 1.1: Basic pricicple of the bus access
TB Modbus RTU 01.02 E
3
2
3.1
Transmission Mode RTU
Unit Address
In the transmission mode "RTU" described hereunder,
the appearance of each individual Byte to be transmitted is defined on the lowest logical level as follows :
Coding:
Permissible unit addresses:
Broadcast Address:
2.1
3.2
Bit structure in the Byte:
1 Start Bit
8 Data Bits
1 Parity Bit Even
1 Stop Bit
Function Number
Coding:
Permissible Codes:
A transmitted Byte is coded as:
8 Bit binary value, hexadecimal 0 - 9 and A - F.
The least significant Bit is sent and received first
All devices connected to the bus have to interpret each
transmitted Byte analogously in this manner. Methods
for an automatic recognition of baud rates are not assigned and hence the same baud rate must be used
by the Master as well as all Slaves allocated to the
bus. No specific baud rate is specified by the Modbus; typical baud rates are 9600 or 19200.
3
Telegram Frame
A Modbus telegram consists of the actual utilization information (data structure) which is to be transmitted between Master and Slave. This utilization information is
supplemented by a function number and the unit address. A CRC check number, computed over the fields
"slave address", "function number" and "data structure",
is added as protection against transmission errors.
Telegram Frame as scheme:
Slave
address
Function
code
Data structure
CRC
3.3
8 Bit binary value
1 – 247
0
8 Bit binary value
1 – 255 (private codes,
public codes and reserved
codes)
Data Structure
Coding: binary
Interpretation of the information inside the data structure has to be coordinated between Master and Slave
within the so called unit profile (not subject of this description) as also usual in other transmission protocols
dependent on any specific function number. However,
because the length of the data structure within the
telegram frame is missing, in Modbus the frame recognition of the details concerning assignment between
function number and the related data structure arranged within the unit profile between Master an
Slave is of dependent nature.
3.4
CRC
Protection of the telegram is achieved by a Cyclical
Redundancy Check (CRC) in form of a 16 Bit binary
value. The least significant byte is sent and received
prior to the higher significant byte. The CRC total is
formed across the entire telegram and then appended
at the end.
For both data directions (Query and Response) the
telegram frame is identical.
For the individual sections in the telegram frame the following applies :
4
TB Modbus RTU 01.02 E
4
Algorithim to Establish the CRC Total
CRC_START = FFFF HEX
CRC_REF = A001 HEX
data_byte = 8 bit binary value
CRC_SUM = 16 bit binary value
LSB = least significant bit
CRC_SUM = CRC_START
CRC_SUM := CRC_SUM XOR
data_byte
CRC_SUM AND
1 = 0?
No
Shift result to direction LSB.
Set MSB 0.
Yes
Shift result to direction LSB.
Set MSB 0.
Are all 8bits
processed?
CRC_SUM := CRC_SUM XOR
CRC_REF
No
Yes
Are all bytes in
the telegram
processed?
No
Yes
CRC_SUM
Established
Figure 4.1
TB Modbus RTU 01.02 E
5
5
Synchronization of Query and
Response.
In Modbus there is no special coding used within the
telegram data for telegram synchronization. Telegram
sync is solely achieved by keeping certain chronological correlations. For an easier understanding the succession of Query and Response is represented on a
time beam.
Device
address
Function
code
Data
structure
Device
address
CRC
Function
code
Data
structure
Device
address
CRC
Function
code
Data
structure
CRC
Query 2
Query 1
Response 1
t
tR
tR
tT
Figure 5.1
Query and Response have to be completed within a
fixed time frame to avoid any bus-collision. In connection with telegram synchronization the following times
are of importance :
tT : Timeout status
tR : Bus quiescence time
6
TB Modbus RTU 01.02 E
6
Details on Telegram
Synchronization
After receiving a Query from the Master, the Slave has
to send a Response within a certain time frame.
(Transmitting of “Broadcasts” is an exception of this
rule, because in this case the Slave does not send a
Response).
If there is no Response from the Slave within the time
frame (Time-out), the Master can repeat the Query
several times or a fault condition can be generated in
the Master.
No slave is permitted to send a Response outside the
time frame.
nd
Quiescence time (tR ) of at least
3.5 characters before start of the
telegram
3.5 characters 9600 Baud = 4 ms
3.5 characters 19200 Baud = 2 ms
After a quiescence time of >3.5
characters (tR) the start of a new telegram is expected.
rd
Continuos data flow. When an interruption occurs of more than 1.5 characters (intermitted time), the telegram is
disregarded and the start of a new
telegram is expected.
1.5 characters 9600 Baud = 1.7 ms
1.5 characters 19200 Baud = 0.85 ms
2 Criterion:
3 Criterion:
The following times have to be taken into consideration :
st
1 Criterion:
After the Timeout status(tT) has expired,
the Slave must not send another
response, although the Master can
send a new Query .
1. Diagram for telegram synchronization in the time frame
The data transfer on the bus is illustrated by means of a time beam. In this example the Slave sends the Response
at the very last instant.
tÜQ
tRS max
tÜR
Query 1
Query 2
Response 1
t
tR
tR
tT
t QI
tS1 max
max
tS2
From this diagram results :
tT
tQI max
tS1
tS2
≥
≥
≥
≥
tÜQ + tRSmax + tR + tÜR
tT + tR
tR tS1 max = tRSmax + tR
tR
TB Modbus RTU 01.02 E
7
2. Diagram for telegram synchronization in the time frame
The data transfer on the bus is illustrated by means of a time beam. In this example the Slave sends the Response
and the Master the Query at the earliest instant.
tÜQ
tRS min
tÜR
Query 1
Query 2
Response 1
t
tR
tR
tT
t QI
min
tS1 min
From this diagram results :
tQI min ≥ tÜQ + tRSmin + tR + tÜR + tR
tS1
≥ tR
tS2
≥ tR
tS2 min
tQI min < tT
tS1 min = tRSmin + tR
In order to ascertain the Timeout status(tT), the following times can be defined for the time frame.
Quiescence time (TR):
During the quiescence time no data activities are allowed on the bus. Hence the quiescence time for the
bus has to be kept before each transmission.
The quiescence time depends on the transmission rate.
Transmission times (tÜQ), (tÜR):
The telegram transmission time (Query) from the Master
to the Slave depends on the transmission rate. For calculating the (tÜQ), the longest telegram in this data direction is the basis used by the unit profile.
The telegram transmission time (Response) from the
Slave to the Master depends on the transmission rate.
For calculating the (tÜR), the longest telegram in this
data direction is the basis used by the unit profile.
8
The Slave reaction time (tRS):
The Slave reaction time is the time the Slave needs to
process a Query. It depends on the system activity and
may vary from system to system. Therefore it should be
ascertained and adjusted as tRS max on site.
The Query interval as tQI or the longest Query interval
as tQI max.
The time after a Slave sends its message as ts1 or ts1 max.
The time after a Response until the next Query as ts2.
From these times the maximal needed Timeout status
(tT) can be established as time frame within which the
protocol service has to be completed. This Timeout
status(tT) can then be adjusted at the Master. It is arrived at by : tT max = tÜQ max + tRSmax + tR + tÜR max
TB Modbus RTU 01.02 E
7
Protocol-Services
To put in order the information interchanged between
master and slave, it is useful to subdivide this information into several so called "services". The services differ
in meaning. In principle services can be separated
into two fundamental categories:
1. monitoring services
2. controlling services
It goes without saying that monitoring services do not
change status-information in slaves. Monitoring services may not have any side-effects. The bus master is
allowed to trigger monitoring services an arbitrary
number of times with the slave sending similar results.
In difference to monitoring services, controlling services
are typically used to change internal status-information
in slave-units.
Controlling services are typically confirmed by the addressed Slave (response telegram).
8
9
Parameters of the Modbus
Protocol
Slave:
1. Transmission rate 9600 or 19200 Bit/s
2. Reaction time in the time frame approx.: 50 to
1000 ms (max. Response time, Timeout status)
3. Quiescence time on the bus 3.5 characters
(off-time between telegrams)
4. Intermittent time 1.5 characters
(max.off-time within a telegram)
Master:
1. Transmission rate 9600 or 19200 Bit/s
2. Timeout status in the time frame approx.: 50 to
1000 ms (max. Response timet, Timeout status)
3. Quiescence time on the bus 3.5 characters
(off-time between telegrams)
4. Intermittent time 1.5 characters
(max.off-time within a telegram
Broadcastmessage:
Modbus offers the possibility to handle services with
broadcast-messages. In this case a query telegram is
sent with the "broadcast-slave-address" 0, which will
address all slaves on the bus simultaneously. In this
way it is possible to broadcast information to all connected slaves. The slaves dont have the possibility to
answer to a broadcast-query.
Because the slaves do not answer to a broadcastmessage by a response telegram it is only used by
controlling services. Broadcasting monitoring services
does not make sense at all.
The master is not able to check the process triggered
by a broadcastmassage (unconfirmed service.).
In case of unconfirmed services loss of information is to
be tolerated. If this is unacceptable, broadcast-services
do not have to used at all.
(The services supported by a modbus slave are defined in so called device protocol profile. See also
chapter „Definition of device protocol profiles“).
TB Modbus RTU 01.02 E
9
10 Error Handling in general
This chapter describes protocol error handling in different cases.
While MODBUS-communication between master und
slave takes place, the following error-cases have to be
taken into account:
1. Wrong CRC total encountered (Query telegram
as well as Response telegram):
When detecting a wrong CRC total, the receiver
has to discard the received message. Because of
this, either a slave detecting a wrong CRC total in
a query wont answer to the waiting master or the
master will discard the worthless response. In either case, the waiting master will reach timeoutstatus. After that, he has the possibility of repeating the query.
2. Size of "data-structure" in received telegram not as
expected by the receiving unit:
This means that master and slave are unclear,
how a certain service has to be performed. As
stated earlier, master and slave have to agree
how to interprete the data-structure belonging to
every single service. These agreements have to be
summarized in a so called "protocol-profile" and
should contain no hidden ambiguity at all.
In case of such an error, the received telegram is
to be considered being worthless. A slave detecting such an error will answer with a so called "Exception-response".
Unlike a CRC-error, repeating the query wont
solve the problem. As this is a severe error, no further error-handling can be discussed.
3. Diagram for error handling in the time frame :
The data transfer on the bus is illustrated by means of a time beam. In this example the Slave sends no Response.
For handling of the error, the Master repeats the Query.
tÜQ
tRS max
tÜR
Query 1
Query 1
t
tR
tR
tT
t QI
max
tS2
From this diagram results :
≥ tÜQ + tRSmax + tR + tÜR
tT
tQI max
≥ tT + tR
tS2
≥ tR
10
TB Modbus RTU 01.02 E
11 Exception-Response-Telegram
If the data structure or function number in the telegram
are incorrect, the Slave replies with an „Exception Response“. An error code in the „Exception Response“
describes the generated error.
Exception Response represented as complete telegram
Device address
Function code
Exception code
+ 128
CRC
Explanation:
In an error case, the figure 128 is added to the received function number and it is then returned.
The meaning of the Exception Code is defined in the
protocol profile definition.
For example the Exception Code has the following
meaning:
CODE
01
03
04
05
NAME
Invalid function number
Invalid value
Unknown error
Positive acknowledgement
06
Unit not ready
07
Negative acknowledgement
TB Modbus RTU 01.02 E
MEANING
The received function number is not supported in the unit.
The received value cannot be written.
When processing the Query an unknown error has occured.
The received Query is understood, but the Response is still being
processed. Repeat Query !
The received Query is understood, but is not processed because
the unit is untilized at the moment. Repeat Query !
The received Query initiates a program function which is not
supported in the unit.
11
Woodward SEG GmbH & Co. KG
Krefelder Weg 47 ⋅ D – 47906 Kempen (Germany)
Postfach 10 07 55 (P.O.Box) ⋅ D – 47884 Kempen (Germany)
Phone: +49 (0) 21 52 145 1
Internet
Homepage http://www.woodward-seg.com
Documentation http://doc.seg-pp.com
Sales
Phone: +49 (0) 21 52 145 635 ⋅ Telefax: +49 (0) 21 52 145 354
e-mail: [email protected]
Service
Phone: +49 (0) 21 52 145 614 ⋅ Telefax: +49 (0) 21 52 145 455
e-mail: [email protected]