After commissioning, every shared value follows one controlled path: a slave exposes local data, the master polls it, the master updates its canonical data model, and the master writes only the consumers that need the value. A slave never initiates a Modbus RTU transaction.
Where does each Modbus RTU request travel?
Follow the packet. The master creates a request, its USART sends the frame through the selected physical interface, one addressed slave processes it, and that slave returns the response over the same segment. Every other slave remains silent. A slave with changed data must wait for a master request; Modbus RTU has no unsolicited slave-to-master message.
Layer one first. A microcontroller USART is not by itself a multidrop fieldbus interface. Connect each node through hardware suitable for the chosen shared physical layer. On an RS-485 segment, configure compatible transceivers, a common reference, cable topology, termination, biasing, and transmitter direction control. One active transmitter at a time is the operating rule.
| Path item | Required agreement | Commissioning check |
|---|---|---|
| Physical segment | Compatible electrical interfaces and wiring | Inspect waveforms and verify clean idle and driven levels |
| Serial port | Baud rate, parity, data format, and stop setting | Read one slave repeatedly without framing errors |
| Slave address | Unique address for every node on the segment | Query nodes individually and match each response |
| Frame timing | Master timeout and inter-frame handling suitable for the devices | Confirm responses complete before the next request |
Proof before continuing: poll every slave separately and obtain repeatable responses without collisions, framing errors, or responses from the wrong address.
Who should own each shared register value?
Keep shared state in the master. Each slave owns only the measurements, inputs, or locally calculated values it produces. The master reads those source registers, validates them, stores the accepted values, and distributes them to registered consumers. Slaves do not need knowledge of other slave addresses or maps.
Build a master-side routing table before writing polling logic. Define ownership at the value or block level rather than treating all registers in every slave as shared.
| Map field | Purpose |
|---|---|
| Owner | Identifies the only device allowed to originate the value |
| Source range | Defines the contiguous registers the master reads |
| Consumers | Lists only the slaves that require the value |
| Destination range | Defines where each consumer receives it |
| Update class | Selects cyclic, change-driven, or initialization handling |
| Validation | Defines range, freshness, and communication-quality checks |
If an intelligent slave knows something the master does not, that slave still owns and exposes the result. The master does not need to reproduce the calculation; it needs a defined register range, validity rule, and routing destination.
Proof before continuing: trace every shared value to exactly one owner and at least one explicit destination, with no circular ownership.
How can polling scale to a slave with 5000 registers?
Do not scan all 5000 registers on every cycle. Divide the map by purpose and update rate. Poll fast-changing control inputs more often, slow measurements less often, and static configuration only at initialization or after a detected change.
For slaves you design, reserve a compact command/status block as a change mailbox. This is not an unsolicited transmission: the master still polls the mailbox. A reliable exchange uses this sequence:
- The slave updates its owned data and marks the affected block or blocks as pending.
- The master polls the compact status block.
- The master reads each indicated contiguous range.
- The master accepts the data only after the complete range passes communication and value checks.
- The master acknowledges the processed change indication.
- The slave retains or renews the indication if another change occurred during the exchange.
A bitmap works for a fixed set of blocks; a queue works when ordered changes matter. Include a generation value or equivalent handshake so a new update cannot be erased by an acknowledgment for an older update. Third-party slaves that lack this custom mailbox remain on scheduled polling.
| Polling class | Typical content | Trigger |
|---|---|---|
| Fast cyclic | Operator inputs and control state | Recurring schedule |
| Slow cyclic | Slow process measurements | Recurring schedule |
| Change mailbox | Dirty-block indications | Compact recurring poll |
| Initialization | Configuration and starting state | Startup or reinitialization |
Proof before continuing: change data in each block and verify that the master reads the indicated range once, acknowledges it, and does not lose a second change made during acknowledgment.
How should non-consecutive values be transferred?
Group related values into contiguous blocks based on common owner, consumers, update rate, and validity. Reading a small amount of unused padding is usually cleaner than issuing many isolated transactions. Do not combine unrelated fast and slow data merely because their addresses are adjacent.
When multiple blocks are unavoidable, describe each block independently in the routing table. The scheduler can merge adjacent compatible blocks, but it must respect the maximum request size documented by each device. Keep decoding tied to the documented register type, byte order, and word order rather than copying raw storage blindly.
Proof before continuing: read every configured block boundary and compare the decoded engineering values with the producing slave, including the first and last register in each range.
How should the master relay updates between slaves?
Use targeted writes for normal distribution. The path is Slave A to master, master validation and change detection, then master to Slave B or Slave C. Send only when the accepted source value changes or when a consumer requires refresh.
Broadcast writes fit only values that every attached slave interprets at the same register range. A broadcast cannot read data, cannot select a subset of consumers, and provides no slave response for confirmation. Heterogeneous devices make broadcast initialization particularly risky because identical addresses may represent different data.
Take a stable snapshot of a multi-register value before transmission. If related values must change together, use a device-supported multi-register operation or an application-level validity handshake defined in both endpoints. Do not expose partially updated shared state to another task while the frame is being assembled.
Proof before continuing: change one source value, verify that only listed consumers receive it, and read each targeted consumer back when its map permits confirmation.
How is the complete data path commissioned?
- Capture a baseline with one slave connected, then add nodes while watching for physical-layer errors and duplicate responses.
- Poll every source block and record response status, decoded values, and transaction duration.
- Exercise each mailbox indication, including two updates occurring around the acknowledgment.
- Force each routed value at its owner and verify the master accepts, timestamps, and stores the correct result.
- Confirm each intended consumer changes while unrelated slaves and registers remain unchanged.
- Run the full schedule at the expected bus load and compare worst-case source-to-consumer latency with the application requirement.
The end-to-end test passes only when a physical change at the producing slave appears correctly in the master model and in every configured consumer, with no unexpected write elsewhere.
FAQ
Why does a Modbus RTU slave not notify the master directly?
Modbus RTU transactions are initiated by the master. The slave must expose changed data and wait for the master to poll either the data range or a custom command/status block.
Why does polling 5000 registers make the network slow?
Scanning 5000 registers consumes transactions and wire time even when most values have not changed. Split the map into contiguous blocks and assign each block a polling class or change indication.
Why does a broadcast write fail as a routing method?
A broadcast reaches all compatible slaves, cannot select individual consumers, and returns no confirmation response. Use addressed writes when destinations differ or delivery must be verified.
Why does a command register still require polling?
The command/status block is only a compact mailbox inside the slave map. The master must poll it, read the indicated data blocks, and acknowledge the processed indication without clearing a newer change.
How do I verify Modbus RTU data reached every slave?
Change one owned source value, confirm the master reads and validates it, then read back every targeted consumer where supported. The final check is that all configured consumers match the master while unrelated registers remain unchanged.