Modicon
`Modbus Protocol
`Reference Guide
`
`PI–MBUS–300 Rev. J
`
`1
`
`

`

`Modicon
`Modbus Protocol
`Reference Guide
`
`PI–MBUS–300 Rev. J
`
`June 1996
`
`MODICON, Inc., Industrial Automation Systems
`One High Street
`North Andover, Massachusetts 01845
`
`DOK-
`
`3
`
`ii
`
`

`

`Preface
`
`This guide is written for the person who will use Modicon Modbus protocols and
`messages for communication in Modicon programmable controller applications.
`It describes how messages are constructed, and how transactions take place
`using Modbus protocol.
`
`This guide should be used in conjunction with Modicon user guides for the types
`of networks and programmable controllers present in the application. Familiarity
`with your network layout, and with your control application, is assumed.
`
`The data and illustrations in this book are not binding. We reserve the right to
`modify our products in line with our policy of continuous product improvement.
`Information in this document is subject to change without notice and should not
`be construed as a commitment by Modicon, Inc., Industrial Automation Systems.
`
`Modicon, Inc. assumes no responsibility for any errors that may appear in this
`document. If you have any suggestions for improvements, or have found any
`errors in this publication, please notify us.
`
`No part of this document may be reproduced in any form or by any means,
`electronic or mechanical, without the express written permission of Modicon, Inc.,
`Industrial Automation Systems. All rights reserved.
`
`The following are trademarks of Modicon, Inc.:
`
`SM85
`SQ85
`
`P190
`984
`Modbus
`RR85
`BM85
`ModConnect
`SA85
`BP85
`Modcom
`DEC is a registered trademark of Digital Equipment Corporation.
`VAX and DECNET are trademarks of Digital Equipment Corporation.
`IBM is a registered trademark of International Business Machines Corporation.
`IBM AT, IBM XT, Micro Channel, and Personal System/2 are trademarks
`of International Business Machines Corporation.
`Microsoft and MS–DOS are registered trademarks of Microsoft Corporation.
`Western Digital is a registered trademark of Western Digital Corporation.
`Ethernet is a trademark of Xerox Corporation.
`Copyright  1996, Modicon, Inc.
`Printed in U. S. A.
`
`PI-MBUS–300
`
`Preface
`
`iii
`
`

`

`Related Publications
`
`Refer to the following publication for details about the application of Modicon 984
`Programmable Controller systems:
`
`GM–0984–SYS
`
`984 Programmable Controller Systems Manual.
`Modicon, Inc.
`
`Refer to the following publications for details about the application and installation
`of the Modbus Plus network and related communications devices:
`
`GM–MBPL–001
`
`Modbus Plus Network Planning and Installation Guide.
`Modicon, Inc.
`
`GM–BM85–001
`
`Modbus Plus Bridge/Multiplexer User’s Guide.
`Modicon, Inc.
`
`Refer to the following publication for details about the Modcom III Communications
`Software Library for host computer applications:
`
`GM–MC3A–001 Modcom III Communications Software Library User’s Guide.
`Modicon, Inc.
`
`iv
`
`Related Publications
`
`PI-MBUS–300
`
`

`

`Contents
`
`Chapter 1 Modbus Protocol
`
`. . . . . . . . . . . . . . . . . . . . . . .
`
`1
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Introducing Modbus Protocol
`Transactions on Modbus Networks
`. . . . . . . . . . . . . . . . . . . . . . . . .
`Transactions on Other Kinds of Networks
`. . . . . . . . . . . . . . . . . . .
`The Query–Response Cycle
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`The Two Serial Transmission Modes
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`ASCII Mode
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`RTU Mode
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Modbus Message Framing
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`ASCII Framing
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`RTU Framing
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`How the Address Field is Handled
`. . . . . . . . . . . . . . . . . . . . . . . . . .
`How the Function Field is Handled
`. . . . . . . . . . . . . . . . . . . . . . . . .
`Contents of the Data Field
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Contents of the Error Checking Field
`. . . . . . . . . . . . . . . . . . . . . . .
`How Characters are Transmitted Serially
`. . . . . . . . . . . . . . . . . . . .
`Error Checking Methods
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Parity Checking
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`LRC Checking
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`CRC Checking
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`2
`4
`4
`5
`6
`6
`7
`8
`8
`9
`10
`10
`11
`12
`13
`14
`14
`15
`16
`
`PI–MBUS–300
`
`Contents
`
`vii
`
`

`

`Chapter 2 Data and Control Functions
`
`. . . . . . . . . . . . .
`
`17
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Modbus Function Formats
`How Numerical Values are Expressed
`. . . . . . . . . . . . . . . . . . . . . .
`Data Addresses in Modbus Messages
`. . . . . . . . . . . . . . . . . . . . . .
`Field Contents in Modbus Messages
`. . . . . . . . . . . . . . . . . . . . . . .
`Field Contents on Modbus Plus
`. . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Function Codes Supported by Controllers
`. . . . . . . . . . . . . . . . . . . . . . . . .
`01 Read Coil Status
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`02 Read Input Status
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`03 Read Holding Registers
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`04 Read Input Registers
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`05 Force Single Coil
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`06 Preset Single Register
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`07 Read Exception Status
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`11 (0B Hex) Fetch Comm Event Ctr
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`12 (0C Hex) Fetch Comm Event Log
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`15 (0F Hex) Force Multiple Coils
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`16 (10 Hex) Preset Multiple Regs
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`17 (11 Hex) Report Slave ID
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`20 (14Hex) Read General Reference
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`21 (15Hex) Write General Reference
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`22 (16Hex) Mask Write 4X Register
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`23 (17Hex) Read/Write 4X Registers
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`24 (18Hex) Read FIFO Queue
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`18
`18
`18
`18
`20
`22
`24
`26
`28
`30
`32
`34
`36
`38
`40
`44
`46
`48
`58
`62
`66
`68
`70
`
`viii
`
`Contents
`
`PI–MBUS–300
`
`

`

`Chapter 3 Diagnostic Subfunctions
`
`. . . . . . . . . . . . . . . .
`
`73
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Function 08 – Diagnostics
`Diagnostic Codes Supported by Controllers
`. . . . . . . . . . . . . . . . . . . . . . . .
`Diagnostic Subfunctions
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`00 Return Query Data
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`01 Restart Communications Option
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`02 Return Diagnostic Register
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`03 Change ASCII Input Delimiter
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`04 Force Listen Only Mode
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`10 (0A Hex) Clear Counters and Diagnostic Register
`. . . . . . . . . . . . . . .
`11 (0B Hex) Return Bus Message Count
`. . . . . . . . . . . . . . . . . . . . . . . . . .
`12 (0C Hex) Return Bus Communication Error Count
`. . . . . . . . . . . . . . .
`13 (0D Hex) Return Bus Exception Error Count
`. . . . . . . . . . . . . . . . . . . .
`14 (0E Hex) Return Slave Message Count
`. . . . . . . . . . . . . . . . . . . . . . . .
`15 (0F Hex) Return Slave No Response Count
`. . . . . . . . . . . . . . . . . . . .
`16 (10 Hex) Return Slave NAK Count
`. . . . . . . . . . . . . . . . . . . . . . . . . . . .
`17 (11 Hex) Return Slave Busy Count
`. . . . . . . . . . . . . . . . . . . . . . . . . . . .
`18 (12 Hex) Return Bus Character Overrun Count
`. . . . . . . . . . . . . . . . .
`19 (13 Hex) Return IOP Overrun Count (884)
`. . . . . . . . . . . . . . . . . . . . .
`20 (14 Hex) Clear Overrun Counter and Flag (884)
`. . . . . . . . . . . . . . . . .
`21 (15 Hex) Get/Clear Modbus Plus Statistics
`. . . . . . . . . . . . . . . . . . . . .
`Modbus Plus Network Statistics
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`74
`76
`77
`77
`77
`78
`81
`81
`81
`82
`82
`82
`83
`83
`83
`84
`84
`84
`85
`86
`87
`
`Appendix A Exception Responses
`
`. . . . . . . . . . . . . . . . .
`
`93
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Exception Responses
`Exception Codes
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`94
`96
`
`Appendix B Application Notes
`
`. . . . . . . . . . . . . . . . . . . . .
`
`99
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . .
`Maximum Query/Response Parameters
`Estimating Serial Transaction Timing
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Notes for the 584 and 984A/B/X
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`100
`106
`108
`
`Appendix C LRC/CRC Generation
`
`. . . . . . . . . . . . . . . . .
`
`109
`
`LRC Generation
`CRC Generation
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`110
`112
`
`PI–MBUS–300
`
`Contents
`
`ix
`
`

`

`Figures
`
`. . . . . . . . . . . . . . .
`Figure 1 Overview of Modbus Protocol Application
`Figure 2 Master–Slave Query–Response Cycle
`. . . . . . . . . . . . . . . . . .
`Figure 3 ASCII Message Frame
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 4 RTU Message Frame
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 5 Bit Order (ASCII)
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 6 Bit Order (RTU)
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 7 Master Query with ASCII/RTU Framing
`. . . . . . . . . . . . . . . . .
`Figure 8 Slave Response with ASCII/RTU Framing
`. . . . . . . . . . . . . . .
`Figure 9 Field Contents on Modbus Plus
`. . . . . . . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 10 Read Coil Status – Query
`Figure 11 Read Coil Status – Response
`. . . . . . . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 12 Read Input Status – Query
`Figure 13 Read Input Status – Response
`. . . . . . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . .
`Figure 14 Read Holding Registers – Query
`Figure 15 Read Holding Registers – Response
`. . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . . . .
`Figure 16 Read Input Registers – Query
`Figure 17 Read Input Registers – Response
`. . . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 18 Force Single Coil – Query
`Figure 19 Force Single Coil – Response
`. . . . . . . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . . .
`Figure 20 Preset Single Register – Query
`Figure 21 Preset Single Register – Response
`. . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . .
`Figure 22 Read Exception Status – Query
`Figure 23 Read Exception Status – Response
`. . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . .
`Figure 24 Fetch Communications Event Counter – Query
`Figure 25 Fetch Communications Event Counter – Response
`. . . . . .
`
`. . . . . . . . . . . . .
`Figure 26 Fetch Communications Event Log – Query
`Figure 27 Fetch Communications Event Log – Response
`. . . . . . . . .
`
`3
`5
`8
`9
`13
`13
`19
`19
`21
`
`24
`25
`
`26
`27
`
`28
`29
`
`30
`31
`
`32
`33
`
`34
`35
`
`36
`37
`
`38
`39
`
`40
`41
`
`x
`
`Contents
`
`PI–MBUS–300
`
`

`

`. . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 28 Force Multiple Coils – Query
`Figure 29 Force Multiple Coils – Response
`. . . . . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . .
`Figure 30 Preset Multiple Registers – Query
`Figure 31 Preset Multiple Registers – Response
`. . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 32 Report Slave ID – Query
`Figure 33 Report Slave ID – Response
`. . . . . . . . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . .
`Figure 34 Read General Reference – Query
`Figure 35 Read General Reference – Response
`. . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . .
`Figure 36 Write General Reference – Query
`Figure 37 Write General Reference – Response
`. . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . .
`Figure 38 Mask Write 4X Register – Query
`Figure 39 Mask Write 4X Register – Response
`. . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . .
`Figure 40 Read/Write 4X Registers – Query
`Figure 41 Read/Write 4X Registers – Response
`. . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 42 Read FIFO Queue – Query
`Figure 43 Read FIFO Queue – Response
`. . . . . . . . . . . . . . . . . . . . . . .
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 44 Diagnostics – Query
`Figure 45 Diagnostics – Response
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`45
`45
`
`46
`47
`
`48
`49
`
`60
`61
`
`64
`65
`
`67
`67
`
`68
`69
`
`70
`71
`
`75
`75
`
`Figure 46 Master Query and Slave Exception Response
`
`. . . . . . . . . .
`
`95
`
`. . . . . . . . . . . . . . . . . . . . . . . . . . . .
`Figure 47 LRC Character Sequence
`Figure 48 CRC Byte Sequence
`. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
`
`110
`113
`
`PI–MBUS–300
`
`Contents
`
`xi
`
`

`

`Chapter 1
`Modbus Protocol
`
`Introducing Modbus Protocol
`
`The Two Serial Transmission Modes
`
`Modbus Message Framing
`
`Error Checking Methods
`
`PI–MBUS–300
`
`Modbus Protocol
`
`1
`
`

`

`Introducing Modbus Protocol
`
`Modicon programmable controllers can communicate with each other and with
`other devices over a variety of networks. Supported networks include the Modicon
`Modbus and Modbus Plus industrial networks, and standard networks such as
`MAP and Ethernet. Networks are accessed by built–in ports in the controllers or
`by network adapters, option modules, and gateways that are available from
`Modicon. For original equipment manufacturers, Modicon ModConnect ‘partner’
`programs are available for closely integrating networks like Modbus Plus into
`proprietary product designs.
`
`The common language used by all Modicon controllers is the Modbus protocol.
`This protocol defines a message structure that controllers will recognize and use,
`regardless of the type of networks over which they communicate. It describes the
`process a controller uses to request access to another device, how it will respond
`to requests from the other devices, and how errors will be detected and reported.
`It establishes a common format for the layout and contents of message fields.
`
`The Modbus protocol provides the internal standard that the Modicon controllers
`use for parsing messages. During communications on a Modbus network, the
`protocol determines how each controller will know its device address, recognize a
`message addressed to it, determine the kind of action to be taken, and extract any
`data or other information contained in the message. If a reply is required, the
`controller will construct the reply message and send it using Modbus protocol.
`
`On other networks, messages containing Modbus protocol are imbedded into the
`frame or packet structure that is used on the network. For example, Modicon
`network controllers for Modbus Plus or MAP, with associated application software
`libraries and drivers, provide conversion between the imbedded Modbus message
`protocol and the specific framing protocols those networks use to communicate
`between their node devices.
`
`This conversion also extends to resolving node addresses, routing paths, and
`error–checking methods specific to each kind of network. For example, Modbus
`device addresses contained in the Modbus protocol will be converted into node
`addresses prior to transmission of the messages. Error–checking fields will also
`be applied to message packets, consistent with each network’s protocol. At the
`final point of delivery, however – for example, a controller – the contents of the
`imbedded message, written using Modbus protocol, define the action to be taken.
`
`2
`
`Modbus Protocol
`
`PI–MBUS–300
`
`

`

`Figure 1 shows how devices might be interconnected in a hierarchy of networks
`that employ widely differing communication techniques. In message transactions,
`the Modbus protocol imbedded into each network’s packet structure provides the
`common language by which the devices can exchange data.
`
`HOST
`PROCESSOR
`
`MAP
`
`984–685
`(TO MB PLUS)
`
`AND
`
`S980 (TO MAP)
`
`MODBUS
`
`P230
`PROGRAMMER
`
`MODBUS PLUS
`
`AT/MC–984
`AND
`HOST/MMI
`
`984A/B
`AND
`S985
`
`BM85
`
`MODBUS
`
`MODBUS
`
`P230
`PROGRAMMER
`
`UP TO FOUR
`MODBUS DEVICES
`OR NETWORKS
`
`Figure 1 Overview of Modbus Protocol Application
`
`PI–MBUS–300
`
`Modbus Protocol
`
`3
`
`

`

`Introducing Modbus Protocol (Continued)
`
`
`Transactions on Modbus Networks
`
`Standard Modbus ports on Modicon controllers use an RS–232C compatible serial
`interface that defines connector pinouts, cabling, signal levels, transmission baud
`rates, and parity checking. Controllers can be networked directly or via modems.
`
`Controllers communicate using a master–slave technique, in which only one
`device (the master) can initiate transactions (called ‘queries’). The other devices
`(the slaves) respond by supplying the requested data to the master, or by taking
`the action requested in the query. Typical master devices include host processors
`and programming panels. Typical slaves include programmable controllers.
`
`The master can address individual slaves, or can initiate a broadcast message to
`all slaves. Slaves return a message (called a ‘response’) to queries that are
`addressed to them individually. Responses are not returned to broadcast queries
`from the master.
`
`The Modbus protocol establishes the format for the master’s query by placing into
`it the device (or broadcast) address, a function code defining the requested action,
`any data to be sent, and an error–checking field. The slave’s response message
`is also constructed using Modbus protocol. It contains fields confirming the action
`taken, any data to be returned, and an error–checking field. If an error occurred in
`receipt of the message, or if the slave is unable to perform the requested action,
`the slave will construct an error message and send it as its response.
`
`Transactions on Other Kinds of Networks
`
`In addition to their standard Modbus capabilities, some Modicon controller models
`can communicate over Modbus Plus using built–in ports or network adapters, and
`over MAP, using network adapters.
`
`On these networks, the controllers communicate using a peer–to–peer technique,
`in which any controller can initiate transactions with the other controllers. Thus a
`controller may operate either as a slave or as a master in separate transactions.
`Multiple internal paths are frequently provided to allow concurrent processing of
`master and slave transactions.
`
`4
`
`Modbus Protocol
`
`PI–MBUS–300
`
`

`

`At the message level, the Modbus protocol still applies the master–slave principle
`even though the network communication method is peer–to–peer. If a controller
`originates a message, it does so as a master device, and expects a response from
`a slave device. Similarly, when a controller receives a message it constructs a
`slave response and returns it to the originating controller.
`
`The Query–Response Cycle
`
`Query message from Master
`
`Device Address
`
`Function Code
`
`Eight–Bit
`Data Bytes
`
`Device Address
`
`Function Code
`
`Eight–Bit
`Data Bytes
`
`Error Check
`
`Error Check
`
`Response message from Slave
`
`Figure 2 Master–Slave Query–Response Cycle
`
`The Query: The function code in the query tells the addressed slave device what
`kind of action to perform. The data bytes contain any additional information that
`the slave will need to perform the function. For example, function code 03 will
`query the slave to read holding registers and respond with their contents. The
`data field must contain the information telling the slave which register to start at
`and how many registers to read. The error check field provides a method for the
`slave to validate the integrity of the message contents.
`
`The Response: If the slave makes a normal response, the function code in the
`response is an echo of the function code in the query. The data bytes contain the
`data collected by the slave, such as register values or status. If an error occurs,
`the function code is modified to indicate that the response is an error response,
`and the data bytes contain a code that describes the error. The error check field
`allows the master to confirm that the message contents are valid.
`
`PI–MBUS–300
`
`Modbus Protocol
`
`5
`
`

`

`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 tranasmission. For example, a request to read
`holding registers can be handled between two controllers on Modbus Plus without
`regard to the current setup of either controller’s serial Modbus port.
`
`ASCII Mode
`
`When controllers are setup to communicate on a Modbus network using ASCII
`(American Standard Code for Information Interchange) mode, each 8–bit 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:
`
`Bits per Byte:
`
`Hexadecimal, ASCII characters 0–9, A–F
`One hexadecimal character contained in each
`ASCII character of the message
`
`1 start bit
`7 data bits, least significant bit sent first
`1 bit for even/odd parity; no bit for no parity
`1 stop bit if parity is used; 2 bits if no parity
`
`Error Check Field:
`
`Longitudinal Redundancy Check (LRC)
`
`6
`
`Modbus Protocol
`
`PI–MBUS–300
`
`

`

`RTU Mode
`
`When controllers are setup to communicate on a Modbus network using RTU
`(Remote Terminal Unit) mode, each 8–bit byte in a message contains two 4–bit
`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:
`
`Bits per Byte:
`
`8–bit binary, hexadecimal 0–9, A–F
`Two hexadecimal characters contained in each
`8–bit field of the message
`
`1 start bit
`8 data bits, least significant bit sent first
`1 bit for even/odd parity; no bit for no parity
`1 stop bit if parity is used; 2 bits if no parity
`
`Error Check Field:
`
`Cyclical Redundancy Check (CRC)
`
`PI–MBUS–300
`
`Modbus Protocol
`
`7
`
`

`

`Modbus Message Framing
`
`In either of the two serial transmission modes (ASCII or RTU), a Modbus message
`is placed by the transmitting device into a frame that has a known beginning and
`ending point. This allows receiving devices to begin at the start of the message,
`read the address portion and determine which device is addressed (or all devices,
`if the message is broadcast), and to know when the message is completed.
`Partial messages can be detected and errors can be set as a result.
`
`On networks like MAP or Modbus Plus, the network protocol handles the framing
`of messages with beginning and end delimiters that are specific to the network.
`Those protocols also handle delivery to the destination device, making the
`Modbus address field imbedded in the message unnecessary for the actual
`transmission. (The Modbus address is converted to a network node address and
`routing path by the originating controller or its network adapter.)
`
`ASCII Framing
`
`In ASCII mode, messages start with a ‘colon’ ( : ) character (ASCII 3A hex), and
`end with a ‘carriage return – line feed’ (CRLF) pair (ASCII 0D and 0A hex).
`
`The allowable characters transmitted for all other fields are hexadecimal 0–9, A–F.
`Networked devices monitor the network bus continuously for the ‘colon’ character.
`When one is received, each device decodes the next field (the address field) to
`find out if it is the addressed device.
`
`Intervals of up to one second can elapse between characters within the message.
`If a greater interval occurs, the receiving device assumes an error has occurred.
`A typical message frame is shown below.
`
`START
`
`ADDRESS
`
`FUNCTION
`
`DATA
`
`LRC
`CHECK
`
`END
`
`1 CHAR
`:
`
`2 CHARS
`
`2 CHARS
`
`n CHARS
`
`2 CHARS
`
`2 CHARS
`CRLF
`
`Figure 3 ASCII Message Frame
`
`8
`
`Modbus Protocol
`
`PI–MBUS–300
`
`

`

`Exception: With the 584 and 984A/B/X controllers, an ASCII message can
`normally terminate after the LRC field without the CRLF characters being sent.
`An interval of at least one second must then occur. If this happens, the controller
`will assume that the message terminated normally.
`
`RTU Framing
`
`In RTU mode, messages start with a silent interval of at least 3.5 character times.
`This is most easily implemented as a multiple of character times at the baud rate
`that is being used on the network (shown as T1–T2–T3–T4 in the figure below).
`The first field then transmitted is the device address.
`
`The allowable characters transmitted for all fields are hexadecimal 0–9, A–F.
`Networked devices monitor the network bus continuously, including during the
`‘silent’ intervals. When the first field (the address field) is received, each device
`decodes it to find out if it is the addressed device.
`
`Following the last transmitted character, a similar interval of at least 3.5 character
`times marks the end of the message. A new message can begin after this interval.
`
`The entire message frame must be transmitted as a continuous stream. If a silent
`interval of more than 1.5 character times occurs before completion of the frame,
`the receiving device flushes the incomplete message and assumes that the next
`byte will be the address field of a new message.
`
`Similarly, if a new message begins earlier than 3.5 character times following a
`previous message, the receiving device will consider it a continuation of the
`previous message. This will set an error, as the value in the final CRC field will not
`be valid for the combined messages. A typical message frame is shown below.
`
`START
`
`ADDRESS
`
`FUNCTION
`
`DATA
`
`CRC
`CHECK
`
`END
`
`T1–T2–T3–T4
`
`8 BITS
`
`8 BITS
`
`n x 8 BITS
`
`16 BITS
`
`T1–T2–T3–T4
`
`Figure 4 RTU Message Frame
`
`PI–MBUS–300
`
`Modbus Protocol
`
`9
`
`

`

`Modbus Message Framing (Continued)
`
`
`How the Address Field is Handled
`
`The address field of a message frame contains two characters (ASCII) or eight
`bits (RTU). Valid slave device addresses are in the range of 0 – 247 decimal.
`The individual slave devices are assigned addresses in the range of 1 – 247. A
`master addresses a slave by placing the slave address in the address field of the
`message. When the slave sends its response, it places its own address in this
`address field of the response to let the master know which slave is responding.
`
`Address 0 is used for the broadcast address, which all slave devices recognize.
`When Modbus protocol is used on higher level networks, broadcasts may not be
`allowed or may be replaced by other methods. For example, Modbus Plus uses a
`shared global database that can be updated with each token rotation.
`
`How the Function Field is Handled
`
`The function code field of a message frame contains two characters (ASCII) or
`eight bits (RTU). Valid codes are in the range of 1 – 255 decimal. Of these, some
`codes are applicable to all Modicon controllers, while some codes apply only to
`certain models, and others are reserved for future use. Current codes are
`described in Chapter 2.
`
`When a message is sent from a master to a slave device the function code field
`tells the slave what kind of action to perform. Examples are to read the ON/OFF
`states of a group of discrete coils or inputs; to read the data contents of a group of
`registers; to read the diagnostic status of the slave; to write to designated coils or
`registers; or to allow loading, recording, or verifying the program within the slave.
`
`When the slave responds to the master, 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 slave simply echoes the
`original function code. For an exception response, the slave returns a code that is
`equivalent to the original function code with its most–significant bit set to a logic 1.
`
`For example, a message from master to slave to read a group of holding registers
`would have the following function code:
`
`0000 0011
`
`(Hexadecimal 03)
`
`10
`
`Modbus Protocol
`
`PI–MBUS–300
`
`

`

`If the slave device takes the requested action without error, it returns the same
`code in its response. If an exception occurs, it returns:
`
`1000 0011
`
`(Hexadecimal 83)
`
`In addition to its modification of the function code for an exception response, the
`slave places a unique code into the data field of the response message. This tells
`the master what kind of error occurred, or the reason for the exception.
`
`The master device’s application program has the responsibility of handling
`exception responses. Typical processes are to post subsequent retries of the
`message, to try diagnostic messages to the slave, and to notify operators.
`
`Contents of the Data Field
`
`The data field is constructed using sets of two hexadecimal digits, in the range of
`00 to FF hexadecimal. These can be made from a pair of ASCII characters, or
`from one RTU character, according to the network’s serial transmission mode.
`
`The data field of messages sent from a master to slave devices contains
`additional information which the slave must use 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.
`
`For example, if the master requests a slave to read a group of holding registers
`(function code 03), the data field specifies the starting register and how many
`registers are to be read. If the master writes to a group of registers in the slave
`(function code 10 hexadecimal), the data field specifies the starting register, how
`many registers to write, the count of data bytes to follow in the data field, and the
`data to be written into the registers.
`
`If no error occurs, the data field of a response from a slave to a master contains
`the data requested. If an error occurs, the field contains an exception code that
`the master application can use to determine the next action to be taken.
`
`The data field can be nonexistent (of zero length) in certain kinds of messages.
`For example, in a request from a master device for a slave to respond with its
`communications event log (function code 0B hexadecimal), the slave does not
`require any additional information. The function code alone specifies the action.
`
`PI–MBUS–300
`
`Modbus Prot