This document introduces the reader to the Modbus protocol. It presents a basic protocol description and discusses the serial and the TCP based implementations.
Basically Modbus is an application layer protocol (see Figure 1) for communication between devices, mainly to exchange data typical for the field of automation.
At this level Modbus is a stateless client-server protocol (e.g. much like HTTP), based on transactions, which consist of a request (issued by the client) and a response (issued by the server). In the field where this protocol is usually applied, there exists a concept that is one of the possible schemas governing the lower level communication behavior on a network using a shared signal cable: Master-Slave. To prevent confusion, the following directed relations describe Master-Slave in terms of the Client-Server paradigm:
A transaction and it's context is visualized in Figure 2.
The stateless communication is based on a simple package, that is called Protocol Data Unit (PDU). The protocol specification defines three types of PDU's:
Figure 3 presents a visualization of these packages.
The specification defines a certain number of functions, each of which is assigned a specific function code. These are in the range 1-127 (decimal), as 129 (i.e. 1+128) - 255 (i.e. 127+128) represents the range of error codes.
While the first published version of the specification defined different classes of functions (e.g. Class 0, Class 1, Class 2), the newly released specification (from http://www.modbus.org; see Knowledge Base Index) defines categories of function codes:
The documentation for a function consists of:
The specification further documents defined and assigned public functions.
In certain cases, the response from a slave will be an exception. The primary identification of an exception response is the error code (function code + 128), which is further specified by the exception code. Assigned codes and descriptions can be found in the specification.
The basic public functions have been developed for exchanging data typical for the field of automation. Following are the basic Modbus data types defined by the specification:
The specification does not define the ways of organizing the related data in a device. However, the organization has a direct influence on the addresses used in basic access functions.
| Note |
|---|
| Please, always consult the device's documentation to learn about addressing in basic access functions! |
Basically Modbus has been implemented and used over all types of physical links (wire, fiber and radio) and various types of lower level communication stacks. However, we will concentrate on the two basic types of implementations (which are supported by jamod):
Modbus started it's life in form of an implementation for asynchronous serial network communication. The application level protocol operates directly on top of a serial interface and serial communication standards. The most common ones (over wire) are:
RS232 is used for short distance point-to-point communication, the same is valid for EIA422, which is a bidirectional extension of RS232 for industrial environments, that also supports longer distances.
EIA485 can be used for multipoint communication (i.e. multiple devices connected to the same signal cable), employing the Master-Slave paradigm (one master and n fixed address slaves).
Figure 4 visualizes the possible network setups.
To enable the actual communication for this setups, the implementation extends the PDU with additional fields, better said, it wraps the PDU into a package with a header and an error checksum (see Figure 5). The resulting package is defined by the protocol specification as Application Data Unit (ADU), that has a maximum package size of 256 bytes.
| Note |
|---|
| The maximum package size limitation of 256 bytes applies for all existing Modbus protocol implementations (legacy) ! |
The header is composed of an address field (1 byte) and the tail is an error checksum over the whole package, including the address field (i.e. header). For transmission the Modbus message (i.e. ADU) is placed into a frame that has a known beginning and ending point, allowing detection of the start and the end of a message and thus partial messages. There exist two transmission modes, which differ in encoding, framing and checksum:
Frames are encoded into two ASCII characters per byte, representing the hexadecimal notation of the byte (i.e. characters 0–9, A–F). The error checksum is represented by a longitudinal redundancy check (LRC; 1 byte) and messages start with a colon (':', 0x3A), and end with a carriage return – line feed ("CRLF", 0x0D0A). Pauses of 1 second between characters can occur.
Frames are transmitted binary to achieve a higher density. The error checksum is represented by a cyclic redundancy check (16 bit CRC; 2 byte) and messages start and end 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. The maximum pause that may occur between two bytes is 1.5 character times.
jamod is designed to support both transmission modes, using an implementation which is based on the javax.comm API.
| Warning |
|---|
| The RTU implementation does only support the Master side. It is working by the best effort principle, which means it might not work in a reliable way in a low-lantency real-time context. |
It is indeed possible to implement the serial transport based on other serial stack implementations (i.e. replacements for the Java Comm API implementation) like for example SerialPort (http://www.sc-systems.com/products/serialport/serialport.htm). According to the product info it supports around 20 platforms and it has been successfully used to implement the two serial transmission modes in Java (Master only, see Field Talk/Java, a commercial Master protocol pack from Focus Engineering).
A TCP/IP based Modbus protocol implementation (Modbus/TCP) has been recently committed as an RFC draft to the IETF. It uses the TCP/IP stack for communication (registered port is 502) and extends the PDU with an IP specific header (see Figure 6).
The possible network setups are not governed by the specification; it is possible to setup multi-master systems or realize bidirectional communication (i.e. have nodes that are master and slave at the same time). However, the user should be well aware that there are implications from deviations of the Master/Slave schema.
The IP specific header (called MBAP in the specification) is 7 bytes long and composed of the following fields:
There are a few points regarding the specification, which are definitely discussable:
| Note |
|---|
| For learning more about Modbus/BIN, please see: Modbus/BIN Specification. |
Especially if a real-time communication has to be achieved, it might be of interest to investigate in a Modbus/UDP implementation.
| Note |
|---|
| For learning more about Modbus/UDP, please see: Modbus/UDP Specification. |
