Modbus RTU is the same register logic as Modbus TCP, the same holding registers, the same idea of a device answering reads over a table of numbered addresses, just carried over a wire instead of Ethernet. It shows up on older VFDs, power meters, and PLCs that never got an Ethernet port, and on newer ones where RS-485 was cheaper to add. If you’ve read the Modbus TCP guide, most of the register logic there carries straight over. What’s different here is entirely in the wire and the wire-level settings, and that’s what this guide covers.
Before you start You’ll need the device’s Modbus register map, its unit ID (also called slave ID), a twisted pair for the RS-485 A/B lines, and its baud rate, parity, and stop bits from the device’s own manual. Spall’s gateway has two onboard RS-485 ports on its screw terminal panel. Spall reads only. It never writes to the device.
1. Wire the RS-485 bus
RS-485 is a two-wire differential bus, labeled A and B (sometimes D+/D- or +/-), that can carry several devices on the same pair, daisy-chained from one to the next. Each device does not get its own home run back to the gateway. Wire the gateway’s A to every device’s A, B to every device’s B, straight through the chain, and land a common ground if your devices and the gateway don’t already share one through their power supplies. Polarity matters. A swapped A/B pair is the single most common reason a freshly wired RTU device answers nothing at all, worth checking first if the connection test in step 4 comes back silent.
The gateway’s carrier board breaks out two independent RS-485 channels on its panel, so two separate buses (or one bus and a spare) are available without adding a converter. Power the gateway off while landing these terminals, same as any other panel wiring.
2. Unit IDs, one per device on the bus
Because several devices can share one physical pair, each one needs its own unit ID (also called slave ID) so a request addressed to unit 3 doesn’t get answered by unit 1. Unit IDs run 1 through 247, set on the device itself, usually a set of DIP switches, a front-panel menu, or a configuration tool. Check the device’s manual for exactly where. Two devices sharing a unit ID on the same bus is a real, common wiring mistake. Both devices try to answer the same request, so it looks like intermittent garbage or timeouts, not a clean failure.
3. Confirm the settings match
Beyond the unit ID, RS-485 requires the whole bus to agree on baud rate, parity, and stop bits. Get any of the three wrong and the device won’t answer at all. These live in the device’s own manual or configuration menu. Common values are 9600 baud, no parity, 1 stop bit, but plenty of devices ship at 19200 or 38400, or with even parity. Write down exactly what the device is set to before touching Spall’s side.
4. Add the source in Spall
In Spall, add the machine, choose Modbus RTU as the source, and set the serial device, the gateway’s two RS-485 ports are its own labeled entries in that field (its help text names the exact device path for the port you wired). Set baud rate, parity, stop bits, and data bits to match the device from step 3, and set the unit ID from step 2.
5. Byte order and word order, set independently per source
This is the setting to understand before your first tag comes back wrong. A single Modbus register is 16 bits, two bytes, and a value wider than that, a float or a 32-bit integer, spans two consecutive registers. Two separate things can vary by device, and Spall lets you set both, independently, per source:
- Byte order is which of the two bytes inside one register comes first, most devices are big-endian (the standard the Modbus wire format assumes), some byte-swap their own registers.
- Word order is which of the two registers comes first for a multi-register value, big (the first register holds the high-order half) is the default, little (word-swapped, sometimes called CDAB) is common on VFDs and several PLC families.
Both default to the common case and rarely need to change. Set them only when your device’s manual calls one out explicitly, or when a value looks like a plausible wrong number instead of an outright error.
6. What a wrong order looks like
A wrong byte or word order rarely looks like an error. The read succeeds, a number comes back, and it’s very often the wrong order that produces the tell: a value off by a large, suspiciously round factor (roughly 65536 times too big or too small is the word-order symptom), or a number that looks scrambled but is still technically finite, digits from the right value in the wrong place, instead of something obviously broken. A pressure sensor reading 3355545.6 PSI instead of 51.2 isn’t a sensor problem, and a temperature that flips between two unrelated-looking values every time you refresh isn’t jitter. Both are the shape a word-order or byte-order mismatch takes. If a value looks like that, that’s the first setting to check, before assuming the scale or the register address is wrong.
7. Add a tag per register
For every point you want, add a tag with the wire address, subtract one from a traditional 40001-style manual address the same as Modbus TCP, and a data type: 16-bit int for a single register, float or 32-bit int for a value spanning two, 64-bit int or double for a counter spanning four. Scale and offset turn a raw integer into real engineering units without touching the device. Assign the gateway and save. Every new tag lands in the Signal inbox unclassified until someone confirms what it means, exactly as it does for every other protocol in this series.
What Spall does with this data
Availability. A tag classified as a run/stop signal splits every hour into running, idle, and down.
Downtime and reasons. Each stop is caught the instant the mapped signal changes, ranked into a Pareto once operators tag the reason.
Production. A tag classified as a part counter drives target-vs-actual by shift and job.
Quality and OEE. Availability, performance, and quality still roll into one OEE view, dollar-ranked, whatever protocol the tag came in over.
One thing worth repeating Spall issues Modbus read requests only, function code 3, holding registers, the same as it does over TCP. It never writes a register back to the device. Worst case if a device stops answering on the bus is a gap in the chart for that one tag. The rest of the bus keeps answering normally.
Quick recap
- RS-485 daisy-chains on one A/B pair, wire A to A and B to B straight through, swapped polarity is the most common reason for total silence
- Every device on the bus needs its own unit ID (1-247), a shared ID looks like intermittent garbage, not a clean failure
- Baud rate, parity, and stop bits must match the device exactly. A mismatch means no answer at all
- Byte order and word order are two independent settings, both defaulting to the common case. Change only the one your device calls out
- A wrong order looks like a plausible wrong number, a huge or tiny value, or one that scrambles between refreshes, not an obvious error
- Every new tag lands in the Signal inbox unclassified until someone tells Spall what it means
If a device’s manual doesn’t say its byte or word order plainly, bring the model number to a pilot call. Most of the common ones are already known.