Modbus RTU

What it is

Modbus is a protocol designed specifically for exchanging process data between industrial control devices. It was developed by Modicon in 1979 and operates at the application layer. In the Modbus Organization's own terms, it is an application layer messaging protocol positioned at level 7 of the OSI model, providing client/server communication between devices connected on buses or networks.

Modbus has lasted because it is simple. For more than forty years it has looked at the data inside a device as numbered registers and defined a small set of commands to read and write them. Learning it does not take a day, and almost every device on a shop floor has a Modbus interface somewhere.

On a serial line there are two transmission modes, ASCII and RTU. In the organisation's words, ASCII frames require nearly twice the number of bits as RTU frames, making Modbus ASCII slower than Modbus RTU. Industrial practice therefore settles on RTU — binary, tightly packed frames.

How it works

Modbus is built on a master/slave model. In the organisation's historical description, one PLC functioned as the master Modbus device and all other devices functioned as Modbus slaves. The master always initiates: a slave never speaks on its own, it answers when asked.

That single rule determines the protocol's whole behaviour. There is no collision handling to manage, no arbitration mechanism, no network configuration to plan. In exchange, an event inside a slave waits until the master polls that device again, which makes Modbus a poor foundation for an event-driven architecture. Up to 247 separate Modbus slave devices can sit on the same cable.

The physical layer is left open: Modbus is compatible with any lower-level communication protocols including EIA/TIA-232, EIA/TIA-485 and Ethernet, the latter via TCP/IP. Drive applications settle in practice on two-wire RS-485 — multi-drop, tolerant of distance, inexpensive.

The data model is four tables: discrete outputs (“coils”), discrete inputs (“contacts”), analog input registers and holding registers. Holding registers are 16-bit word read-write data that can be altered by an application program. On a drive, speed reference, ramp times and current limit are the sort of parameter that lands in those holding registers.

One fact an engineer has to carry into a Modbus project: Modbus does not define what the registers mean. There is no device profile equivalent to CiA 402 in CANopen. Which register is the speed reference and which is the status word is written in the manufacturer's own map. The first task in any Modbus integration is therefore to obtain the register map — the protocol is already simple, the work is in the device's map.

When to choose it

Modbus RTU is the right choice wherever communication is not on the cycle-critical path of the machine: handing a drive a speed reference, reading its status, collecting an alarm, writing a recipe parameter. On single-axis machines, or a handful of axes that do not need to track one another, it is more than sufficient.

Its second strong case is integration. When a device is added to an existing plant there is a good chance a Modbus line already runs there, and being able to connect without laying a new fieldbus is often worth more than technical superiority.

Against that, Modbus RTU is not the right layer for any application where axes must move in step with one another. Its poll-and-answer model does not offer a deterministic cycle base; CANopen or EtherCAT belongs there. The same applies where a fast event-driven response is required and the polling interval becomes the deciding factor.

At SMB

In the SMB catalogue Modbus RTU is represented by variants of the SD-LP family and by products carrying an RS-485/RS-232 interface. Because the SD-LP family offers the same drive in Modbus RTU, CANopen and EtherCAT variants, a machine commissioned on Modbus RTU can later move to a more deterministic protocol inside the same family — the motors, the cables and the mechanical design stay as they are.

Register maps are published in the product documents and should be downloaded from the relevant product's documents tab before integration begins.

The product list below is generated live from the Modbus node of the catalogue.

Common questions

RTU or ASCII? RTU, in industrial practice. In the organisation's own words, ASCII frames require nearly twice the number of bits as RTU frames, which makes Modbus ASCII slower. ASCII's only practical advantage is that frames are human-readable, and that pays off during debugging rather than on a production line.

How many devices can I put on one line? Modbus supports up to 247 separate slave devices on a single network. The practical limit is usually not that number but the total time to poll every device in turn: as the device count rises, so does the gap between two polls of the same device.

Where does the register map come from? Modbus does not define what the registers mean — there is no device profile equivalent to CiA 402 in CANopen. Which register is the speed reference and which is the status word is written in the manufacturer's own map. Integration therefore starts with the register map in the product document.

RS-485 or RS-232? Drive applications settle on two-wire RS-485: multi-drop, tolerant of distance, and able to carry several devices on one line. RS-232 is a point-to-point connection, used with a single device over a short distance, mostly for service and commissioning.

Can I synchronise axes over Modbus? No, and it is not worth attempting. The poll-and-answer model does not provide a deterministic cycle base. Wherever axes must move in step with one another, CANopen or EtherCAT is the layer to use.