Modbus RTU and RS-485

Part 21 of 23 in Cobler's Electricity Fundamentals course. New here? Start with the course map.

In Part 20 we turned a CO2 level into a 12-bit number, but that number is sitting inside one controller. The building management system (BMS) server, the analytics and thirty power meters like the one in Part 19 all live somewhere else, and one 4-20 mA pair per number won't scale. So the number has to travel. Let's take a look at one way it does that, called Modbus RTU.

Imagine a gateway in a chiller plant's switch room, with thirty power meters on one pair of wires. It asks each meter in turn, waits for the answer and moves on, sending bits as voltage pulses at 9,600 bits per second. Collecting a full set of readings from every meter on its chain takes it about four seconds (illustrative). The rules of that conversation are Modbus RTU, and the wire it runs on is called RS-485. In this part we'll build both, from the voltage on the wire to the number in the register.

Serial transmission

So how do bits actually travel down a wire? Well, we switch a voltage between two levels in a timed sequence, one bit after another, and that's what we call serial transmission.

The voltage is the push from Part 2, and the switching is Part 4's switch, now flipped by a transistor thousands of times a second. The sender and the receiver agree on a speed, called the baud rate. At 9,600 baud each bit lasts 1/9,600 of a second, about 104 microseconds. The receiver samples the line in the middle of each bit and reads a 0 or a 1.

Modbus RTU sends each byte (8 bits of data) as 11 bits. There's a start bit that says "a byte begins", then the 8 data bits, then a parity bit that helps catch a flipped bit (or a second stop bit), and then a stop bit. So one byte takes:

$$t_{byte} = \frac{11 \ \text{bits}}{9600 \ \text{bits/s}} \approx 1.15 \ \text{ms}$$

That's about 870 bytes a second. To give you a feel for it, this whole article as plain text would take about 12 seconds to send. So hold on to that 1.15 ms, because it ends up deciding how fast a building can read its meters.

RS-485 and the twisted pair

Now, a single wire measured against 0 V is easy to fool. Run it 300 m past motor starters and drives, and their changing magnetic fields induce stray voltages in it. That's Part 7's induction, working against us this time. So RS-485, a wiring standard now published by TIA (originally EIA-485), sends every bit on two wires, A and B, driven in opposite directions. For one bit value the driver might put A at 3 V and B at 1 V, which is a difference of +2 V. For the other, it swaps them, so −2 V.

Now let's say a motor starts nearby and induces 4 V of noise. The two wires are twisted together, so both of them pick up the same 4 V:

$$(3 + 4) - (1 + 4) = 2 \ \text{V}$$

And you can see the difference hasn't moved. It's kind of like two people in a lift. Ride up twenty floors and both of them rise equally, but the gap between their heights stays the same. The receiver only reads the difference between the two wires, and it needs only about 0.2 V of difference to decide, so it still reads the right bit. The noise lands on both wires equally, so it cancels, and that's the reason RS-485 uses a twisted pair.

There are three wiring rules that come straight out of this physics:

• Daisy chain. The pair runs from device to device in one line, rather than as a star. Branches send part of each signal down a dead end and back.
• Terminate both ends. A fast edge travelling down a long pair bounces back from an open end, kind of like an echo. A resistor of about 120 ohms at each end, matching the cable, absorbs it.
• Count the loads. The standard allows 32 "unit loads" on one segment, over cable runs up to about 1,200 m at building speeds (TI's RS-485 design guide). Many modern devices use transceivers rated at a quarter or an eighth of a unit load, so a segment can actually hold more.

So now thirty meters share one pair, and if two of them drive it at once, both messages are lost. How do we go from a shared wire to an orderly conversation? Well, what if only one device is allowed to start talking, and the rest wait to be asked?

Modbus RTU

That's basically the idea behind Modbus. Modicon published it in 1979 for its programmable logic controllers (PLCs), and it's now an open standard kept by the Modbus Organization. RTU, short for remote terminal unit, is its compact binary form for serial lines.

The way it works is that one master, like a gateway or a BMS controller, polls slaves at addresses 1 to 247. (The current specification calls them client and server.) A slave never speaks unless it's asked, so two devices never talk over each other on the shared pair. It's a lot like a roll call, where the teacher calls one name and only that student answers. Every request is one frame, with an address, a function code, the data and an error check, and a silence of 3.5 byte-times marks the end of each frame.

At this point you might be wondering why a meter doesn't just speak up when its reading changes. Well, then two could start at once, and every device would need a way to notice a collision and retry. Polling avoids that, at a cost in speed that we'll time below. And when meter 7 stops answering, the gateway knows exactly who has gone quiet.

Requests and replies

Let's work through one. The gateway wants meter 7's total kW, and the meter's manual says it sits in two registers starting at register 0x0034, which is 52 in ordinary numbers (an illustrative register map). The request is eight bytes, each written as two hexadecimal (base 16) characters:

`07 03 00 34 00 02 85 A3`

• `07` is the address. Meter 7 listens, and the other 29 ignore the frame.
• `03` is the function code, "read holding registers".
• `00 34` is the first register to read.
• `00 02` is how many registers, so two.
• `85 A3` is the cyclic redundancy check (CRC), a 16-bit number the gateway calculates from the first six bytes.

Meter 7 runs the same CRC calculation on what it received. If noise flipped even one bit on the way, the two numbers won't match, so the meter stays silent, and the gateway times out and asks again. If they do match, the meter answers:

`07 03 04 43 CE 40 00 D9 88`

So that's address 7, function 3, "4 bytes follow", the four data bytes `43 CE 40 00`, and then the reply's own CRC. Those four bytes are the kW. The whole exchange takes 17 bytes, which is about 20 ms of wire time at 9,600 baud.

Registers

So what's actually inside a register? A register holds 16 bits, which is a whole number from 0 to 65,535. Most real readings don't fit that, so meters either combine registers or scale them.

Say we have a kWh total of 1,234,567. That's too big for one register, so the meter splits it into two 16-bit halves, a high one and a low one:

$$\text{value} = \text{high} \times 65{,}536 + \text{low} = 18 \times 65{,}536 + 54{,}919 = 1{,}234{,}567$$

Readings with decimals use one of two tricks. Some meters store a scaled whole number, so 4,125 in one register, with the manual saying "divide by 10", means 412.5 kW. Others store a 32-bit floating-point number (the IEEE 754 format) across two registers. That's what meter 7 sent us, and `43 CE 40 00` decodes to exactly 412.5 kW.

Now there's one classic integration fault to know about. Vendors disagree on which of the two registers comes first. If the gateway puts meter 7's registers in the wrong order, it decodes `40 00 43 CE` and shows about 2.0 kW, and nothing raises an error. The number is just wrong, and it stays wrong until someone compares it with the meter's own display. So every good Modbus integration starts with the register map and ends with that check.

Modbus TCP, BACnet and gateways

Now let's send the same request over Ethernet instead. The function code and the data stay the same. The address moves into a short header (as the "unit identifier"), the CRC is dropped because Ethernet checks its own frames, and the conversation uses TCP port 502. So it's the same request, carried inside the Transmission Control Protocol (TCP) that most networks use, and that's what we call Modbus TCP. A gateway sits between the two worlds. It takes a Modbus TCP request from the network and uses the unit identifier to pick which address to ask on its RS-485 side.

BACnet, the building automation protocol from ASHRAE, takes a different approach. Devices describe themselves as named objects, like an analog input with its units, instead of bare numbered registers. BACnet vs Modbus compares the two. Real buildings run both, plus the odd proprietary bus, and integrating mixed-vendor systems is the job of mapping them all into one model.

Thirty meters on one chain

So let's picture the chiller plant switch room of a Klang Valley office tower (illustrative). Thirty multifunction meters, each fed by current transformers (CTs) as in Part 19, sit on the main switchboard and the motor control centre, for the chillers, chilled-water pumps, condenser water pumps and cooling tower fans. One shielded twisted pair runs from the gateway to meter 1 and on to meter 30 in a single chain, with a 120-ohm terminator at the gateway and another at meter 30. That's thirty-one devices, which is inside the 32-unit-load limit even before we count fractional loads.

Every cycle, the gateway asks each meter for one block of 40 registers. On these meters (illustrative), each register holds one scaled reading, like the kW × 10 above, so that's kW, kVA, power factor, the three phase currents and voltages, and more. Let's add up the time at 9,600 baud:

• Request: 8 bytes × 1.15 ms ≈ 9 ms
• Reply: 85 bytes (5 bytes of frame plus 80 of data) × 1.15 ms ≈ 97 ms
• Silences between frames plus the meter's thinking time: about 30 ms (illustrative)

That comes to about 140 ms per meter, so thirty meters take about 4.2 seconds. At 19,200 baud the wire time halves. So this is why plant meters refresh every few seconds rather than every millisecond. And honestly, for energy work that's fine. Maximum demand is a 30-minute average (Part 5), so a reading a few seconds old is still fresh.

The gateway, which could be a BMS controller or a CobiNeural gateway, then forwards the readings over Ethernet, or over a LoRaWAN radio link where cabling is hard. When a chain misbehaves, the cause is usually on a short list: a missing terminator, a branch off the chain, A and B swapped at one meter, two meters set to the same address, or the register word order.

Too many readings

So the chain works. Every 4.2 seconds, thirty meters send 40 values each, which is about 17,000 readings a minute from the plant meters alone. Add the BMS's temperatures, valve positions and CO2 sensors, and one tower produces tens of thousands of readings a minute. No person can watch all of that. So how do we find the few that matter? Well, the building needs software that watches for us and tells us what's wrong, and that's Part 22: fault detection and diagnostics.

This is Part 21 of 23 in Cobler's Electricity Fundamentals course. Previous: Sensors and 4-20 mA Signals. Next: Fault Detection and Diagnostics.

Cobler builds CobiNeural, which reads meters and controllers over Modbus and BACnet, standalone or as an overlay on an existing BMS. To see what your building's meters are already saying, request a demo.