Modbus RTU and Modbus TCP use the same basic data model over different transport environments. RTU commonly runs over a serial link, while TCP runs over an IP network. The decision is not simply which is faster: device support, wiring, topology, network management and failure behaviour all matter.
Meaning comes from the device map
Modbus defines areas such as coils, discrete inputs, input registers and holding registers. Whether a particular register represents temperature, a counter or a status word is determined by the manufacturer. The protocol specification does not supply every device’s engineering meaning. Obtain the map for the actual model and firmware.
A physical value may span several registers. Verify signedness, scaling and word order. Documentation numbering can differ from the offset expected by a client library. A stable but incorrect measurement may result from this mapping rather than a damaged sensor.
Compare transport responsibilities
| Topic | Modbus RTU | Modbus TCP |
|---|---|---|
| Medium | Serial communication | TCP/IP network |
| Configuration | Baud, parity and line properties | Addressing, connections and network access |
| Diagnosis | Physical link and serial timing | Reachability and TCP session |
| Shared constraint | Line capacity and device response | Device connection limits and network load |
This table is not a hardware-selection guarantee. Physical matters such as termination, cable routing, isolation and grounding need competent field assessment. Using TCP does not require directly exposing an industrial device to the internet.
Plan polling and failure handling
Reading every register as frequently as possible is not a good default. Consider how quickly each signal changes and the load permitted by the device. Group appropriate reads, and measure how timeouts and retries affect the overall cycle. One slow device should not hold the rest of the collection flow indefinitely.
A failed read must not become a valid zero. If the last value remains visible, label it as stale. Sensor errors and communication failures may need different quality codes. Bound retry count and waiting time, and keep enough operational information to diagnose which stage failed.
Illustrative energy meter
Assume an existing serial meter exposes cumulative energy. A gateway reads it using the manufacturer map, adds the correct unit and equipment identity, and forwards the record. Another meter may expose the same quantity over TCP. Their field connections differ while the application can use the same normalised energy-record format.
Test resets, rollover, device replacement and missing reads for both. A negative difference between cumulative readings should trigger evaluation of these conditions, not silently become negative consumption. This is an application data-quality responsibility independent of the transport protocol.
Keep the access scope explicit
Classic Modbus access alone does not provide a complete user-identity, authorisation or network-security policy. Segmentation, approved collectors and limiting operations remain separate design tasks. The existence of additional approaches such as Modbus Security does not mean an installed device supports them.
Prefer a clearly defined read-only scope for the first integration. Writing values can affect control logic and physical processes, so it requires separate approval and testing. The discovery output should bring together the register map, units, polling schedule, timeout behaviour and access boundaries. That combination is more useful than selecting RTU or TCP on its own.
Build a small register verification sheet
For each required quantity, keep the document reference, register area, address convention, count of registers, data representation, scaling and expected unit together. Include the device model and firmware version. A value read successfully from an address is not evidence that the correct quantity was selected. Record a known operating condition alongside the raw response and converted value so a second person can reproduce the interpretation.
An illustrative register value of 253 could represent 25.3 degrees only when the manufacturer specifies that scale and unit. Another register may contain a fault code or a reserved value. Applying a temperature conversion before checking validity would create a plausible number from an invalid measurement. Fault interpretation belongs in the mapping procedure, with the resulting quality state carried into storage and the user interface.
Multi-register quantities deserve particular attention. Check the supported read operation and the device’s documentation for consistency across an update. A counter changing during an unsuitable read sequence may yield a value that never existed as a coherent observation. The remedy depends on the equipment: do not invent a universal atomic-read guarantee. Preserve the original map and test evidence when a firmware update changes the available representation.
Compare a failed device with a failed network
Prepare one commissioning test where a device stops answering and another where its response contains a defined exception or measurement fault. The collector should distinguish lack of communication from a response reporting a problem. Both differ from a valid value of zero. Verify the labels at the dashboard, not just the collector log, because users make decisions from the final presentation.
Measure the effect of one slow participant on the complete polling schedule. Bounded waits and retry budgets should prevent a failing device from indefinitely delaying unrelated readings. The appropriate limits depend on the device and topology; they cannot be selected from a generic internet example. In the handover document, include the approved operations, the observed collection cycle under normal and degraded conditions, and the process for changing the map. Bring existing device documentation and a short list of required quantities to the first PLC or meter integration discussion. Those inputs allow the transport choice to follow the real installation.