Does anyone actually use Modbus broadcast?
Some do. Most engineers go their whole careers without touching it. Broadcast is one of those Modbus features that lives in the corner of the spec, gets one or two paragraphs in most books, and shows up unexpectedly when you have to commission a large multi-drop bus at 3 AM.
This article is a straight-talk reference: what Modbus address 0 is for, which function codes support it, what actually happens on the wire, and — most importantly — when it makes sense to use it, and when it is better avoided.
According to the Modbus Application Protocol Specification V1.1b3, broadcast requests use slave address 0 and are supported only on serial line implementations.
Table of Contents
The basics in one paragraph
Modbus broadcast is when a client sends a request to Modbus address 0 on a serial bus (typically RS-485) so that every slave device on the bus receives and processes it. Only write function codes can be broadcast because the servers do not send responses to broadcasts — if they all responded at once, they would collide on the bus. Broadcast is a serial concept; in native Modbus TCP it does not really apply, though some gateways interpret Unit ID 0 as “broadcast to all serial slaves behind this gateway.” Broadcast support is optional in the specification — not every device implements it.
Which function codes can be broadcast
Only write function codes support broadcast. Reads cannot broadcast because there would be no way to get a coherent response.
Here is the compatibility matrix:
| Function Code | Name | Broadcast? |
|---|---|---|
| 0x01 | Read Coils | ❌ No — read function |
| 0x02 | Read Discrete Inputs | ❌ No — read function |
| 0x03 | Read Holding Registers | ❌ No — read function |
| 0x04 | Read Input Registers | ❌ No — read function |
| 0x05 | Write Single Coil | ✅ Yes |
| 0x06 | Write Single Register | ✅ Yes |
| 0x07 | Read Exception Status | ❌ No — read function |
| 0x08 | Diagnostics | Partial — only specific diagnostic sub-functions defined by the Modbus specification support broadcast |
| 0x0B | Get Comm Event Counter | ❌ No |
| 0x0C | Get Comm Event Log | ❌ No |
| 0x0F | Write Multiple Coils | ✅ Yes |
| 0x10 | Write Multiple Registers | ✅ Yes |
| 0x11 | Report Slave ID | ❌ No |
| 0x14 | Read File Record | ❌ No |
| 0x15 | Write File Record | ✅ Yes |
| 0x16 | Mask Write Register | ✅ Yes |
| 0x17 | Read/Write Multiple Registers | ❌ No — has read component |
| 0x18 | Read FIFO Queue | ❌ No |
| 0x2B | Encapsulated Interface | Depends on MEI type / sub-function |
Although these function codes are defined as broadcast-capable, individual devices are not required to implement broadcast support. Broadcast is optional in the specification — you must verify each device supports it before relying on it.
In practice, engineers use only three broadcast function codes: 0x05 (Write Single Coil), 0x06 (Write Single Register), 0x10 (Write Multiple Registers). The others are technically allowed but rarely appear in real deployments.
For details on each function code, see our Modbus Function Codes Explained article.
What happens on the wire
Broadcast breaks the normal Modbus request/response pattern. Here is what a Modbus RTU broadcast looks like using Modbus address 0:
Master → All slaves:
Address: 0x00 ← Modbus address 0 (broadcast)
Function: 0x06 ← Write Single Register
Register: 0x0064 ← register 100
Value: 0x0400 ← write value 1024
CRC: xx xx ← two bytes of CRC
Slaves: (silent — no response)Every slave on the RS-485 bus:
- Receives the request
- Sees address 0 (broadcast)
- Executes the write (if it supports broadcast for this function code)
- Does NOT send a response
The master:
- Sends the request
- Waits for the configured broadcast turnaround delay
- Sends the next request
If the master waits for a response, it will time out because there is none. The master must know the request was a broadcast and not wait.
Serial vs TCP: the critical distinction
Broadcast is a serial Modbus concept intended primarily for multidrop RS-485 networks. While Modbus can operate over RS-232, standard RS-232 is point-to-point and does not provide the shared bus needed for practical broadcast communication. In practice, Modbus address 0 broadcast lives almost entirely on RS-485.
Modbus TCP is different. Each Modbus TCP connection is point-to-point — one client talking to one server over a dedicated TCP session. There is no “bus” in the physical sense. Broadcasting in the RS-485 sense does not exist.
So what happens if you send a Modbus TCP request with Unit ID 0?
Case 1: Direct Modbus TCP device. Some Modbus TCP servers ignore the Unit Identifier field entirely because it has no meaning for a direct TCP endpoint. Others reject Unit ID 0 as “reserved, do not use.” Behavior varies. Check the device manual.
Case 2: Modbus TCP gateway to serial bus. Some gateways interpret Unit ID 0 as broadcast to all serial slaves behind the gateway. The gateway forwards the request to the serial bus with Modbus address 0, and the slaves process it silently as they would in native Modbus RTU. Other gateways treat Unit ID 0 as a protocol violation. Again — check the manual.
Case 3: Modbus TCP client library. Some client libraries let you pick Unit ID freely, others restrict the choice, some warn you if you use 0. If you need broadcast semantics over TCP, you need a client that supports it and a gateway that interprets Unit ID 0 as broadcast.
For the broader TCP vs RTU comparison, see our Modbus RTU vs Modbus TCP article.
When broadcast is actually useful
Real scenarios where Modbus address 0 broadcast makes sense:
Synchronizing multiple drives. Sending a “start” or “stop” command to a batch of servo drives on the same RS-485 bus, at the same instant. A single broadcast Write Single Register accomplishes this — much faster than sending 20 individual writes back to back.
Setting a common setpoint. Writing the same speed setpoint to all drives on a bus during commissioning. Broadcast covers all devices in one message instead of 20 sequential writes.
Batch configuration. During initial commissioning, when you need to write the same parameter to many similar devices, broadcast saves time compared to unicast writes.
Time synchronization. Broadcasting a “reset counter” command to synchronize event timestamps across many slaves. If timing is critical, all slaves receive the command in the same bus cycle.
Test-and-teardown scripts. During testing, using broadcast to reset all slaves to a known state before starting a new test cycle.
When NOT to use broadcast
These reasons come up much more often than the “yes, use it” cases:
You need confirmation the write succeeded. Broadcast has no response, so you have no way to know if any slave processed it. If confirmation matters, use unicast writes.
Slaves may fail silently. A slave with a broken register mapping, a wrong data type, or a hardware issue will ignore the broadcast without any error signaled to the master. You have no visibility.
Safety-critical operations. Do not use broadcast for anything safety-related. Modbus itself is not a safety protocol, and the lack of acknowledgment makes broadcast even less suitable for safety functions.
You are on native Modbus TCP. As discussed above, broadcast does not have a well-defined meaning in TCP. Use unicast writes to each device.
Slaves have inconsistent implementations. If your bus has devices from multiple vendors, some may support broadcast and some may not. Testing coverage becomes hard.
Fault diagnosis needed. During troubleshooting, you want visibility into what each slave is doing. Broadcast hides everything.
For most modern SCADA deployments, the answer is: do not use Modbus address 0 broadcast. Individual writes with confirmations are safer, more diagnosable, and often not meaningfully slower.
Broadcast timing and turnaround delay
After sending a broadcast, the client waits for a vendor- or application-defined broadcast turnaround delay before sending the next request. The Modbus specification does not mandate a specific duration.
Why the delay? All slaves are simultaneously:
- Parsing the incoming frame
- Executing the write operation
- Updating their internal state
If the client sends another request immediately, some slaves may still be processing the broadcast and will miss the new request.
Typical turnaround values engineers use in practice:
| Bus configuration | Common delay |
|---|---|
| Slow bus (9600 baud, older devices) | 100 – 200 ms |
| Standard bus (19200-38400 baud) | 50 – 100 ms |
| Fast bus (115200 baud, modern devices) | 20 – 50 ms |
| Mixed vendor bus | Use the slowest device’s requirement |
Always check the device manual for its specific turnaround requirement. Some devices document a minimum “inter-frame delay” that applies after broadcasts.
If your broadcasts work sometimes but not others, or if slaves seem to miss following requests, extend the turnaround delay.
Gateway behavior in the wild
The most common broadcast confusion comes from Modbus TCP-to-RTU gateways.
Scenario: you have a Schneider Modicon PLC on Ethernet, a Modbus TCP-to-RTU gateway, and 15 RTU drives on an RS-485 bus behind it. Can you broadcast to all 15 drives?
Answer: it depends on the gateway.
Some gateways:
- Accept Unit ID 0 in the Modbus TCP request
- Forward it as Modbus address 0 broadcast on the RS-485 side
- Do not expect a response from the serial slaves
- Immediately acknowledge the TCP transaction locally after forwarding the serial broadcast, or return a vendor-specific success indication
Other gateways:
- Reject Unit ID 0 as invalid
- Return a Modbus TCP exception
- Do not forward to the serial side
Other gateways:
- Accept Unit ID 0 but wait for a response that never comes
- Time out the TCP request
- Return a timeout error to the client
How to know: read the gateway manual. Search for “broadcast” or “Unit ID 0” in the documentation. If it is not documented, test it on the bench before deploying.
Common problems and troubleshooting
Broadcast issues that show up in the field:
Slaves ignore the broadcast entirely. The slave does not implement broadcast for this function code. Check the device manual — broadcast support is optional per the Modbus spec, and many devices skip it.
Only some slaves process the broadcast. Vendor inconsistency. One brand implements broadcast, another does not. If you need broadcast, stick to devices you have verified support it.
Bus contention (multiple responses). If a slave incorrectly responds to a broadcast, its response collides with the master’s next request. Symptoms: CRC errors, unexpected timeouts. Identify and reconfigure or replace the misbehaving slave.
Timing issues after broadcast. Too-short turnaround delay causes slaves to miss the next request. Extend the delay.
Gateway rejects Unit ID 0. Gateway does not accept broadcast semantics. Either use a different gateway or fall back to unicast writes.
No visibility into failures. By design — broadcast has no response. Consider adding an individual read after broadcast to verify at least one slave applied the change (though this only verifies that one slave, not all).
For general Modbus troubleshooting, see our Modbus Troubleshooting article.
Address range reference
For clarity on the whole address space:
| Address | Meaning |
|---|---|
| 0 | Modbus address 0 — broadcast (serial only) |
| 1-247 | Individual slave addresses |
| 248-255 | Reserved by Modbus specification |
Some devices use addresses 248-255 for special functions in vendor-specific extensions. Follow the manual if you see any.
Alternatives to broadcast
If Modbus address 0 broadcast is tempting but risky for your use case, consider these alternatives:
Individual writes in a loop. Send the same write to each slave sequentially. Slower but every write is confirmed. For 20 slaves at 100 ms each, this takes 2 seconds — acceptable in most scenarios.
Grouped writes. Some devices support “write multiple registers” spanning a large range. Not the same as broadcast (still unicast to one slave), but it batches many register updates into one message.
Change of state notifications. Some slaves proactively report changes. Set up the change of state mechanism to notify the master rather than the master polling.
Higher-level protocols. For time-synchronized actions across many devices, consider protocols designed for it (EtherCAT, PROFINET IRT, IEC 61850 GOOSE). Modbus was not designed for tight synchronization.
Common questions
What is Modbus broadcast?
Modbus broadcast is a mode where the client sends a request to slave address 0. Every slave on the bus receives the request and processes it, but none of them send a response. Because no response comes back, only write function codes can be broadcast — read function codes would need a response to be useful. Broadcast is used mainly on serial buses (RS-485) where multiple slaves share a physical medium.
What is Modbus address 0 used for?
Modbus address 0 is the broadcast address. Sending a request to Modbus address 0 tells all slaves on the bus that this is a broadcast — they should process the write but not send a response. Individual slaves have addresses 1 through 247. Addresses 248-255 are reserved by the Modbus specification. Modbus address 0 broadcast is only meaningful on serial line implementations.
What is slave address 0 in Modbus?
Slave address 0 in Modbus is the broadcast address — the same as Modbus address 0. Any request sent to slave address 0 on a serial bus is a broadcast that every slave receives and processes silently. The naming varies (address 0, slave address 0, broadcast address), but they all refer to the same 8-bit value: 0x00.
Which Modbus function codes support broadcast?
Only write function codes: 0x05 (Write Single Coil), 0x06 (Write Single Register), 0x0F (Write Multiple Coils), 0x10 (Write Multiple Registers), 0x15 (Write File Record), 0x16 (Mask Write Register), and some sub-functions of 0x08 (Diagnostics). Read function codes cannot be broadcast because they would require responses from every slave, which would collide on the serial bus. Broadcast support is optional per the specification — not every device implements it.
Do Modbus slaves respond to broadcasts?
No. Slaves receive and process broadcast requests but do not send responses. This is by design — if multiple slaves responded to the same broadcast, their responses would collide on the shared RS-485 bus. The master must know it sent a broadcast and not wait for a response.
Does Modbus TCP support broadcast?
Not natively. Modbus TCP is point-to-point (one client to one server per TCP connection), so the serial-broadcast concept does not apply directly. Some Modbus TCP-to-RTU gateways interpret Unit ID 0 as “broadcast to all serial slaves behind the gateway,” but this is gateway-specific behavior. Native Modbus TCP devices typically ignore Unit ID 0 or reject it. Check the specific device documentation.
What does Unit ID 0 mean in Modbus TCP?
Behavior varies by device and gateway. Some Modbus TCP-to-RTU gateways treat Unit ID 0 as broadcast to their serial-side slaves. Some direct Modbus TCP servers ignore the Unit Identifier field entirely because it has no meaning for a direct TCP endpoint. Others reject Unit ID 0 as a protocol violation. There is no universal rule — check each device’s documentation. If you need broadcast semantics over Modbus TCP, verify gateway behavior before deploying.
What is the broadcast address in Modbus?
The broadcast address in Modbus is 0 (0x00) — often called Modbus address 0. Any request addressed to 0 on a serial Modbus bus is a broadcast that all slaves on the bus receive and process. The broadcast address exists only on serial line implementations. In native Modbus TCP there is no true broadcast address; Unit ID 0 has device-specific meaning that varies by implementation.
What is the broadcast turnaround delay?
The broadcast turnaround delay is the time the master waits after sending a broadcast before sending the next request. This gives all slaves time to process the broadcast without colliding with the next message. The Modbus specification does not mandate a specific duration — it is a vendor- or application-defined value. Common practice: 20 ms (fast modern buses) to 200 ms (slow legacy devices). Check each device’s manual for its specific minimum inter-frame delay.
Why would I use Modbus broadcast?
Broadcast is useful for synchronizing an action across multiple slaves at the same instant — starting all drives simultaneously, sending the same setpoint to a group of devices, or writing common configuration to many similar devices during commissioning. It is also faster than looping through individual writes when you have many devices to update with the same value.
When should I avoid Modbus broadcast?
Avoid broadcast when confirmation is needed (no response means no confirmation), for safety-critical operations, on native Modbus TCP without gateway broadcast support, when your bus has devices from multiple vendors with inconsistent broadcast implementations, or during troubleshooting when you need visibility into what each device is doing. In most modern SCADA deployments, unicast writes are safer and more diagnosable than broadcast.
How do I know if my device supports Modbus broadcast?
Check the device manual for “broadcast” or “address 0” behavior. Some devices document broadcast support explicitly. If not documented, test on the bench: send a broadcast with a known write, then read back from an individual device to verify the write took effect. If the manual is silent and testing fails, assume broadcast is not supported.
Is Modbus broadcast reliable?
Not for critical operations. Broadcast has no acknowledgment, so you cannot verify that any specific slave received and processed the request. A slave with a broken configuration, hardware fault, or mismatched register map will silently ignore the broadcast. If reliability matters, use unicast writes with confirmations.
Can I broadcast a Read command in Modbus?
No. Read function codes (0x01, 0x02, 0x03, 0x04) cannot be broadcast because every slave would try to respond simultaneously, causing bus collisions. Only write function codes support broadcast, and only writes that do not require a response make sense in a broadcast context.
What happens if a slave sends a response to a broadcast?
That is a slave implementation bug — no slave should respond to Modbus address 0. If it does, the response will likely collide with the master’s next request on the RS-485 bus. Symptoms include CRC errors, unexpected timeouts, and general bus instability. Identify the misbehaving slave with a bus analyzer and either reconfigure it or replace it.