Modbus Guide: RTU, TCP, Registers and Troubleshooting

This practical Modbus guide explains Modbus RTU and Modbus TCP for automation engineers. It covers RS-485 communication, Modbus registers, function codes, addressing, CRC, byte and word order, raw value conversion, example frames and troubleshooting.

If you already have a Modbus message and want to inspect it, use the online Modbus decoder.

What is Modbus?

Modbus is a simple, royalty-free application-layer protocol. The client sends a request and the server responds—the server does not send messages on its own initiative. Terminology has been updated from master/slave → client/server.

Modbus is an application layer communication protocol widely used between PLCs, controllers, meters, sensors, drives and building automation devices.

A client sends a request to a server device. The server processes the request and returns a response.

Modbus RTU vs Modbus TCP

1.1 Hexadecimal

Modbus messages travel as bits (0/1). Four bits form an easy-to-read hexadecimal digit (0–F), so binary data is almost always presented in hex. The hexadecimal system has a base of 16. In practice, Modbus messages are commonly converted from binary form to hexadecimal to make them easier to read. You’ll need to interpret hex during commissioning and troubleshooting.
A bit is the smallest unit of information (0 or 1).

• One hex digit represents four bits.
• Byte = 8 bits = two hex digits.
• 16‑bit register = 2 bytes = four hex digits.

Bit string 0001 0010 1011 1100 in hexadecimal is 0x12BC.

The table below shows how each 4-bit binary value maps to one hexadecimal digit.

1.2 Modbus RTU bus wiring and voltage levels

The Modbus RTU message is transmitted through a serial bus. Branches in the bus should be avoided, as they cause communication problems. The bus is usually terminated at both ends with a 120Ω resistor. The purpose of this resistor is to prevent reflections and thus reduce interference in bus communication.

RS-485 transmits data using the voltage difference between the two bus conductors. In many practical RS-485 installations, the differential waveform can be observed at roughly a few volts in either direction, and values around -5 V to +5 V are a useful simplified example of what the signal may look like on an oscilloscope.

The exact voltage is not fixed at ±5 V. It depends on the transceivers, supply voltage, bus loading, termination and biasing. The receiver determines the logic state from the polarity and magnitude of the differential voltage between the conductors rather than from either conductor having one exact voltage relative to ground.

The figure below therefore shows a simplified example of an RS-485 differential waveform. A real installation may have a different amplitude.

A and B naming conventions are also not completely consistent between manufacturers. When connecting devices from different manufacturers, use the terminal definitions in the device documentation rather than assuming that one universal A/B polarity convention applies.

1.3 Modbus RTU bus cable

For RS-485 buses, a twisted pair cable with as much shielding as possible should be used. The better the shielding, the fewer disturbances occur in the bus.

RS-485 communication is based on differential signal transmission, where the cable conductors form a twisted pair. This structure effectively reduces electromagnetic interference from external sources such as frequency converters, relays, and other devices using high currents. In addition, the shielding helps to prevent interference from coupling into the bus and also reduces emissions from the bus into the environment.

Special attention should be paid to grounding and connecting the cable shield. It is generally recommended that the shield is grounded only at one end to avoid ground loops caused by potential differences.

1.4 Modbus RTU bus speed and maximum length

RS-485 segment length is affected by the baud rate, cable characteristics, topology, transceivers, termination and EMC environment. There is therefore no single Modbus RTU distance table that applies to every installation.

As a rough practical illustration, lower baud rates generally tolerate longer cable runs better than high baud rates:

These values are not Modbus protocol limits. They are practical examples showing the relationship between communication speed and cable length. The actual permitted length should always be determined from the specifications of the cable, transceivers and connected devices.

In electrically noisy installations, reducing the baud rate may increase communication margin, but wiring, topology, termination and grounding should still be corrected rather than treating a lower baud rate as the only solution.

1.5 Reflections in the cable

When a reflection occurs, the electrical signal “bounces back” and distorts the bus voltage levels. Distorted voltage levels lead to communication errors.

To reduce reflections, the termination resistance should be reasonably close to the characteristic impedance of the transmission line.

120 Ω is common in RS-485 installations because many cables intended specifically for RS-485 have a characteristic impedance close to this value. Real building-automation installations do not always use a 120 Ω cable, however.

For example, some Nomak cables commonly used in Finnish building-automation installations have a characteristic impedance of approximately 75 Ω. If a 75 Ω transmission line is terminated with 120 Ω, the termination does not match the cable impedance exactly.

The reflection coefficient can be estimated from:

[ \Gamma = \frac{Z_L - Z_0}{Z_L + Z_0} ]

where:

• (Z_L) is the termination resistance
• (Z_0) is the characteristic impedance of the cable

For a simplified example with a 75 Ω cable and a 120 Ω termination:

[ \Gamma = \frac{120 - 75}{120 + 75} ]

[ \Gamma \approx 0.23 ]

The impedance mismatch can therefore create a reflected component corresponding to roughly 23% of the incident voltage amplitude.

This does not automatically mean that the RS-485 network will fail. Real behaviour also depends on cable length, baud rate, driver impedance, receiver thresholds, topology and other electrical effects. In practice, many such networks still operate reliably.

The example illustrates the important principle: termination resistance and cable characteristic impedance belong to the same electrical design question.

A 120 Ω resistor should not be treated as a magic Modbus component that fixes every RS-485 network. It is common because it matches many RS-485 cables reasonably well.

1.6 Principle of termination

The purpose of the termination resistor is to absorb the signal at the end of the cable so that it does not reflect back into the line. If the bus is long and the speed is high, without termination the signals are easily distorted and the messages become difficult to read. Termination resistors are always placed at both ends of the bus.

What termination resistor should I use for RS-485?

Use a termination resistor close to the cable’s characteristic impedance at each physical end of the bus. 120 Ω is common for RS-485 cabling, but if the installed cable has a different specified characteristic impedance, the termination should be selected to match that cable as closely as practical.

1.7 Biasing and idle state

Termination alone is not enough if the bus remains floating in an idle state. In such a case, the receiver inputs may remain undefined and generate erroneous bit interpretations. For this purpose, biasing resistors are used, which set a small DC voltage difference between the A and B lines of the bus. Typically, biasing is implemented with a single resistor pair at one point in the bus, most often at the master device.

1.8 Practical considerations

• Only one pair of termination resistors: Termination should only be done at the two ends of the bus. If there are more terminations, the signal is attenuated too much and communication may be disrupted.
• Cable length and speed: The longer the bus and the higher the baud rate, the more critical correct termination becomes. On short cables and at low speeds, the bus can often operate without termination.
• Impedance mismatch: In practice, buses often work quite reliably even with some impedance mismatch, but the closer the termination matches the cable’s characteristic impedance, the fewer errors occur.

1.9 Client and server

There are two device roles in Modbus: Client (Master) and Server (Slave). In a Modbus RTU network there is typically one client and up to 247 servers. Each server is assigned a unique Modbus address from 1–247. Avoid using address 1, as it is a common default and easily causes conflicts in practice.

• The client reads or writes registers. Usually a PLC.
• The server returns values or stores them on request. Usually a field device.
• The server does not send messages without a request.

1.10 Registers

There are four types of Modbus registers (Coil, Discrete Input, Input Register, Holding Register). They differ in size (1 bit / 16 bits) and access rights (R/W). Vendor documentation may use either the 1…49999 or the 0…65535 register space. Registers may also have vendor‑specific restrictions that deviate from the standard, such as write limitations on Coil registers or a limit on how many registers can be read at once.

Also note 0- vs 1-based indexing for the starting register—always check the device datasheet.

1.11 Function codes

Function codes are one‑byte commands used to read/write a given register type at one or more addresses. In addition to the standard codes, some devices may have manufacturer‑specific codes, and not all devices necessarily support every code. Below is a quick view of the official function codes from modbus.org.

1.12 CRC (Cyclic Redundancy Check)

Each RTU frame ends with a 16‑bit CRC. The sender and receiver compute the CRC from the message bytes and compare the results; a change in even a single bit causes an error.

1.13 Parity

Parity can be N (none), E (even), or O (odd). The parity setting must match on both ends, otherwise errors occur. The parity bit ensures the number of bits with value 1 in the frame has the defined even/odd parity. If there would be an odd number of 1s and parity is set to E, the parity bit switches to one (1).

1.14 Byte and word order (endianness)

Modbus register values are transferred as bytes. For single 16-bit registers this is usually straightforward, but 32-bit and 64-bit values are built from multiple registers, and devices may use different byte or word orders.

By default, Modbus register data is commonly shown in big-endian order, where the most significant byte is listed first. However, some devices swap the two 16-bit words of a 32-bit value, swap bytes inside each word, or do both.

For this reason, the byte order and word order must always be checked from the device-specific register map.

Common 32-bit orders include:

A practical example is shown in section 1.16 Converting raw register values.

1.15 Data types

In Modbus, internal device variables such as temperatures, states, alarms, counters, and setpoints are transferred as registers and bit values. The Modbus protocol itself does not define whether a register contains a signed integer, unsigned integer, floating-point value, status word, or scaled engineering value.

A Modbus register is 16 bits. This means one register can directly contain a 16-bit value, while larger values are formed by combining multiple consecutive 16-bit registers.

1 register  = 16 bits
2 registers = 32 bits
4 registers = 64 bits

Common Modbus data types include:

The client must know the correct data type from the device documentation. If the wrong data type is selected, the device may respond correctly, but the displayed value will be wrong.

For example, the same raw 16-bit register can be interpreted as UINT16 or INT16. The same two consecutive registers can be interpreted as UINT32, INT32, or FLOAT32. For 32-bit and 64-bit values, the byte order and word order also matter.

Practical examples of signed and unsigned values, byte order, word order, scaling, offsets, and wrong-value troubleshooting are shown in section 1.16 Converting raw register values.

1.16 Converting raw register values

When reading Modbus registers, communication can work correctly even if the displayed value is wrong. This usually means that the device responds to the request, but the client interprets the returned register data with the wrong data type, byte order, word order, scaling factor, offset, or register address.

A valid Modbus response does not automatically mean that the engineering value is correct.

One register is 16 bits

A Modbus register contains 16 bits:

1 register = 16 bits = 2 bytes = 4 hex digits

One register can directly hold 16-bit values:

Larger values are formed from multiple consecutive registers:

If the device documentation says that a value is FLOAT32, the client must read two consecutive registers and combine them correctly.

Signed and unsigned values

The same raw 16-bit register can produce different values depending on whether it is interpreted as signed or unsigned.

Example:

Raw register = 0xFF9C

As an unsigned value, 0xFF9C means 65436. As a signed 16-bit value, using two’s complement, it means -100.

This matters for values that may go below zero, such as outdoor temperature, pressure difference, offsets, control corrections, and power import/export values.

If the scale factor is 0.1, the final value is:

-100 x 0.1 = -10.0 °C

32-bit values from two registers

A 32-bit value is built from two 16-bit registers.

Example:

Register 1 = 0x42F6
Register 2 = 0x0000

The raw bytes are:

42 F6 00 00

The same bytes can be interpreted in different ways:

The raw data is identical. Only the interpretation changes.

Byte and word order

A 32-bit value consists of four bytes, often described as:

A B C D

Because Modbus registers are 16-bit, the value is split into two registers:

Register 1 = A B
Register 2 = C D

Common 32-bit byte and word orders are:

Using the example registers:

Register 1 = 0x42F6
Register 2 = 0x0000

The possible byte sequences are:

This is one of the most common reasons why a Modbus value looks wrong even though the request and response are valid.

Scaling and offset

Many devices send an integer value that must be converted into an engineering value.

Engineering value = raw value x scale factor

Example:

Raw value = 234
Scale factor = 0.1
Engineering value = 234 x 0.1 = 23.4 °C

Some devices also use an offset:

Engineering value = raw value x scale factor + offset

Example:

Raw value = 234
Scale factor = 0.1
Offset = -50
Engineering value = 234 x 0.1 - 50 = -26.6

The scale factor, offset, and unit must be checked from the device-specific register map.

Address, register type, and function code

Wrong values can also come from reading the wrong place.

Some manuals document holding registers as 40001, 40002, 40003, while the actual Modbus request uses zero-based addresses 0, 1, 2. This means that a register documented as 40001 may need to be requested as address 0.

Also check that the correct register area and function code are used:

Reading address 10 with Function Code 03 is not the same as reading address 10 with Function Code 04.

Troubleshooting method

Start with the raw register values before converting them into engineering units.

For one-register values, compare:

For two-register values, compare:

If one interpretation produces a realistic value and the others produce unrealistic values, the realistic one is usually the intended format.

Common reasons for wrong Modbus values

• wrong register address
• 0-based vs 1-based address confusion
• wrong register type or function code
• signed value interpreted as unsigned, or the opposite
• 32-bit value read as 16-bit
• wrong byte order or word order
• missing scale factor or offset
• wrong unit
• copied conversion settings from another register

Always check the device-specific register map and record the raw register values when troubleshooting.

1.17 Example messages

Read Coils: Function Code 01

Request: 01 01 00 05 00 03 6C 0A

Response: 01 01 01 02 D0 49

Read Discrete Inputs: Function Code 02

Request: 01 02 00 02 00 02 58 0B

Response: 01 02 01 00 A1 88

Read Holding Registers: Function Code 03

Request: 01 03 00 07 00 02 75 CA

Response: 01 03 04 00 01 00 06 2B F1

Read Input Registers: Function Code 04

Request: 01 04 00 00 00 02 71 CB

Response: 01 04 04 00 01 00 0B EB 83

Write Single Coil: Function Code 05

Request: 16 05 00 09 00 00 1E EF

Response: 16 05 00 09 FF 00 5F 1F

Write Single Register: Function Code 06

Request: 16 06 00 09 00 01 9B 2F

Response: 16 06 00 09 00 01 9B 2F

Write Multiple Coils: Function Code 15

Request: 16 0F 00 09 00 05 01 0D 32 78

Response: 16 0F 00 09 00 05 46 ED

Write Multiple Registers: Function Code 16

Request: 16 10 00 09 00 05 0A 00 09 00 02 00 4D 00 00 00 01 13 5B

Response: 16 10 00 09 00 05 D3 2F

1.18 Error codes

After a Modbus request, several outcomes are possible:

• The server processes the request and sends a normal response.
• The server receives the request but it has CRC/parity errors, so it is ignored.
• The server never receives the request, so it cannot respond.
• The server cannot process the request for some reason and returns an exception.

Observe device‑specific limitations, e.g., empty addresses in the register map should be avoided in polling.

In exception responses, the returned function byte is function code + 0x80. For example:

Example exception exchange:

Request: 01 01 00 42 00 03 DC 1F

Response: 01 81 01 81 90

Modbus exception codes:

1.19 RX and TX LEDs

On converters/sensors in field devices, TX blinks on transmit and RX on receive—useful basic diagnostics during installation. On the client device, a transmission should be followed by a response; on the server device, a reception should be followed by a transmission.

Modbus TCP frame and MBAP header

A Modbus TCP message contains an MBAP header followed by the Modbus protocol data unit.

The MBAP header contains:

• Transaction ID
• Protocol ID
• Length
• Unit ID

Modbus TCP normally uses TCP port 502.

Modbus TCP frame structure

Unlike Modbus RTU, Modbus TCP does not include the RTU CRC field.

Modbus RTU vs Modbus TCP frames

The underlying Modbus function codes and register concepts are the same, but the transport framing is different. Modbus RTU uses a device address and CRC, while Modbus TCP uses the MBAP header and TCP/IP networking.

Practical tips

• Don’t use the default address 1, and document addresses in the I/O list.
• Check 0/1‑based indexing and data types; don’t mix INT/UINT/DINT in the same read.
• On an RTU bus, ensure termination and a simple serial topology; an incorrect topology increases errors.

Related Modbus tools and guides

• Decode Modbus RTU and TCP frames online
• Troubleshoot common Modbus RTU problems
• Find why a Modbus value is wrong
• Understand Modbus 40001, 0-based and 1-based addressing
• Check RS-485 wiring for Modbus RTU
• Design a Modbus register map for integration
• Test a Modbus device before release