Sunday, September 24, 2017

IAM Search

Modbus

Developed by the Modicon company (the original manufacturer of the Programmable Logic Controller, or PLC) in 1979 for use in its industrial control products, Modbus is a protocol designed specifically for exchanging process data between industrial control devices. The Modbus standard does not specify any details of physical networking, and thus may be deployed on any number of physical networks such as EIA/TIA-232, EIA/TIA-485, Ethernet (the latter via TCP/IP), and a special token-passing network also developed by Modicon called Modbus Plus. Modbus itself is primarily concerned with details at layer 7 of the OSI Reference Model, the so-called Application Layer.

Modbus, especially when implemented over simple serial networks such as EIA/TIA-232 and EIA/TIA-485, is a rather primitive protocol. The seemingly arbitrary numerical codes used to issue commands and specify addresses is antiquated by modern standards. For better or for worse, though, a great many digital industrial devices “speak” Modbus, even if they are also capable of communicating via some other network protocol.

 

Modbus data frames

Modbus defines a set of commands for reading (receiving) and writing (transmitting) data between a master device and one or more slave devices connected to the network. Each of these commands is referenced by a numerical code, with addresses of the master and slave devices’ internal registers (data sources and data destinations) specified along with the function code in the Modbus message frame.

Two different formats are specified in the Modbus standard: ASCII and RTU. The difference between these two modes is how addresses, function codes, data, and error-checking bits are represented. In Modbus ASCII mode, all slave device addresses, function codes, and data are represented in the form of ASCII characters (7 bits each), which may be read directly by any terminal program (e.g. minicom, Hyperterminal, kermit, etc.) intercepting the serial data stream.

This makes troubleshooting easier: to be able to directly view the Modbus data frames in human-readable form. In Modbus RTU mode, all slave device addresses, function codes, and data are represented directly in hexadecimal form, with four bits per hexadecimal character. Different errorchecking techniques are used for ASCII and RTU modes as well. The following diagram compares data frames for the two Modbus communication modes:

 

Modbus ASCII and RTU Message Frame

 

As you can see from a comparison of the two frames, ASCII frames require nearly twice the number of bits as RTU frames, making Modbus ASCII slower than Modbus RTU for any given data rate (bits per second).

The contents of the “Data” field vary greatly depending on which function is invoked, and whether or not the frame is issued by the master device or from a slave device. More details on Modbus “Data” field contents will appear in a later subsection.

Since Modbus is strictly a “layer 7” protocol, these message frames are usually embedded within other data frames specified by lower-level protocols. For example, Modbus over TCP/IP encapsulates individual Modbus data frames as TCP/IP packets, which are then (usually) encapsulated again as Ethernet packets to arrive at the destination device. This “multi-layered” approach inherent to Modbus being such a high-level protocol may seem cumbersome, but it offers great flexibility in that Modbus frames may be communicated over nearly any kind of virtual and physical network type.

 

Modbus function codes and addresses

A listing of commonly-used Modbus function codes appears in the following table:

 

Modbus code

(decimal)

 Function
01 Read one or more PLC output “coils” (1 bit each)
02 Read one or more PLC input “contacts” (1 bit each)
03 Read one or more PLC “holding” registers (16 bits each)
04 Read one or more PLC analog input registers (16 bits each)
05 Write (force) a single PLC output “coil” (1 bit)
06 Write (preset) a single PLC “holding” register (16 bits)
15 Write (force) multiple PLC output “coils” (1 bit each)
16 Write (preset) multiple PLC “holding” registers (16 bits each)

Modbus “984” addressing defines sets of fixed numerical ranges where various types of data may be found in a PLC or other control device. The absolute address ranges (according to the Modbus 984 scheme) are shown in this table:

 

Modbus codes (decimal) Address range (decimal) Purpose
01, 05, 15 00001 to 09999 Discrete outputs (“coils”)
02 10001 to 19999 Discrete inputs (“contacts”)
04 30001 to 39999 Analog input registers
03, 06, 16 40001 to 49999 “Holding” registers

 

This fixed addressing scheme usually does not match conveniently to the addressing within the master or slave devices. Manufacturer’s documentation for Modbus-compatible devices normally provide Modbus “mapping” references so technicians and engineers alike may determine which Modbus addresses refer to specific bit or word registers in the device.

Note how all the Modbus address ranges begin at the number one, not zero as is customary for so many digital systems. For example, a PLC with sixteen discrete input channels numbered 0 through 15 by the manufacturer may “map” those inputs (“contacts”) to Modbus addresses 10001 through 10016, respectively.

Coil, Contact, and Register addresses are specified within Modbus data frames relative to the starting points of their respective commands. For example, the function to read discrete inputs (“contacts”) on a slave device only applies to Modbus absolute addresses 10001 through 19999, and so the actual Modbus command issued to read contact address 10005 will specify the address as 0004 (since 10005 is the fourth address up from the start of the contact address block 10001 through 19999), and this relative address value is always communicated as a hexadecimal (not decimal) value1.

 

Modbus function command formats

Every Modbus data frame, whether ASCII or RTU mode, has a field designated for “data.” For each Modbus function, the content of this “data” field follows a specific format. It is the purpose of this subsection to document the data formats required for common Modbus functions, both the “Query” message transmitted by the Modbus master device to a slave device, and the corresponding “Response” message transmitted back to the master device by the queried slave device.

Since each Modbus data frame is packaged in multiples of 8 bits (RTU), they are usually represented in text as individual bytes (two hexadecimal characters). For example, a 16-bit “word” of Modbus data such as 1100100101011011 would typically be documented as C9 5B with a deliberate space separating the “high” (C9) and “low” (5B) bytes.

 

Function code 01 – Read Coil(s)

This Modbus function reads the statuses of slave device discrete outputs (“coils”) within the slave device, returning those statuses in blocks of eight (even if the “number of coils” specified in the query is not a multiple of eight!). Relevant Modbus addresses for this function range from 00001 to 09999 (decimal) but the starting address is a hexadecimal number representing the (n1)th register from the beginning of this range (e.g. decimal address 00100 would be specified as hexadecimal 00 63).

 

Modbus Query and Response Message (Function Code 01)

 

Note that the second and third bytes representing coil status are shown in grey, because their existence assumes more than one byte worth of coils has been requested in the query.

 

Function code 02 – Read Contact(s)

This Modbus function reads the statuses of slave device discrete inputs (“contacts”) within the slave device, returning those statuses in blocks of eight (even if the “number of contacts” specified in the query is not a multiple of eight!). Relevant Modbus addresses for this function range from 10001 to 19999 (decimal), but the starting address is a hexadecimal number representing the (n1)th register from the beginning of this range (e.g. decimal address 10256 would be specified as hexadecimal 00 FF).



Modbus Query and Response Message (Function Code 02)

 

Function code 03 – Read Holding Register(s)

This Modbus function reads the statuses of “holding” registers within the slave device, with the size of each register assumed to be two bytes (16 bits). Relevant Modbus addresses for this function range from 40001 to 49999 (decimal), but the starting address is a hexadecimal number representing the (n1)th register from the beginning of this range (e.g. decimal address 40980 would be specified as hexadecimal 03 D3).

 

Modbus Query and Response Message (Function Code 03)

 

Note that since the query message specifies the number of registers (each register being two bytes in size), and the response message replies with the number of bytes, the response message’s “number of bytes” field will have a value twice that of the query message’s “number of registers” field. Note also that the maximum number of registers which may be requested in the query message (65536) with “high” and “low” byte values grossly exceeds the number of bytes the response message can report (255) with its single byte value.

 

Function code 04 – Read Analog Input Register(s)

This Modbus function is virtually identical to 03 (Read Holding Registers) except that it reads “input” registers instead: addresses 30001 through 39999 (decimal). As with all the Modbus relative addresses, the starting address specified in both messages is a hexadecimal number representing the (n 1)th register from the beginning of this range (e.g. decimal address 32893 would be specified as hexadecimal 0B 4C).

 

Modbus Query and Response Message (Function Code 04)

 

Note that since the query message specifies the number of registers (each register being two bytes in size), and the response message replies with the number of bytes, the response message’s “number of bytes” field will have a value twice that of the query message’s “number of registers” field. Note also that the maximum number of registers which may be requested in the query message (65536) with “high” and “low” byte values grossly exceeds the number of bytes the response message can report (255) with its single byte value.

 

Function code 05 – Write (Force) Single Coil

This Modbus function writes a single bit of data to a discrete output (“coil”) within the slave device. Relevant Modbus addresses for this function range from 00001 to 09999 (decimal) but the starting address is a hexadecimal number representing the (n1)th register from the beginning of this range (e.g. decimal address 07200 would be specified as hexadecimal 1C 1F).

 

Modbus Query and Response Message (Function Code 05)

 

The “force data” for a single coil consists of either 00 00 (force coil off) or FF 00 (force coil on). No other data values will suffice – anything other than 00 00 or FF 00 will be ignored by the slave device.

A normal response message will be a simple echo (verbatim repeat) of the query message.


Function code 06 – Write (Preset) Single Holding Register

This Modbus function writes data to a single “holding” register within the slave device. Relevant Modbus addresses for this function range from 40001 to 49999 (decimal) but the starting address is a hexadecimal number representing the (n 1)th register from the beginning of this range (e.g. decimal address 40034 would be specified as hexadecimal 00 21).

 

Modbus Query and Response Message (Function Code 06)

 

A normal response message will be a simple echo (verbatim repeat) of the query message.

 

Function code 15 – Write (Force) Multiple Coils

This Modbus function writes multiple bits of data to a set of discrete outputs (“coils”) within the slave device. Relevant Modbus addresses for this function range from 00001 to 09999 (decimal) but the starting address is a hexadecimal number representing the (n1)th register from the beginning of this range (e.g. decimal address 03207 would be specified as hexadecimal 0C 86).

 


Modbus Query and Response Message (Function Code 15)

 

Note that the query message specifies both the number of coils (bits) and the number of bytes.

 

Function code 16 – Write (Preset) Multiple Holding Register

This Modbus function writes multiple words of data to a set of “holding” registers within the slave device. Relevant Modbus addresses for this function range from 40001 to 49999 (decimal) but the starting address is a hexadecimal number representing the (n 1)th register from the beginning of this range (e.g. decimal address 47441 would be specified as hexadecimal 1D 10).

 

Modbus Query and Response Message (Function Code 16)

Note that the query message specifies both the number of registers (16-bit words) and the number of bytes, which is redundant (the number of bytes must always be twice the number of registers, given that each register is two bytes2 in size). Note also that the maximum number of registers which may be requested in the query message (65536) with “high” and “low” byte values grossly exceeds the number of bytes the response message can report (255) with its single byte value.


1If the process of converting a device’s I/O addresses to Modbus commands sounds to you like it would be about as much fun as being beat with a rubber hose, you are correct. In order to appease those of us lacking masochistic tendencies, some digital device manufacturers include Modbus address “translation” features into their products, so the programmer (you) does not have to burden yourself with offset calculations and decimal-to-hexadecimal conversions just to move a few blocks of data between devices on a Modbus network.

2Even for devices where the register size is less than two bytes (e.g. Modicon M84 and 484 model controllers have 10 bits within each register), data is still addressed as two bytes’ worth per register, with the leading bits simply set to zero to act as placeholders.


Click here to go back to the previous page, The HART Digita/Analog Hybrid Standard

References

“422 and 485 Standards Overview and System Configurations” Application Report SLLA070C, Texas Instruments Incorporated, Dallas, TX, 2002.

“B&B Converters for the Industrial Bus World” Technical Article 13, B&B Electronics Manufacturing Company, Ottawa, IL, 2000.

Floyd, Thomas L., Digital Fundamentals, 6th edition, Prentice-Hall, Inc., Upper Saddle River, NJ, 1997.

“FOUNDATION Fieldbus System Engineering Guidelines” (AG 181) Revision 2.0, The Fieldbus Foundation, 2004.

“FOUNDATION Specification System Architecture” (FF 581) Revision FS 1.1, The Fieldbus Foundation, 2000.

“Fundamentals of RS-232 Serial Communications” Application Note 83 (AN83), Maxim Integrated Products, 2001.

Giancoli, Douglas C., Physics for Scientists & Engineers, Third Edition, Prentice Hall, Upper Saddle River, NJ, 2000.

Graham, Frank D., Audels New Electric Library, Volume IX, Theo. Audel & Co., New York, NY, 1942.

HART Communications, Technical Information L452 EN; SAMSON AG, 1999.

Horak, Ray, Telecommunications and Data Communications Handbook, John Wiley & Sons, Inc., New York, NY, 2007.

Horak, Ray, Webster’s New World Telecom Dictionary, Wiley Publishing, Inc., Indianapolis, IN, 2008.

Hutchinson, Chuck, The ARRL Handbook For Radio Amateurs, 2001 edition, The American Radio Relay League, CT, 2000.

“Industrial Electronics Reference Book”, Westinghouse Electric Corporation, John Wiley & Sons Inc., New York, NY, 1948.

Lipt´ak, B´ela G., Instrument Engineers’ Handbook – Process Software and Digital Networks, Third Edition, CRC Press, New York, NY, 2002.

“Modbus Application Protocol Specification”, version 1.1b, Modbus-IDA, Modbus Organization, Inc., 2006.

“Modbus Messaging on TCP/IP Implementation Guide”, version 1.0b, Modbus-IDA, Modbus Organization, Inc., 2006.

“Modicon Modbus Protocol Reference Guide”, (PI-MBUS-300) revision J, Modicon, Inc. Industrial Automation Systems, North Andover, MA, 1996.

Newton, Harry, Newton’s Telecom Dictionary, CMP Books, San Francisco, CA, 2005.

Park, John; Mackay, Steve; Wright, Edwin; Practical Data Communications for Instrumentation and Control, IDC Technologies, published by Newnes (an imprint of Elsevier), Oxford, England, 2003.

“Selecting and Using RS-232, RS-422, and RS-485 Serial Data Standards” Application Note 723 (AN723), Maxim Integrated Products, 2000.

Smith, Steven W., The Scientist and Engineer’s Guide to Digital Signal Processing, California Technical Publishing, San Diego, CA, 1997.

Smith, W. W., The “Radio” Handbook, Sixth Edition, Radio Ltd., Santa Barbara, CA, 1939.

Spurgeon, Charles E., Ethernet: The Definitive Guide, O’Reilly Media, Inc., Sebastopol, CA, 2000.

Svacina, Bob, Understanding Device Level Buses: A Tutorial, InterlinkBT, LLC, Minneapolis, MN, 1998.

Welsh, Matt and Kaufman, Lar, Running Linux, Second Edition, O’Reilly & Associates, Sebastopol, CA, 1996.


Go Back to Lessons in Instrumentation Table of Contents


Comments (0)Add Comment

Write comment

security code
Write the displayed characters


busy

Related Articles

Promotions

  • ...more

Disclaimer

Important: All images are copyrighted to their respective owners. All content cited is derived from their respective sources.

Contact us for information and your inquiries. IAMechatronics is open to link exchanges.

IAMechatronics Login