Modbus

Modbus in Niagara looks simple on paper – registers in, values out. In practice the work is in the register maps: undocumented scaling, packed bits, byte-order surprises, and meters that answer slowly enough to stall a poll cycle. Software Pile integrates Modbus TCP and RTU devices into Niagara stations so the data is right, not just present.

What We Handle

  • Register mapping from vendor documentation – or reverse-engineering when the documentation is wrong or missing
  • Data-type handling: signed/unsigned, 32-bit floats across register pairs, byte and word order, bitfields
  • Poll-cycle design for mixed-speed devices on shared RTU trunks, so one slow meter does not starve the rest
  • Gateway topologies: serial devices behind TCP gateways, addressing and timeout behavior included
  • Histories, alarms, and totalization on Modbus points that arrive as raw counts

Energy Metering, Done Right

Most of our Modbus work is meters: power, gas, water, BTU. We validate scaling against the meter face before histories start recording, because a wrong multiplier discovered six months later poisons every report built on it.

Getting Started

Send the device list and register maps you have – plus your Niagara version and whether devices are TCP or RTU behind gateways. If the documentation is missing, say so; that changes the approach, not the feasibility.

On RTU, Half the Trouble Is Physical

Before suspecting the register map, look at the wire. RS-485 is a daisy chain, and trunks wired as a star develop reflections that produce errors nobody can reproduce on demand. Termination missing at the ends, bias resistors omitted, shields grounded at both ends, and a trunk extended twice by different contractors all present as the same symptom: intermittent timeouts that get worse toward the far end.

Serial settings cause their share too. A device with the wrong parity or stop bit configuration will sit on the trunk producing errors that look like a mapping fault. Confirming baud, parity and framing on every device is dull work that clears problems no amount of register analysis will touch.

Timeouts, Retries and the One Slow Device

Modbus RTU is strictly sequential. Every device waits while the master talks to the one before it, so a single meter that responds slowly, or worse fails to respond and forces the master to wait out the timeout and retry, delays everything else on that trunk.

The remedies are practical: tune timeout and retry values per device instead of applying one global setting, poll slow devices less often than fast ones, move a persistent offender onto its own port or its own gateway, and split an overloaded trunk. Getting this right is what separates a station where values update predictably from one where operators learn to distrust the screen.

Reading a Register Map That Turns Out to Be Wrong

Vendor documentation goes out of date, gets written against a different firmware revision, and is sometimes plainly incorrect. There is a workable method for deducing the map anyway, with a known limit: it will not recover registers holding values the device never displays, and it struggles with values that are encoded instead of simply scaled.

Start from the device display and find registers holding values you can see. Vary a known input and watch which registers move. Look for the same value appearing at different scalings in nearby registers, which reveals the multiplier. Test both interpretations of the addressing offset, since documentation written for one convention read by software using another produces an off-by-one that shifts every point. Check the word order on any value spanning a register pair by comparing both interpretations against the display.

Writing to Modbus Devices

Writes need more care than reads. Some devices accept a write to a register and silently ignore it. Some hold configuration registers that were never intended for runtime changes and behave badly when written. Some accept a value outside their working range and act on it.

So writes get confirmed by reading back, the writable register list is kept deliberately short, and range limits are enforced on the station side before the write is issued. There is also a prior question: whether the device should be under station control at all. A meter is there to be read, and giving it a control path creates risk for no operational benefit.

When Modbus Is the Wrong Choice

If a piece of equipment offers both Modbus and BACnet/IP, BACnet usually carries more of what an integration needs: object names, units, alarm state, change-of-value reporting and a priority mechanism for writes. Modbus delivers numbers with no context, and every piece of that context becomes something you configure and document by hand.

Modbus remains the right answer when it is what the device speaks, which is a common situation with meters and packaged plant. Where both are available on the same equipment, the comparison above is the whole of it, and it is worth a few minutes before the point list is written. Where devices of both kinds end up in one station, Building Automation Integration Services covers keeping them coherent.

Four Tables, Not One Address Space

Modbus defines four separate address spaces, and the function code decides which one a request touches. Coils are single writable bits, read with 01 and written with 05 or 15. Discrete inputs are read-only bits, read with 02. Input registers are read-only 16 bit words, read with 04. Holding registers are 16 bit words that can be read and written, using 03, 06 and 16. Address 12 exists in all four and holds four unrelated values. A point list that gives only a number is incomplete until someone names the table, and reading it against the wrong one returns numbers that look reasonable and are not the quantity you asked for.

A single request also has a ceiling. A read of holding or input registers returns at most 125 registers, a coil read at most 2000 bits, and a write of multiple registers at most 123, because the protocol data unit is capped at 253 bytes. Drivers split a longer point list into several requests on their own, but plenty of devices enforce a lower limit than the standard allows, and some accept an oversized request and answer with garbage rather than refusing it. When a block read fails and the same points read individually succeed, the block size is the first thing to cut.

A device that refuses a request has two ways to say so. It can answer with an exception response, which is the original function code with the high bit set plus a one byte code, or it can stay silent and let the master time out. Those are different fault classes. An exception means the device received the frame, parsed it and rejected it, so the wiring, the serial parameters and the address are all correct and the fault is inside the request. Silence means the frame never arrived, or the device never recognized it as addressed to itself. The codes worth recognizing on sight are few:

  • 01, illegal function. The device does not implement that function code at all, which is common on inexpensive devices that support 03 and nothing else. A point list written against input registers then fails on every point, and changing addresses will not help; the function code has to change.
  • 02, illegal data address. The function is supported, but the address, or the address plus the quantity requested, falls outside the range the device implements. A block read that starts inside a valid range and runs past its end fails as a whole rather than returning the part that exists.
  • 03, illegal data value. The quantity in the request is out of range for that function, most often a read longer than the per-request limit. It refers to the request, not to the contents of the register.
  • 04, server device failure. The device hit an unrecoverable error handling a request it otherwise understood. This often means the point exists but the underlying measurement did not.
  • 05 and 06, acknowledge and busy. The device took the request and cannot answer yet. Treat these as retry rather than failure, or a slow write will look broken.

Modbus TCP, Gateways and the Unit Identifier

Modbus TCP keeps the application layer intact. The same function codes address the same four tables, so a point list moves between transports unchanged. What changes is the framing: a seven byte MBAP header replaces the serial framing, the CRC is dropped because TCP already covers integrity, and the default port is 502. That header also carries a transaction identifier, which in principle lets a master keep several requests outstanding at once. In practice many devices and most gateways serialize internally, and small embedded devices accept only one or two simultaneous TCP connections. A laptop running a scanning tool against a meter that permits one connection can push the station's connection off, which presents at the station as a device that failed the moment an engineer arrived on site.

The unit identifier is where the two topologies diverge. On a device with its own Ethernet interface it is usually ignored, or it has to be 1 or 255 before the device will answer at all. Behind a gateway it is the serial slave address, and it is the field that actually selects the device. One IP address with thirty unit identifiers behind it is thirty devices sharing a single RS-485 trunk. The transport in front of them is parallel; the trunk is not, and it keeps every constraint it had before the gateway was added.

That split is what makes a failing gateway readable. If the same IP answers for unit 10 and times out for unit 11, the IP layer is fine and the subject is the trunk or that one device. If the whole IP goes quiet, the gateway or the network is the subject. Timeouts stack in the same direction. The gateway holds its own serial timeout and retry count, and the station holds a TCP timeout on top of it. Set the station timeout shorter than the gateway's serial timeout multiplied by its retries and the station abandons requests the gateway is still working on, which produces failures that clear as soon as the gateway is given less to do.

Counters, Rollover and Reads That Tear

A 32 bit counter living in two 16 bit registers can be read at the exact moment the device carries from the low word into the high word. Nothing in the protocol requires a device to present a consistent snapshot across a multi register read, so the master can assemble a value the counter never held: a new low word beside an old high word, or the reverse. The sample lands tens of thousands of counts away from its neighbors. Because the error can only occur at the carry, a fast meter produces one every few days and a slow one may never produce any, and it shows up as a single impossible spike in a history that is otherwise clean. Some meters offer a snapshot or freeze mechanism that removes the exposure; where none exists, a delta limit on the history side catches it.

Counters are 16, 32 or 64 bits wide and they wrap. Some meters wrap at a decimal boundary such as 999999 rather than a binary one, which defeats a totalizer that assumes 2^32 and yields a negative or absurd delta at every wrap. Rollover handling and a rule for what a decrease means, whether a wrap, a device reset or a bad read, are configuration decisions the totalizer needs from its first reading. The physical maximum of the equipment gives the cheapest guard: a meter on a 200 amp service cannot pass a megawatt hour in a minute, and a sample claiming it did is a read fault rather than data.

The timestamp on a totalized value is the station's, not the device's. Modbus carries no time, so the interval attached to a delta is the gap between two polls, and that gap moves with retries, trunk load and station restarts. Consumption totals absorb this because the error cancels across intervals. Demand and rate figures do not, because the interval is the denominator, and a poll that landed forty seconds late inflates the demand computed for that window. Two things have to be settled before histories start, because neither can be reconstructed from the recorded data afterward:

  • Whether the register is an accumulator that only rises, or an instantaneous value sampled at the moment of the read. Running a totalizer against an instantaneous register produces a curve that looks like data and means nothing.
  • Which counter the reports are built on, where a meter exposes more than one. Many carry a resettable counter alongside a non resettable one, and a technician clearing the display months later moves the reports only if they were built on the resettable one.

Serving Modbus From the Station

The roles invert when a third party wants data out of the station rather than the station wanting data from a device. A SCADA system, a tenant billing platform or a packaged plant controller polls the station, the station answers, and the consumer decides the poll rate and how many clients connect. Register numbers stop being something you discover and become an interface you publish. Once someone has built against register 40021, moving it does not fail loudly: the consumer reads whatever now sits there and gets a number back. So a published map gets frozen and additions go on the end, even when the layout would be tidier rebuilt.

Serving quickly does not make data fresh. A served point is only as current as the station's own poll of the source device, so a value can be offered every second and change every fifteen minutes. A consumer polling hard against a slow source adds load to the station and learns nothing extra, and the fix is a conversation about the source update rate rather than a change on the serving side.

Modbus also has no concept of point quality. A register holds sixteen bits and all of them are a legitimate value, so a point whose source device went offline an hour ago still reads as a number and the master has no way to tell a stale value from a live one. The convention is to publish alongside the data: a heartbeat register that increments every cycle, so a consumer can detect a frozen station, and a status register whose bits report the health of the source devices behind the served points. Both are agreements between two parties, so they belong in the same document as the point list, which has to state what the wire cannot carry:

  • Scaling and word order for every value, decided once and written into the document, because the consumer has no display to check them against and no way to derive them.
  • Which of the four tables each point lives in, and which addressing convention the document is written in, said in words rather than implied by how the numbers are formatted.
  • The engineering unit and the expected range for each point. The consumer receives an integer with nothing attached to it and will otherwise guess.
  • Whether any register is writable and what a write is expected to do. A consumer that finds holding registers will eventually try one, and silence on this point gets resolved by experiment.

Frequently Asked Questions

Our gateway is set to something called RTU over TCP. Is that Modbus TCP?

No. They are different encapsulations, and a client set for one cannot talk to a server set for the other. RTU over TCP wraps complete serial frames, CRC included, inside a TCP stream, while Modbus TCP replaces that framing with its own header. Gateways and terminal servers usually offer both and often on the same port, so the port number does not tell you which mode a device is in. If every response fails its check, or the driver reports framing errors on a link that is otherwise healthy, the mode is the thing to look at first.

What has to already exist before Modbus integration can start?

A Niagara station on a host that can reach the devices, with the correct driver licensed on that host. The serial and TCP Modbus drivers are separate licensed features in Niagara, so a controller licensed for one is not automatically licensed for the other. On the device side, each device needs power, a unique slave address on its trunk, and either an RS-485 path back to a controller port or a gateway. For TCP devices the station host needs a route to the device subnet with port 502 open outbound, which on a segmented network is a firewall or VLAN change owned by someone else.

Can the station be added as a second master on a trunk another system already reads?

Not on RS-485. Modbus serial allows exactly one master per trunk, and two masters transmitting on the same pair collide, which appears on both systems as timeouts that come and go with no pattern. The options are to take the data from the existing system instead, to use a second serial port on the device where one exists, or to replace the existing master and serve it what it needs. Modbus TCP permits multiple masters at the protocol level, but a device that accepts one connection still refuses the second, so the question of what already polls this equipment belongs at the start of the job, not at commissioning.

How many devices can one RS-485 trunk carry?

The addressing allows 247 slave addresses, standard transceivers allow 32 unit loads on a segment before a repeater is needed, and low load transceivers raise that into the hundreds. None of those is usually the binding limit. The poll cycle is: at 9600 baud a request and its response occupy on the order of tens of milliseconds, so twenty devices with several block reads each, plus the occasional retry, can stretch a cycle past what the graphics and the histories expect. Count transactions and multiply before counting devices.

Beyond the device list and register maps, what do you need from us?

For serial devices, the parameters actually set on each device rather than the ones in the specification: slave address, baud, parity and stop bits, plus which physical trunk each device sits on and where that trunk physically ends. For TCP devices, IP addresses and unit identifiers, and the name of whoever controls the firewall or VLAN between the station host and the device subnet. We also need a way to see something known, such as a meter display, a nameplate rating, or a load that can be switched. Last, a decision on which points matter, because a meter can expose several hundred registers when a dozen of them belong in histories.

How does the work proceed once that information is in hand?

One device is brought up end to end before anything is replicated, comms through to points that read correctly, because an error copied across forty identical meters costs forty times as much to undo. The pattern that results is then applied to the rest of the identical models, which is where the volume sits on a metering job. Timing is tuned after the trunk is fully loaded rather than during the first device, since a device that answers reliably on its own can start missing under a full cycle. Histories and alarms come last, once the trunk holds a cycle without timeouts, because an alarm on a point that still drops out teaches operators to ignore it.

Is Modbus secure?

No, and it was never designed to be. There is no authentication, no encryption and no concept of a user, so any host that can reach port 502, or touch the RS-485 pair, can read every register and write every one that accepts a write. Protection comes from network placement: devices on their own VLAN or a physically separate network, no route from general office traffic, and nothing exposed to the internet. A TLS variant exists in the specification on its own port, but device support for it is thin enough that it is not a plan. Where the station is the side serving Modbus, keep the served map read-only unless a write has a stated purpose, because that half of the interface is yours to define.