Modbus RTU/TCP: How a PLC Reads the Position Value

Note: Germanjet interfaces include analogue, Start-Stop, SSI and CANopen, Profibus, PROFINET and EtherCAT. This page explains how Modbus reads a position value, for comparison; selection still follows the interfaces above.

Reading a displacement sensor over Modbus comes down to one thing: use the "Read Holding Registers" function, concatenate two consecutive 16-bit registers into a 32-bit position count, then multiply by the resolution step to obtain actual displacement. RTU runs on an RS-485 serial link and TCP on Ethernet; the application-layer data model is identical, the difference being only the transport and the addressing. Modbus's strength is that almost every PLC, HMI, gateway and host computer supports it, so implementation cost is very low; its weakness is that it is a master–slave polling protocol, weaker in real-time performance and diagnostics than dedicated fieldbuses. This article covers the read method and three frequent pitfalls; for the overall judgement across interface families see Analog vs. Digital Across the Whole Range.

Data model: how the position value is placed

Modbus registers are all 16-bit, while the position value needs 32 bits, so it necessarily occupies two consecutive registers. The host uses "Read Holding Registers" to read both in one request, then concatenates them into a 32-bit integer in the agreed word order.

What is read back is still a count value, not millimetres: actual displacement = count value × resolution step, with the step chosen from 1 / 2 / 5 / 10 / 20 / 50 / 100 μm. A wrong scale factor makes the reading look as if "the measuring range was specified wrongly" — a common complaint of every digital interface, unrelated to the protocol. For the difference between resolution and accuracy figures see The Three Accuracy Terms of Magnetostrictive Sensors: Resolution, Repeatability and Non-Linearity. The position value is absolute, so power-loss restart needs no homing; see Absolute vs. Incremental Position.

Three frequent pitfalls

Pitfall one: word order. When 32-bit data is split across two registers, whether "high 16 bits first" or "low 16 bits first" is not uniformly agreed, and vendors differ. Reverse the word order and the reading will show large, seemingly random jumps — while the communication status is entirely healthy, which is easily misdiagnosed as interference. Verification is simple: park the magnet at mid-stroke, move it slowly a short distance, and watch whether the reading changes continuously and monotonically. If the jumps have no pattern, swap the concatenation order of the two registers and look again.

Pitfall two: signed versus unsigned. The position value is a signed 32-bit integer. If the host interprets it as unsigned, negative values (below zero or reverse counting) display as a huge number. A reading "near 4.3 billion" on the HMI is almost certainly a sign interpretation error.

Pitfall three: polling cycle. Modbus is active polling: the slave does not answer unless the master asks. The polling cycle must not be shorter than the sensor's own update rate — magnetostriction has to wait for the torsional wave to travel from the magnet back to the electronics head, so the longer the measuring range the longer it takes (of the order of 0.5 ms on shorter ranges, and several milliseconds on very long ranges); nor should the polling cycle be shorter than the minimum transaction time the link can carry, which is especially visible on RTU at low baud rates. An overly tight cycle shows up as a rising timeout rate and more repeated values. For how to match them see Matching Response Time and Refresh Rate to the Control Cycle.

RTU versus TCP

The physical-layer requirements on the RTU side share the same origin as CAN and Profibus: linear topology, one 120 Ω terminating resistor at each end of the segment, none in the middle, and slave addresses unique within the segment. For the principle of impedance matching see Terminating Resistors and Bus Length: Why It Has to Be 120 Ω; for a systematic approach to earthing and shielding see Troubleshooting Fieldbus Interference: Grounding, Shielding, Topology.

When Modbus should be used, and when it should not

Suitable cases: the controller is not a master of any dedicated fieldbus, but supports Modbus; there are only one or a few axes and cycle demand is modest; position data needs to be sent to an HMI, SCADA or data-acquisition gateway; a retrofit already has an RS-485 link that can be reused.

Unsuitable cases: multi-axis synchronous control (Modbus has no synchronous-sampling mechanism, so the read instants of the stations are naturally staggered); high-speed closed loops that require a deterministic millisecond-scale cycle; applications that need the device to report faults of its own accord (a Modbus slave cannot initiate communication; diagnostics can only be polled from status registers by the host). These applications should use a dedicated fieldbus; for the trade-off see Comparing the Whole Fieldbus Range. For multi-axis synchronisation mechanisms, refer to the SYNC mechanism of the 194 CANopen series and the distributed clocks of the 197 EtherCAT series.

A reminder: whether a given type offers a Modbus RTU / TCP interface should be confirmed with technical support at the selection stage; do not assume that every digital type supports it. For the matching path of master systems to protocols see Selection Guide: Which Fieldbus Does My PLC Support?; for other frequent questions see FAQ Round-Up: 20 Common Questions About Magnetostrictive Displacement Sensors, Answered.