Is Unit ID 0 safe for writes?

It is the RTU broadcast address and produces no response. Use it only when the device documentation and commissioning procedure explicitly require a broadcast write.

Can I write a float with FC06 twice?

Only if the device explicitly permits split updates. FC16 is normally safer for a contiguous multi-register value because the block is sent in one request.

Does a successful FC16 response prove every register was applied?

It confirms acceptance of the addressed block. Device-specific application, persistence, and process effects still require documented read-back or independent verification.

Safe Modbus writes with FC05, FC06, FC15, and FC16

Name the exact target and consequence

Record the transport, Unit ID, address space, PDU offset, width, raw value, engineering interpretation, and device state that permits the action. Do not infer writability from a successful read or from an adjacent writable register.

Choose the smallest correct function

FC05 writes one coil and FC15 writes multiple coils. FC06 writes one holding register and FC16 writes a contiguous register block. Multi-register values such as float32 should be written atomically when the device requires it; two FC06 operations may expose a transient half-updated value.

Build and inspect a write request offline

Verify protocol and process state

Validate the echoed address and value or quantity in the response, then read the target back with the documented read function. Finally check the independent process indication. A matching register proves stored state, not that a relay moved, a drive started, or an interlock remained satisfied.

Require explicit confirmation for manual writes
Log the raw request and response
Read back the complete value
Keep automation guards and assertions visible

Review the Waveshare I/O map and source document

Build a precondition around the write

Read and record the current value immediately before the change. Confirm the device mode, interlocks, ownership, and any range or rate limits stated by the manufacturer. If another controller can write the same object, establish which system owns it during the test. A correct Modbus frame can still be an unsafe process command.

Preview the raw payload after scale, offset, signedness, and word order are applied. Check that the engineering value and encoded value agree, especially around negative numbers and multi-register types. Keep a known recovery value and define who may apply it if the expected response does not occur.

Confirm written access in the manual
Read the current value
Check device mode and interlocks
Preview the exact encoded payload
Define read-back and recovery before sending

Understand what the acknowledgement proves

The standard write response confirms that the server accepted the protocol operation. It does not prove that non-volatile storage completed, that a physical output changed, or that a higher-level controller did not overwrite the value a moment later. Read the documented object back and observe an independent status or process measurement when the consequence matters.

For broadcast writes on RTU, there is no response by design. That removes the acknowledgement and requires an explicit follow-up read from each intended server. Never treat a timeout after Unit ID 0 as evidence that the broadcast failed or succeeded.

Keep polling and writes from racing

A background poller, manual editor, automation scenario, and external controller can all interact with the same register. Serialize operations through one connection owner and show which source issued each frame. For read-modify-write behavior, remember that the value can change between the read and write unless the device provides an atomic function or ownership mechanism.

Record the request, response, read-back, independent outcome, operator, and time. If the change becomes a repeatable test, encode preconditions, bounded waits, assertions, and failure recovery rather than replaying a naked write.