Protocols · Modbus
Modbus RTU and TCP — A Practical Integration Guide
How Modbus RTU and TCP work, how to read a register map, and which scaling, polling and failure details cause most integration faults.
Quick answer
Modbus is a simple request-response protocol built on coils and registers. RTU runs over serial links; TCP runs over Ethernet. It carries data but not meaning, so the register map, scaling, word order and write permissions must be confirmed in writing. Modbus is ideal for meters, inverters and simple plant, not for fast interlocking.
A register model, not a data model
Modbus exposes coils, discrete inputs, input registers and holding registers. It does not define what a register means; the device manufacturer does. One meter may place energy in two holding registers, another may use a different word order, and a third may require a scaling factor. That is why a Modbus project starts with a register map, not with a cable. The map should state address, data type, scale, unit, access and the behaviour when the device stops answering. A register map that says energy without a unit, scale or word order is not a specification; it is a hope that will be tested at commissioning, usually at the worst possible time.
- Start from the manufacturer's register map
- Record scale, unit and data type for every point
- Define the offline behaviour of each value
RTU and TCP are different links
Modbus RTU runs on RS485 or RS232. RS485 is a shared bus: termination, bias, cable route and unit IDs matter, and one master polls the slaves in turn. Modbus TCP runs over Ethernet and uses a unit identifier inside the TCP frame, often to reach a serial gateway. TCP is easier to route and diagnose, but it is not automatically faster if the gateway behind it is slow. Choose the link by the device, the distance and the existing infrastructure, and document the gateway in between. If the gateway is supplied by the meter vendor, its register mapping and firmware still belong in the point schedule, not only in the vendor's manual.
- RS485 needs termination and a segment plan
- TCP still depends on the gateway behind it
- Document the conversion point
Scaling, signs and word order
Most integration faults are not protocol faults; they are interpretation faults. A value can be signed or unsigned, 16-bit or 32-bit, and split across two registers in either order. A temperature may arrive in tenths of a degree, a pressure in hundredths of a bar, and a status word may pack several alarms into one integer. The register map must define all of this, and the point list should record the conversion. Test with a known value, not with a plausible number on a screen. Record the raw value next to the engineering value during commissioning; it makes future scaling errors obvious and gives the next engineer a reference point.
- Confirm signedness and bit width
- Confirm register pairing and word order
- Test against a known physical value
Polling, writes and failure behaviour
Modbus is polled, so every point has a cost in time and network load. Group reads, avoid polling faster than the device can answer, and treat timeouts as data quality events rather than zero values. Writes need permission, range checks and a read-back. If a controller writes a setpoint, define what happens when the device rejects it or goes offline. Keep safety interlocks out of slow polling loops. Modbus is excellent glue for metering and plant data; it is a poor foundation for sequences that must respond in a deterministic time. A slow protocol can still be reliable; the mistake is asking it to do a fast job, then blaming the protocol when the sequence lags.
- Group reads and respect the polling budget
- Treat timeouts as quality flags, not zero
- Keep safety interlocks out of slow loops
Modbus data areas
6 rows| Area | Access | Typical use | Watch-out |
|---|---|---|---|
| Coils | Read/write | Start/stop commands and status bits | Confirm whether 0 or 1 means on |
| Discrete inputs | Read-only | Running proofs, alarms and limits | Check polarity and debounce |
| Input registers | Read-only | Measured values and counters | Scaling and signedness |
| Holding registers | Read/write | Setpoints, modes and configuration | Write permission and read-back |
| 32-bit values | Read/write | Energy, flow and large counters | Word order and register pairing |
| Device status | Read-only | Communication and fault flags | Distinguish offline from zero |
Project images
3 images
Frequently asked
01RTU or TCP?
RTU suits serial field devices and long cable runs; TCP suits Ethernet networks and gateways. Many sites use both, with a gateway joining the two.
02How many devices can share an RS485 segment?
It depends on the driver, the cable, the baud rate and the polling budget. The segment plan should be calculated, not assumed from a generic number.
03Is Modbus secure?
Not inherently. It has no authentication or encryption. Treat it as a fieldbus and protect it with network segmentation and gateways.
04Why is my value ten times too large?
Scaling. The register may be in tenths or hundredths, or a 32-bit value may be assembled in the wrong word order.
05Can Modbus be wireless?
Yes, through wireless serial bridges or gateways. Confirm latency, retries and the failure state before using it for control.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.