Modbus documentation clarified, 5 reasons to use RS-485 with automation

Understand the implementation of Modbus serial communication, and its evolving relevance in a digital world of automation and controls.

By Lucas Paruch October 9, 2024
Modbus example of how to read registers 10 and 11 (0xA and 0xB). Courtesy: Yaskawa America Inc.

 

Learning Objectives

  • Understand why Modbus been successful for industrial automation: It’s a simple, easy to use open-source protocol (and three other reasons).
  • How Modbus works: Protocol tutorial overview explains number system used for Modbus and clarifies some documentation inconsistencies.
  • Learn five reasons to use RS-485 with Modbus; hardware overview explains single-ended signaling, maximum Modbus bus length, and when Modbus is appropriate for automation applications.

Modbus software and hardware (RS-485) insights 

  • Modbus has been successful for industrial automation because it’s a simple, easy to use open-source protocol (and for three other reasons). 
  • Understand how Modbus works: A protocol tutorial overview explains number system used for Modbus and clarifies some documentation inconsistencies.  
  • There are five reasons to use RS-485 with Modbus. A hardware overview explains single-ended signaling, maximum Modbus bus length, and when Modbus is appropriate for automation applications. 

What started as the internet of things (IoT) has evolved into Industry 4.0. Along the way we added an extra “I” for industrial internet of things (IIoT), and rolled in ideas about big data, artificial intelligence and machine learning (AI/ML) for automation and controls. Behind these shiny new tools is a humble little protocol: Modbus (lead by The Modbus Organization)

Why has Modbus been successful for industrial automation?

Originally published by Modicon in 1979, Modbus quickly became the de facto standard for industrial communications. The following characteristics contributed to the success of Modbus:

  • Simple, easy-to-deploy, open-source protocol

  • Asynchronous serial implementation requires minimal processing resources

  • Differential serial driver provides excellent noise immunity in harsh environments

  • Support for long multi-drop serial bus runs (1200m w/o repeaters/switches).

Fast forward 45 years, and the scale of industrial network data acquisition, communication and real-time processing has exploded to a magnitude unimaginable in the 1980s. However, the IIoT still contains a lot of small things that haven’t fundamentally changed over the past four decades. Many edge devices and sensors, widely distributed throughout a system, require a reliable and low-cost method of reporting data to central “IIoT” controllers. Rather than deploying a ruggedized Ethernet solution to pick up a few bytes of data, Modbus RTU offers a reliable means of communication that can be deployed with something as simple and inexpensive as an 8-bit microcontroller.

How Modbus works: Number system

Number system background: Starting from the very beginning: Binary digital data is comprised of bits. Each bit may be equal to zero (off) or one (on).

We form nibbles by grouping bits into groups of 4.

In binary (base-2), the value of a nibble ranges from 0000 to 1111.

Counting from 0000 to 1111 requires 16 steps (24=16): 0000, 0001, 0010, 0011, 0100.…

In hexadecimal (base-16), these values are represented as 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F.

The 16 possible values of a nibble range from 0000 to 1111 in binary, and from 0 to F in hexadecimal, and from 00 to 15 in decimal (base-10). Numbers expressed in hex are typically preceded by the notation “0x” to avoid confusion with decimal, for example: 0x10 = 16 (decimal).

Bytes are comprised of 8 bits (two nibbles). A byte represents 28=256 values, or a range from 0x00 to 0xFF.

In Modbus, we’re primarily concerned with 16-bit words. A word represents two bytes, or 216=65536 values. A word represents a range of values from 0x0 to 0xFFFF.

Modbus protocol overview, tutorial

Modbus is structured as a client-server (formerly called master-slave) protocol. In each network, one device is designated as the client. The client is the only device that may initiate communication.

Modbus RTU (remote terminal unit) is by far the most common serial implementation. All Modbus devices must implement RTU, however some devices also implement ASCII mode for legacy applications (that is, modem communication). For simplicity, all references to serial Modbus in this guide assume RTU implementation.

Each server device on the network is assigned a unique address (from 1 to 247). The client uses this address to request data from, or send data to, server nodes.

Modbus divides server data into four groups: Discrete coil, discrete input, input register and holding register (Table 1).

Table 1: Modbus divides server data into discrete coil, discrete input, input register and holding register groups. Courtesy: Yaskawa America Inc.

Table 1: Modbus divides server data into discrete coil, discrete input, input register and holding register groups. Courtesy: Yaskawa America Inc.

Clarifying Modbus documentation inconsistencies

Initially, Modbus data types were intended to align with functions of programmable logic controllers (PLCs). Today, most modern devices use only holding registers for data transfer. Rather than address individual bits at a protocol level, many devices simply pack status bits into holding registers and separate them as needed in software (via bitwise AND). This can make software development more efficient, since only one data type needs to be manipulated. Likewise, it’s often more efficient to handle access control at the server level. Rather than using an alternate addressing scheme for read-only registers, it is common to address all data as holding registers and simply ignore write requests for addresses that the server determines are to be treated as read-only.

The address offset is another common point of confusion. Initially, the offset provided a means of differentiating between coils (1-9999), discrete inputs (10001-19999), input registers (30001-39999), and holding registers (40001-49999) in the Modicon PLC implementation.

The Modbus protocol doesn’t actually use these offsets, but the convention is still present in some modern device and controller documentation. If a server’s documentation specifies a Modicon style address of 40010, the data address of the holding register is simply 40010-40001 = 9. Likewise, if the data address of a holding register is specified as 9, and a client is expecting a Modicon-style addressing scheme, simply add the 40001 offset to arrive at an address of 40010.

Compounding addressing confusion, some manufacturers add an offset of 1 to the data address, but drop the 0x/1x/3x/4x Modicon notation. Regardless of naming convention, it is always recommended to verify the first available register for each data type to ensure the server and client nodes are using the same notation.

First available address of each data type is shown in Table 2.

Table 2 shows the first available of each data type in Modbus. Courtesy: Yaskawa America Inc.

Table 2 shows the first available of each data type in Modbus. Courtesy: Yaskawa America Inc.

While these inconsistencies in documentation that have developed over the years can be confusing, referencing the protocol data address is consistent regardless of the offset addressing scheme used.

The client uses function codes to exchange data with server nodes.

Function codes are typically described in hex notation in Table 3.

Table 3: Modbus function codes are typically described in hex notation: Courtesy: Yaskawa America Inc.

Table 3: Modbus function codes are typically described in hex notation: Courtesy: Yaskawa America Inc.

For devices that are configured to only address holding registers, functions 0x03 and 0x10 are the most common.

How to use Modbus with industrial controls

When using industrial control equipment, like PLCs, human machine interfaces (HMIs), and variable frequency drives (VFDs), the Modbus frames are typically handled in the background, and the function codes are transparent to the engineer (who simply picks “read registers” from a drop-down list). For advanced troubleshooting, and when deploying custom embedded sensors or edge controller hardware, it’s important to understand how the Modbus frames are structured. By using serial bus monitoring software on a PC, or a digital scope with protocol decoding, it is possible to identify and monitor the contents of each request and response message transmitted on a Modbus serial network.

A request to read data (initiated by the client) contains the node address of the server device that holds the data, the read function code, the data address requested, and the number of sequential 16-bit registers to read.

For example, to read data registers 10 and 11 (0xA and 0xB) from server node 9 (0x9) the client sends the following request, 8 bytes total, in Table 4.

Table 4: Modbus example of how to read registers 10 and 11 (0xA and 0xB). Courtesy: Yaskawa America Inc.

Table 4: Modbus example of how to read registers 10 and 11 (0xA and 0xB). Courtesy: Yaskawa America Inc.

Every server on the serial bus will receive this message, but only node 09 will acknowledge that it has received a command. Assume the value of register 10 is 3243 (0x0CAB) and the value of register 11 is 4660 (0x1234). Server node 09 will transmit the following response to the client, 9 bytes total, in Table 5.

Table 5: Server node 09 will transmit the following response to the Modbus client, 9 bytes total. Courtesy: Yaskawa America Inc.

Table 5: Server node 09 will transmit the following response to the Modbus client, 9 bytes total. Courtesy: Yaskawa America Inc.

The server validates that the response came from the expected node (09), that the node is responding to the expected function (03) and that the node is responding with the expected amount of data (4 bytes to satisfy the request of two 16-bit registers). The following data represents the contents of registers 10 and 11 (shown in hex).

Each serial frame concludes with a cyclic redundancy check (CRC). The CRC algorithm uses a series of exclusive OR (XOR) and shift operations to calculate a two-byte value. When the serial transmission is received, the calculation is repeated. If the CRC value calculated upon receipt does not match the value transmitted, the data must have been corrupted during transmission, and the request is ignored (and typically retried).

The request to write data to a server node (initiated by the client) is very similar. The request consists of the node address of the server device that holds the data, the write function code, the data address of the first register to write, the number of bytes to write, and the data to be written.

For example, to write values of 4 (0x4) and 256 (0x0100) to data registers 10 and 11 (0xA and 0xB), respectively, on device node 9 (0x9) the client sends the following request (Table 6).

Table 6: Modbus client example shows request to data registers 10 and 11. Courtesy: Yaskawa America Inc.

Table 6: Modbus client example shows request to data registers 10 and 11. Courtesy: Yaskawa America Inc.

Each server on the network receives the message, but only node 09 processes the request. After completing the requested task (writing 4 to register 10 and 256 to register 11), node 9 transmits back to the client that the task is completed (Table 7).

Table 7: Modbus example: Node 9 transmits back to the client that the task is complete. Courtesy: Yaskawa America Inc.

Table 7: Modbus example: Node 9 transmits back to the client that the task is complete. Courtesy: Yaskawa America Inc.

Again, the server validates that the expected node address write was complete. If an exception error is generated, or the request times out, the server can decide to retry or flag an error for the client node.

Reading and writing other data types (coils and inputs) follows a very similar format. In all cases, the client initiates the request, and the requested server node acknowledges completion of the task.

Broadcast messages are a unique exception to this request/acknowledge exchange. If a network consists of a multitude of identical server nodes, a server may broadcast a message to all devices simultaneously. Instead of initiating the request with the node address, the client initiates the request with the broadcast address 00. All server nodes recognize and act on a 00 request, regardless of their node address. Because the command is issued to all nodes simultaneously, no response can be transmitted (because only one device may transmit at a time on the serial bus). Broadcast messages can be helpful if a client needs to synchronize date/time on all connected server nodes simultaneously. Broadcast also can be helpful to synchronize signaling at multiple edge nodes (such as a network of distributed warning lamps that are to all synchronously illuminate) without individually (sequentially) messaging each node.

Modbus hardware overview: Five reasons to use RS-485

The Modbus protocol may be implemented on a variety of different physical layers.

Legacy installations may use TIA-422 (RS-422), and TIA-232 (RS-232) may be used in specific applications, however neither are common.

EIA/TIA-485 (RS-485) is the most common and versatile serial interface used today.

Five key features of RS-485 that make it well suited for industrial control communication applications are:

  1. Differential signaling provides excellent signal noise immunity.

  2. Multi-drop linear bus topology allows connection of multiple nodes.

  3. Bus lengths up to 1200m (4000ft) are supported without additional hardware.

  4. Asynchronous communication is simple to integrate with low-cost microcontrollers and industrial wireless transmitters.

  5. Transceivers are inexpensive to incorporate into embedded controls.

 How single-ended signaling works in Modbus

Single-ended signaling is simplest means of transmitting a digital signal from a transmitter to a receiver (such as RS-232). In a single-ended network, the transmitter switches a voltage source on and off. The receiver compares the signal to the common reference, converting a series of voltage pulses to the ones and zeros of a serial data transmission. Single-ended signaling is susceptible to electromagnetic interference (EMI) because all devices share the same common reference. When noise is introduced on the line, the voltage difference between the signal and the reference becomes difficult to differentiate, potentially causing ones and zeros to be interpreted incorrectly.

Differential signaling actively drives both transmission lines. This approach provides excellent noise immunity, because any disturbance induced on the lines is canceled when the receiver compares the non-inverted and inverted signals.

Figure 1 Modbus example compares single-ended and differential signals. Courtesy: Yaskawa America Inc.

Figure 1 Modbus example compares single-ended and differential signals. Courtesy: Yaskawa America Inc.

On a multi-drop linear serial bus, all devices are [typically] connected to the same two signal lines. The main bus cable must be linear, meaning all devices are tapped into the same bus cable, with no “Y” or “star” connections. The device “tap” conductors shown should be kept as short as practical so that the bus appears as a single wire. The bus has two definitive ends, no more, no less. Line termination is shown at each end of the linear bus in Figure 2. The relative physical location of the client versus servers, or assigned number of the server node addresses is unimportant. The four devices shown could be rearranged in any order without effect on operation or configuration.

Figure 2 Modbus example shows a typical linear bus configuration. Courtesy: Yaskawa America Inc.

Figure 2 Modbus example shows a typical linear bus configuration. Courtesy: Yaskawa America Inc.

The Modbus specification ensures that a minimum of 32 devices (including the client) must be supported on any RS-485 installation. The limitation is a function of the voltage drop that each transceiver imposes on the signal lines, and the maximum allowable length of the serial bus. It is important to note that 32 is not a hard limit of nodes. If the node transceiver specifications are unknown, limiting devices to 32 is required. However, modern high impedance RS-485 transceivers are commonly available with fractional unit load ratings. For example, if all the nodes use 1/8 unit load transceivers, the total number of devices allowed is 256 (256 nodes * 1/8 unit load = 32 unit loads). Signal repeaters also provide a cost-effective means to increase the number of allowed nodes. An active repeater allows two fully loaded bus segments to be connected to operate as one network. In a custom IoT sensor network, a second transceiver to act as a repeater may be easily and inexpensively embedded into the device control design if required.

What is maximum Modbus bus length?

Maximum bus length (the sum of all the cable segments between nodes) on an RS-485 installation is generally limited to 1200m (4000ft). It is absolutely critical to use the correct cable. Improper cable specification is the primary reason Modbus (RS-485) installations fail. Modbus over 485 requires a shielded twisted-pair (STP) cable, typically 24 AWG. However, not all STP cables are created equally. Also required for optimal performance is a nominal characteristic impedance of 120Ω, and a minimal conductor-conductor capacitance (<15pF/ft). Belden 9841 is often considered the gold standard for RS-485 cable. If considering an alternative cable, compare specifications carefully. Other cable constructions (such as CAT5) will work on a test bench, and may operate marginally for months in the field, but will not provide the long-term reliability of a purpose-designed cable.

The Modbus implementation guide requires line termination on RS-485 networks. When termination is applied, it must always be identical at both ends of the network. In practice, there are trade-offs associated with termination. The purpose of termination is to damp signal reflections – to prevent transmitted signals from reflecting off the end of the bus and interposing with the next data pulse. Each time the signal reaches the end of the bus, it is reflected and loses a significant amount of energy. After three to six reflections, the signal is generally attenuated enough that it no longer poses a risk.

Signals propagate down the cable at roughly 2/3 the speed of light. On a “short” cable, the signal easily completes six reflections before the next signal is transmitted, and no termination is required. As the cable length increases, the time required to complete six reflections increases, and it takes longer for the reflections to attenuate. In these situations, termination is required.

The second variable impacting termination is the bit width. At 9600 baud, the signal has ~50μs to stabilize before being sampled. At 115k baud, the signal has only ~4μs to stabilize, making it more susceptible to interference from reflections. As baud rate increases, it becomes more likely that termination is required.

Conservatively allowing for six reflections, a typical 9600 baud installation would not require termination unless the bus length exceeded 2800 ft. Each time the bitrate is doubled, the allowable unterminated cable length halves (that is, 1400 ft at 19200 baud).

For simplicity, many device manufactures recommend 120Ω termination on all networks, regardless of length or bitrate. However, resistive termination is not ideal on short networks with a large number of transceiver unit loads, because the resistive termination introduces a voltage drop on the bus. As voltage drop increases, the voltage difference between the inverted and non-inverted signals decreases, making the network more susceptible to interference. Few manufacturers implement the recommended resistor-capacitor (RC) termination (120Ω resistance in series with a 1nF capacitor). The addition of the series capacitor eliminates the voltage drop associated with DC steady state current through the terminating resistor – providing required attenuation of reflected signals without sacrificing signal voltage margin. The only potential drawback of adding capacitance is the introduction of an RC delay that may impact applications that require very high bitrates, in excess of those typically used in Modbus RS-485 applications (typically 9600 or 19200, seldom greater than 115k).

Line polarization (as shown in Figure 2) is not required. If implemented, it must be implemented only once on the network (often integrated into the client device). The purpose of polarization resistors is to “pullup” and “pull-down” the signal lines to known states when no devices are transmitting. Polarization is not generally implemented, unless in response to a specific issue.

Bitrate (baud) describes the number of bits transmitted per second. Using the example from the protocol section, reading two 16-bit registers requires an 8-byte request from the client, followed by a 9-byte response from the server. In Modbus RTU, each serial frame must be separated by a silent interval of at least 3.5 characters (separating the request from the response). To read two registers, the entire process requires enough time to transmit 8+3.5+9 = 20.5 bytes over the serial network. A data byte is comprised of 8 bits. However, a Modbus RTU serial byte is 11 bits long. Each byte transmission consists of 1 start bit + 8 data bits + 1 parity bit + 1 stop bit = 11 bits. Over serial, 20.5-byte characters requires 20.5*11 = 226 bit times. At 9600 bits per second, the time required to complete this transmission is 226/9600 = 24ms.

When planning a network, consider how many data registers need to be transmitted, how long it will take to transmit the required data and how often the data must be queried. To minimize EMI and signal reflection, and maximize reliability, it is recommended to start at 9600 or 19200 baud, and only select higher bitrates if the additional speed is required.

The ability of Modbus (RS-485) to connect widely distributed nodes over long distances, without repeaters and switches, can be beneficial for many low-bandwidth IoT monitoring and control applications. The asynchronous and latency tolerant nature of serial communication also lends itself to easily create hybrid wireless networks. If it’s impractical to run 1200m of cable, the Modbus serial frame 0can be simply encapsulated in an RF (radio frequency) frame, sent over the air and converted back to wire by the receiving radio. Using this method, moving from wire to wireless is transparent to the devices on the network. Using 900MHz industrial mesh networking technology, networks of Modbus devices can easily expand to cover several square miles, instead of being limited to a 1200m bus cable.

Modbus is not limited to serial communication. Modbus TCP is a widely used implementation that employs the same data types and function codes as Modbus RTU, but wraps requests and responses in TCP/IP packets for transmission over Ethernet.

When is Modbus appropriate for automation applications

For applications that require high speed and bandwidth, TCP/IP is the clear choice. However, for many data acquisition applications, Modbus RTU over RS-485 remains a compelling and cost-effective alternative. The two hardware approaches are not mutually exclusive – it is common for controller systems to manage both TCP/IP and RS-485 device networks, depending on the data transmission requirements. The details of Modbus’ evolution over the past four decades may seem overwhelming, but at its core, Modbus and RS-485 provide a simple and reliable solution to network many of the “things” that comprise the industrial internet of things and make industrial processes run efficiently.


Author Bio: Lucas Paruch is a Sr. Development Engineering Manager for Medium Voltage Drives at Yaskawa America, Inc. Paruch has been leading and developing innovative control and communication solutions for more than 20 years. He is an Electrical Engineering alumnus of the University of Wisconsin-Platteville.