Modbus RTU Protocol

Contents 1 2 3 Basic Principle of the Bus Access : Transmission Mode RTU 2.1 Bit structure in the Byte: Telegram Frame 3.1 Unit Address 3.2 Function Number 3.3 Data Structure 3.4 CRC Algorithim to Establish the CRC Total Synchronization of Query and Response Details on Telegram Synchronization Protocol-Services Broadcastmessage: Parameters of the Modbus Protocol

4 5 6 7 8 9

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.

TB Modbus RTU 01.02 E

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

Transmission Mode RTU

3.1

Unit Address 8 Bit binary value 1 247 0

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

Bit structure in the Byte:

8 Data Bits 1 Parity Bit Even 1 Stop Bit

3.2

Function Number 8 Bit binary value 1 255 (private codes, public codes and reserved codes)

1 Start Bit

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.3 Data Structure

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

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 :

TB Modbus RTU 01.02 E

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? Yes Shift result to direction LSB. Set MSB 0.

No

Shift result to direction LSB. Set MSB 0.

CRC_SUM := CRC_SUM XOR CRC_REF

Are all 8bits processed?

No

Yes

Are all bytes in the telegram processed?

No

Yes
CRC_SUM Established

Figure 4.1

TB Modbus RTU 01.02 E

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 CRC Device address Function code Data structure CRC Device address Function code Data structure CRC

Query 1

Query 2 Response 1

t tR tT tR

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

TB Modbus RTU 01.02 E

Details on Telegram Synchronization

2 Criterion:
nd

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. The following times have to be taken into consideration : 1 Criterion:
st

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

3 Criterion:

rd

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.

tQ

tRS max

tR

Query 1 Response 1

Query 2

t tR tR

tT t QI tS1 max

max

tS2

From this diagram results :

tT tQI max tS1 tS2

tQ + tRSmax + tR + tR tT + tR tR tS1 max = tRSmax + tR tR

7

TB Modbus RTU 01.02 E

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.

tQ

tRS min

tR

Query 1 Response 1

Query 2

t tR tT t QI tS1 min tR

min

tS2 min

From this diagram results : tQI min tQ + tRSmin + tR + tR + tR tS1 tR tS2 tR

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 (tQ), (tR): The telegram transmission time (Query) from the Master to the Slave depends on the transmission rate. For calculating the (tQ), 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 (tR), the longest telegram in this data direction is the basis used by the unit profile.

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 = tQ max + tRSmax + tR + tR max

TB Modbus RTU 01.02 E

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

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

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.

tQ

tRS max

tR

Query 1

Query 1

t tR tR

tT t QI

max

tS2

From this diagram results : tQ + tRSmax + tR + tR 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
Function code Exception code + 128

Device address

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 06 07 NAME Invalid function number Invalid value Unknown error Positive acknowledgement Unit not ready Negative acknowledgement 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.

TB Modbus RTU 01.02 E

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: kemp.electronics@woodward.com Service Phone: +49 (0) 21 52 145 614 Telefax: +49 (0) 21 52 145 455 e-mail: kemp.pd@woodward.com