Start with the document, not the driver
This article assumes the protocol decision is already made. If it is not, our BACnet vs Modbus article covers that comparison; what follows is about getting a Modbus device into a Niagara station once Modbus is the route.
Modbus gives you no discovery, no object names and no units. Every point you get, you build by hand from a vendor document, and the quality of that document sets the ceiling on how well the integration goes. Read it before you commit to a point list or a schedule, not after.
Read the register map before you promise a point list
Modbus has four address spaces: coils (readable and writable bits), discrete inputs (read only bits), input registers (read only 16 bit words) and holding registers (readable and writable 16 bit words). Reads use function codes 1 through 4, and writes use 5, 6, 15 and 16.
Addressing is worth settling before anything else. Vendor documentation may use the 4xxxx convention, where 40001 is the first holding register, while the driver wants the zero based data address, so 40001 becomes address 0. If commissioning produces an illegal data address exception, check the addressing convention before you suspect the device.
Before you commit to a point count, get these from the vendor in writing:
- Register type and address for every value, with the convention stated.
- Data type and length: 16 bit, 32 bit spanning two registers, or bit packed.
- Scaling factor, offset and engineering units.
- Valid range, and what the device reports when a value is unavailable.
- Unit ID per device, which still applies behind a Modbus TCP gateway.
- Whether the device accepts the multiple register write, function code 16, or only single register writes, because a 32 bit setpoint written as two separate registers can be read by the device half updated.
Proving a scaled value is actually right
A Modbus register is 16 bits, so anything larger spans consecutive registers, and the order of those words is a vendor decision rather than a standard. Our Modbus platform page sets out the byte and word order options the driver exposes. The commissioning problem is that a correctly configured point and a wrongly configured one look the same on a graphic.
A value that reads as nonsense but tracks the real quantity as it moves points at the conversion rather than the wiring. Word order, byte order, sign handling, data type and scaling can each produce that signature, so work through them before going back to the cable.
Sign matters as much. A temperature of minus 10 read as unsigned appears as 65526, so a point that looks sane in one season and absurd in another is worth checking for sign handling first.
Where a device sends integers scaled by ten or a hundred, the driver conversion carries the multiplier and offset while the facets carry units and precision. Validate against something independent: the device display, a nameplate figure, or a reading you take yourself. Check at two operating points where you can, because a wrong multiplier and a wrong offset look identical when you test only one value.
Poll rates and the transaction budget
Niagara polls on a schedule with fast, normal and slow rates, and every proxy point is assigned to one of them. Putting a point on fast is a decision to spend bus time, and the bus is finite.
Address layout decides how many transactions your point list turns into. The protocol caps a single holding register read at 125 registers and a coil read at 2000, and the driver can only combine points that sit close together, so values scattered across a wide address range become many requests instead of one.
On serial RS-485 the loop is shared. A device that is slow to turn around, or that has stopped answering and burns the full timeout and retry sequence, delays every other device on it. The symptoms look like a driver fault: values that stall, intermittent timeouts, a device that tests fine alone and fails in service.
Timeout and retry values deserve numbers you chose rather than defaults you inherited. A timeout longer than the poll cycle means the cycle overruns whenever one device stops answering, and a high retry count multiplies that cost on every pass.
Writes need their own decision. Work out whether the driver writes only on change, and what the device does with a written setpoint after a power cycle. A device that forgets written values on restart needs a periodic re-assert, or the setpoint quietly reverts.
Failure modes worth designing for
The failure that hurts is the one nobody notices. When comms drop, proxy points go to a fault or stale status, but the last value is still sitting there, and logic that reads value without reading status keeps controlling on a number that stopped being true. Zero deserves particular suspicion: a device returning zero when it is confused looks identical to one reporting a genuine zero.
Four things are worth building in from the start:
- Read status in the logic, not just value, and enable ping monitoring with an alarm on failure and a startup delay so a restart does not produce nuisance alarms.
- Record status alongside value in histories. A flat line that was really a comm outage is indistinguishable from real data once the context around it is gone.
- Read exception responses literally. Illegal function, illegal data address and illegal data value each point somewhere different.
- On serial, confirm baud rate, parity, stop bits and unit IDs before suspecting anything else, terminate the segment at both ends, and ground the shield at one end only.
Documentation that survives the handover
The vendor PDF may not be on the site laptop when the next person needs it. What survives is what you leave in the station and the handover pack:
- A point list mapping each Niagara point to register type, address as entered, data type, word order, scale, offset, units, poll rate, and whether it is writable.
- The device firmware version and register map revision the integration was built against, because a register map can be renumbered between firmware releases.
- What each point does on comm loss, and which points drive control rather than display.
Where polling stops being the answer
Polling has limits worth recognizing before you fight them. Event driven data such as an alarm or event log maps badly onto a poll: either you poll fast enough to spend bus time on records that seldom change, or slowly enough that entries can be overwritten before you read them. Where a device exposes its log through any other route, that route is worth taking instead.
For point count, work the arithmetic rather than guessing. Each transaction on a shared serial segment costs a request, a response and the device turnaround, so the number of transactions you can complete in one poll cycle is the cycle length divided by the measured round trip time on that segment. Measure the round trip against the slowest device on the loop, multiply by the transaction count your point list produces after the driver has grouped contiguous registers, and compare the result with the poll rate you promised. If it does not fit, the options are fewer points, slower rates, contiguous re-mapping where the vendor allows it, or splitting the devices across more ports or gateways so the segments run in parallel.
Modbus is not the problem
None of that makes Modbus a poor choice. It is a stable, well understood protocol with a small surface area, and a device that answers requests today will answer the same requests after a supervisor upgrade. It simply does nothing you did not explicitly configure, which is why the register map, the scaling and the failure behavior are the whole of the job.
Related service: Related service: Modbus device integration, from register mapping through point configuration and commissioning documentation, is within the scope of our Building Automation Integration Services.