Modbus Communications

Modbus - The Universal Industrial Protocol?

The MODBUS® protocol was developed by Modicon in 1978 as a simple way for transferring control data between controllers and sensors using an RS232 port. The protocol describes an industrial communications and distributed control system developed to integrate PLC’s, computers, terminals, with other monitoring, sensing, and control devices. Since it's creation it has become a de-facto industry standard used by multiple control and sensor companies. Today Modbus protocol is the single, most supported protocol amongst automation devices. Most devices, being able to communicate serial, talk Modbus.

Modbus is now also the most common industrial Ethernet protocol. A newly released study by ARC Advisory Group, the leading analyst firm covering automation and enterprise software, shows Modbus TCP/IP as the world's leading industrial Ethernet protocol, in terms of units shipped in 2004. Ethernet port 502 is now standard for the Modbus TCP/IP protocol. Modbus is the only real open Industrial Internet protocol owned by the Industrial community.

The Modbus protocol is a trademark of Schneider Electric. However, Schneider Electric made the protocol specification and its implementation available for free to anyone who wishes to implement a Modbus or Modbus TCP/IP device.

Although originally designed by Modicon, Modbus is now an open standard supported by an independent, member driven organization which can be found at Modbus-IDA

The following description gives an overview of the protocol and some of the points to consider when connecting dissimilar equipment using Modbus.

Master / Slave Functionality

Modbus is a Master / slave protocol. A number of devices may be interconnected using the protocol, but only one device can be the master. Communications is always instigated and controlled by the master device. All other devices are connected as slaves and will only communicate in response to requests or commands from the single master. The protocol provides for one master device and up to 247 slave devices on a common line. Each device is assigned an address to distinguish it from all other connected devices.

This simple structure ensures the protocol overhead is kept to a minimum. Device addressing is simple.

Methods of Communication

The original Modbus protocol was designed for use with serial communications devices using RS-232 or RS-485. RS-232 is normally restricted to single slave, short distance communications, whereas RS-485 is better when distance and / or multiple slaves are required.

Modbus Plus was introduced by Modicon as a global fieldbus network to enable faster (2 MBit/s) communications between multiple (up to 32) devices. A token passing topology is used over an RS485 interconnection.

Modbus TCP/IP takes the original protocol and structures it for use over Ethernet using the TCP/IP protocols. This is done in such a way as to minimise implementation changes to software developers and has resulted in a large number of devices quickly supporting the protocol. Modbus TCP/IP allows concurrent master / slave operation.

For simple non-networked implementations, the original protocol is fine. For larger, distributed systems, especially where Ethernet may already be installed, Modbus TCP/IP has many advantages. Be aware however, that Modbus TCP/IP installations will only be as good / reliable as the underlying network!

Protocol versions

Modbus devices can communicate using either of two versions of the Modbus protocol, RTU (Remote Terminal Unit) or ASCII (American Standard Code for Information Interchange). RTU is a binary format requiring the least number of characters for transmission, whereas ASCII uses only text readable characters requiring more per message and is thus slower. Some devices will only support one or the other. All connected devices should be configured to the same version

Modbus TCP/IP does not have the ASCII option.

Some proprietary 'versions' define additional data types / uses such as Enron / Daniels which define methods of passing 32 bit integer and floating point values (see Compatibility between devices below). Note that these are still RTU or ASCII based however.

Protocol Details

Data Encoding

MODBUS uses a ‘big-Endian’ representation for addresses and data items. This means that when a numerical quantity larger than a single byte is transmitted, the most significant byte is sent first (see Compatibility between devices below).

Data Model

MODBUS bases its data model on a series of tables that have distinguishing characteristics. The four primary tables are:

Primary tables	Object type	Type of access	Comments
Discretes Input	Single bit	Read-Only	This type of data can be provided by an I/O system.
Coils	Single bit	Read-Write	This type of data can be alterable by an application program.
Input Registers	16-bit word	Read-Only	This type of data can be provided by an I/O system
Holding Registers	16-bit word	Read-Write	This type of data can be alterable by an application program.

The distinctions between inputs and outputs, and between bit-addressable and word-addressable data items, do not imply any application behaviour. 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.

It’s obvious that all the data handled via MODBUS (bits, registers) must be located in device application memory. But physical address in memory should not be confused with data reference. The only requirement is to link data reference with physical address.

MODBUS logical reference number, which are used in MODBUS functions, are unsigned integer indices starting at zero.

It is worth noting at this point that only single bit and 16 bit words are defined object types for data access (ASCII characters are also included in diagnostic messages). How the words are interpreted / combined is not defined in the protocol definition (see Compatibility between devices below).

Addressing

Modbus can address 65536 separate addresses.

Function Codes

Public Function Codes

well defined function codes
guaranteed to be unique
validated by the modbus.org community
publicly documented
have available conformance test
documented in the MB IETF RFC
includes both defined public assigned function codes as well as unassigned function codes reserved for future use.

User-Defined Function Codes

there are two ranges of user-defined function codes, ie 65 to 72 and from 100 to 110 decimal.
user can select and implement a function code without any approval from modbus.org
there is no guarantee that the use of the selected function code will be unique
if the user wants to re-position the functionality as a public function code, he must initiate an RFC to introduce the change into the public category and to have a new public function code assigned.

Reserved Function Codes

Function Codes currently used by some companies for legacy products and that are not available for public use.

Compatibility between devices

Some implementations deviate and / or extend on the defined protocol. Examples include alternate byte / word ordering and other data types. This can lead to problems unless all interconnected master and slave devices support the variations.

To guarantee communications between devices using Modbus, several checks should be made:

The devices all support the same protocol version in order to communicate at all!
The devices all support the Function Codes to be used. This often means limiting the use to a subset of the Public Function Codes.
Data encoding is compatible between master and slaves. This includes register data types and byte order as some devices may have differing uses from the standard.
Addressing ranges comply (number base differences can lead to confusion, for example start with 0 or 1 in setup / usage).

Modbus Support in Hexatec Software

Hexatec software fully supports the Modbus protocol. Hexatec Saturn and SCAN1000 supports both Master and Slave functionality allowing it to be interconnected with a wide range of Modbus communication equipment. The product is available with a wide range of options.