Nothing in a Modbus response tells you whether a register holds a temperature in tenths of a degree or a packed status word — that meaning lives only in the vendor's documentation.

True. Modbus is dumb on purpose. A register is just sixteen bits; the protocol carries no units, scale, or name. The device's manual is the contract — lose it and you have data without meaning. (This is the exact opposite of BACnet, where the object describes itself.)

A sequence needs to catch a status bit on a Modbus server the moment it flips. How does the client find out the bit changed?

The client has to poll fast enough to catch it.. Modbus servers never initiate. Every conversation starts with a client request; the server answers, then waits silently. There is no asynchronous "by the way, this just changed" — if a sequence cares how fast it sees a new value, the client must poll often enough to catch it. (Change-of-Value push is a BACnet feature, not a Modbus one.)

Modbus TCP drops the two-byte CRC that Modbus RTU puts at the end of every frame, because TCP already handles error detection.

True. Same function codes, same data model — only the envelope changes. Modbus RTU appends a two-byte CRC for line-error detection on the serial wire; Modbus TCP wraps the same function-code-plus-data payload in a small TCP header and drops the CRC, since the TCP stack already detects corruption.

Input register 0 and holding register 0 are the same storage location, just reached through two different function codes.

False. The four data tables are addressed independently. Register 0 in the input table and register 0 in the holding table are different storage locations. The address alone never tells you which table — the function code (which names the table to act on) is what disambiguates.

You need to read a VFD's speed feedback — a measured value the controller can't write. Which Modbus table is it most likely in?

Input registers (16-bit, read-only). Speed feedback is a measured 16-bit value the client only reads — that's an input register (FC04). The speed command, by contrast, is a setpoint the client writes, so it lives in a holding register (FC03 read, FC06/FC16 write). Coils and discrete inputs are single-bit tables.

Which function codes are the workhorses for holding registers — reading a setpoint and writing a setpoint — in BMS integration?

FC03 to read, FC16 to write. FC03 reads holding registers; FC16 writes multiple holding registers (FC06 writes a single one). FC04 reads input registers — read-only sensor values — and the bit-table codes (FC01/FC02/FC05/FC15) act on coils and discrete inputs, which show up more in older industrial gear than in BMS work.

The Modbus protocol caps a single register read at how many registers? (The protocol ceiling — individual devices often set lower limits.)

125 registers. The protocol caps a register read at 125 and a coil read at 2000 per request. Most devices set tighter limits in their docs, so a poll that reads "everything in one shot" can quietly exceed a device's real ceiling even when it's under the protocol max.

You send an FC03 read and the server's reply comes back with the function-code byte reading 0x83 instead of 0x03. What does that tell you?

The request failed; the FC was echoed with its high bit set, so the next byte is an exception code.. The high-bit-set echo is the universal exception signal: FC 0x03 | 0x80 = 0x83. It means "the request failed — look at the next byte for why." A response with the function code echoed and no high bit set is a normal one, and the bytes after it are the data you asked for.

You poll device #1 and this comes back on the wire (after the address byte). Read it: what happened? request: 01 03 00 31 00 01 ... response: 01 83 02 ...

FC03 failed with exception 0x02 — Illegal Data Address; the register isn't in this device's map.. The response FC byte is 0x83 = 0x03 | 0x80, so it's an exception, and the byte after it (0x02) is the exception code: Illegal Data Address. The function code was understood, but the requested address isn't in the device's documented map — most often a 5-digit off-by-one (asking for register 0x31 = 49 when the map stops short). 0x83 is the marker, not the reason; the reason is always the byte after it.

You write 150 to a register the manual documents as a 0–100 % setpoint and the device returns exception 0x03 (Illegal Data Value). What is it telling you?

The address is fine, but the value being written is outside the allowed range.. 0x03 Illegal Data Value means the address was valid but the value isn't — writing 150 to a 0–100 % register is the canonical example. Contrast: 0x02 (Illegal Data Address) is a bad address, and 0x01 (Illegal Function) is an unsupported function code — often FC03 aimed at a register that only exists in the input-register table.

Practice · Modbus Basics

Modbus Basics Quiz Modbus

Ten questions on the fundamentals from the Modbus Basics lesson — the four data tables and their independent addressing, the FC03 / FC04 / FC16 function-code pairs, the client-polls / server-answers model, and how an exception response signals failure with the high bit set. Each reveal links back to the section of the lesson it came from.

← All practice