Modbus is an open application-layer communication protocol used to exchange data between PLCs, HMIs, motor drives, sensors, meters and other industrial devices. RS-485 is the differential electrical interface most commonly used to carry Modbus RTU messages on serial networks. The two terms are therefore related, but they do not describe the same thing.

In simple terms: RS-485 provides the electrical road between the devices, while Modbus provides the language they use on that road. A PLC can ask a drive to read a register, change a setpoint or report its status through Modbus, while RS-485 carries those serial bits over the cable.

What is Modbus?

Modbus was introduced by Modicon in 1979 and remains one of the most widely supported protocols in industrial communication. It defines a standardized request/reply messaging structure rather than one mandatory cable or electrical interface.

Current Modbus terminology uses client for the device that initiates a request and server for the device that processes the request and returns a response. Older manuals commonly use the terms master and slave, so both naming systems may be encountered in existing installations.

A PLC can act as a Modbus client and read operating data from a variable frequency drive. An HMI can display registers from a controller, while a SCADA system can collect measurements from many Modbus devices.

What is RS-485?

RS-485 is a balanced differential electrical interface designed for serial multipoint networks. Instead of evaluating one signal conductor against ground, an RS-485 receiver evaluates the voltage difference between two conductors, commonly labelled A and B.

Differential signalling provides good resistance to common electrical noise, which is one reason RS-485 is widely used around motors, contactors and industrial drives. It is especially useful where several devices must share one serial bus.

The most common Modbus installation uses two-wire half-duplex RS-485, where the same differential pair is used for transmission and reception. RS-485 itself is not limited to that arrangement; four-wire implementations are also possible.

Older references often state that RS-485 supports “a maximum of 32 devices.” The traditional specification is actually based on 32 unit loads. Modern transceivers can present only 1/2, 1/4 or 1/8 of a traditional unit load, so properly designed networks can contain more than 32 physical nodes.

How should a Modbus RS-485 network be wired?

A two-wire Modbus RS-485 installation should normally use a linear bus or daisy-chain topology. The main cable should pass from one device to the next, while long uncontrolled star branches should be avoided.

At higher data rates or longer cable lengths, termination is normally applied at the two physical ends of the main bus. Twisted-pair RS-485 cables commonly have a characteristic impedance around 120 Ω, so approximately 120 Ω termination is frequently used. Terminating every device on the network can overload the line.

Some networks also require bias or fail-safe resistors to establish a defined idle state when no transmitter is actively driving the bus. Modern transceivers may already include fail-safe receiver behaviour, so external biasing should follow the equipment manufacturer's recommendations.

A/B naming also deserves attention. Manufacturers have not always used A and B with the same polarity convention. If two devices refuse to communicate, compare the actual terminal definitions in both manuals rather than assuming that A always means positive and B always means negative.

How does Modbus communication work over RS-485?

On a typical serial Modbus network, one client/master sends a request addressed to one server/slave. All devices connected to the RS-485 bus can electrically receive the message, but only the addressed server should return a normal response.

For example, a request can tell server address 1 to write a register using Function 06. After the transaction is complete, the client can address server 2 and use Function 03 to read one or more holding registers. This controlled request/response behaviour prevents several devices from transmitting simultaneously on the normal two-wire bus.

Modbus RS-485 communication animation

The simplified animation below shows one client communicating with two Modbus servers on the same RS-485 pair. It is intended to illustrate bus direction and device addressing; a real Modbus RTU frame also includes the full data field and CRC.

What is Modbus RTU?

Modbus RTU is the compact binary serial transmission mode of Modbus. A basic RTU frame contains Address + Function Code + Data + CRC.

The address identifies the server, the function code defines the requested operation, the data field contains register addresses or values, and the 16-bit CRC detects corrupted frames.

Normal serial server addresses range from 1 to 247. Address 0 is reserved for broadcast requests. A server does not normally send a response to a broadcast.

RTU frame boundaries also depend on timing. At baud rates up to 19,200 bit/s, consecutive RTU frames require a silent interval of at least 3.5 character times.

Example of a valid Modbus RTU write request

Suppose server address 25 must receive decimal value 3987 in holding-register protocol address 0. Because only one register is being written, Function 06 — Write Single Register is simpler and more appropriate than Function 16.

Decimal server address 25 = 0x19
Register address 0 = 00 00
Decimal value 3987 = 0F 93

Before CRC:

19 06 00 00 0F 93

The calculated CRC is 0x8FCF. Because Modbus RTU transmits the low CRC byte first, the complete frame becomes:

19 06 00 00 0F 93 CF 8F

A successful Function 06 response echoes the address, function code, register address and value. This is considerably clearer than creating an incomplete generic byte array whose byte count, register quantity or CRC byte order does not match the selected function.

What are Modbus coils and registers?

The standard Modbus data model contains four basic areas:

Coils: Single-bit read/write values.
Discrete Inputs: Single-bit read-only values.
Input Registers: 16-bit read-only values.
Holding Registers: 16-bit read/write values.

A sensor or transmitter may expose measured values through input or holding registers. A motor drive may use holding registers for control words, speed references, status words and parameters.

Modbus defines the data model, but manufacturers define the actual register map of each product. Two devices can both support Modbus and still use completely different register addresses.

What are common Modbus function codes?

01: Read Coils
02: Read Discrete Inputs
03: Read Holding Registers
04: Read Input Registers
05: Write Single Coil
06: Write Single Register
15: Write Multiple Coils
16: Write Multiple Registers

A device supporting Modbus is not required to support every function code. The supported functions must be checked in the device communication manual.

What do 0x, 1x, 3x and 4x mean?

Traditional Modbus documentation often uses prefixes to identify data areas: 0x for coils, 1x for discrete inputs, 3x for input registers and 4x for holding registers.

References such as 40001 are documentation conventions rather than literal values that always appear inside the Modbus frame. Software packages may display addresses as zero-based offsets, one-based offsets or full reference numbers.

Names such as 5x, 6x, 3x_bit or 4x_bit found in some HMI software are software-specific aliases or data-format options; they are not additional standard Modbus memory areas. They should therefore not be described as part of the universal Modbus specification.

How are 32-bit and floating-point values handled?

A standard Modbus register is 16 bits wide. A 32-bit integer or floating-point value normally occupies two consecutive registers.

The Modbus specification defines the register structure but does not force every manufacturer to arrange multi-register values using the same word order. If communication works but the value looks completely wrong, check byte order, word order, signed/unsigned format and scaling before blaming the physical network.

What is Modbus ASCII?

Modbus ASCII represents each message byte using hexadecimal ASCII characters. The frame begins with a colon and ends with CR/LF, and error detection uses LRC instead of the CRC used by RTU.

ASCII normally transfers the same Modbus information with more serial characters than RTU, so its data efficiency at the same baud rate is lower. Its character-oriented format can, however, be easier to inspect with simple diagnostic tools. It does not consume less cable energy simply because the values are encoded as ASCII.

What is Modbus TCP?

Modbus TCP carries Modbus application messages over TCP/IP and Ethernet. Standard Modbus TCP servers commonly use TCP port 502.

Modbus TCP uses an MBAP Header instead of the serial RTU address/CRC framing. The RTU CRC is not appended to a normal Modbus TCP message.

For comparison with another common Ethernet-based industrial protocol, see EtherNet/IP vs Modbus TCP.

Does Modbus communicate directly over USB?

USB should not normally be presented as another standard Modbus physical network alongside RS-485 or Ethernet. A USB-to-RS485 or USB-to-RS232 adapter typically appears to the computer as a virtual serial port, while Modbus RTU still operates on the serial side of the converter.

Similarly, a USB-to-Ethernet adapter simply gives the computer an Ethernet interface; Modbus TCP still operates over Ethernet and TCP/IP. The USB adapter is a transport interface, not a separate universal “Modbus USB” protocol.

Can devices from different manufacturers communicate automatically?

Not automatically. Modbus provides a common message structure, but each manufacturer defines its own register map, scaling and supported functions.

A PLC from one manufacturer can communicate with a drive from another over Modbus RTU, but the PLC program must use the drive's correct register addresses, data types and function codes.

“Both devices support Modbus” therefore means integration is possible; it does not mean that connecting the wires is the only configuration required.

Can standard Modbus be used for emergency stop?

Standard Modbus should not be treated as a functional-safety protocol. Ordinary start, stop and process commands can be exchanged through Modbus, but an emergency-stop or certified safety function requires an appropriate safety architecture.

For example, a VFD may receive its normal run/stop command through Modbus while a safe torque off or emergency-stop function is handled separately through the drive's certified safety inputs and the machine safety system.

Why does Modbus RS-485 communication fail?

Start with the physical layer: check A/B wiring, cable condition, bus topology, shielding and termination. Then compare baud rate, parity and stop-bit settings.

If the physical network is correct, verify the server address, function code and register offset. Duplicate server addresses can cause two devices to respond to the same request and corrupt the bus traffic.

If the device responds but the displayed value is wrong, inspect zero-based versus one-based addressing, signed/unsigned interpretation, scaling and 32-bit word order.

Practical Modbus RS-485 checklist

1. Are both devices using the same Modbus mode?

2. Is the RS-485 A/B wiring correct according to both manuals?

3. Do baud rate, parity and stop-bit settings match?

4. Does every server have a unique address?

5. Is the requested function code supported?

6. Is the register address using the correct offset convention?

7. Is termination installed only where required at the ends of the main bus?

8. Are data type, scaling and 32-bit word order interpreted correctly?

Related Modbus and Industrial Communication Guides

Modbus FAQ · Modbus ASCII · Ethernet · EtherNet/IP vs Modbus TCP

Related Automation Pages

PLCs · HMI Panels · SCADA · AC Drives and VFDs · Sensors