How Many Slave Devices Can Be Supported on a Modbus Network?

Modbus allows 247 slave addresses, RS-485 allows 32 unit loads per segment, and polling speed usually sets a lower practical limit of a few dozen devices per BMS trunk.

"How many devices can I put on one Modbus trunk?" has three different answers depending on which limit you hit first: the protocol's address limit, the electrical limit of RS-485, or the time it takes to poll everything. This guide explains all three, shows how to estimate polling performance, and gives practical design figures for building management systems.

Limit 1: the Modbus address range

Modbus RTU identifies each slave (server) device by a unit ID in a single byte:

So the protocol allows 247 devices on one Modbus RTU network. Every device on the trunk must have a unique address; two devices with the same address answer together and corrupt each other's replies.

On Modbus TCP, devices are identified by IP address, so the address limit does not apply in the same way. The unit ID is still sent, and matters when a TCP gateway forwards requests to serial devices behind it.

Limit 2: RS-485 electrical load

Modbus RTU usually runs on RS-485, which the standard specifies for 32 unit loads per segment. Each device's transceiver presents a load:

Many modern devices use fractional-load transceivers, so more than 32 can share a segment electrically. Check each device's datasheet. If the trunk mixes devices, add up their loads, including the master.

To go beyond one segment's limit, or to extend distance, use RS-485 repeaters, which start a new electrical segment. Cable length (about 1,200 m at lower baud rates), topology and termination also matter. See RS-485 wiring, termination and biasing.

Limit 3: polling performance (usually the real limit)

Modbus RTU has one master that polls devices one request at a time. The time to read everything grows with every device and every request, so responsiveness usually limits a BMS trunk long before addresses or unit loads do.

Estimating poll time

Each request-response takes roughly:

• the time to send the request and receive the response at the baud rate
• the device's own response delay
• the silent gaps required between Modbus frames

At 9,600 baud, a typical read of a handful of registers takes in the order of 20–60 ms including device response time. At 19,200 baud it is roughly halved. A slow device, or one that has timed out, can take hundreds of milliseconds.

Worked example

A trunk at 9,600 baud has 30 energy meters. Each meter needs 12 values, read in 3 block requests. At about 50 ms per request:

• 30 meters × 3 requests × 50 ms = 4.5 seconds per full cycle

That is fine for meters read every minute. But add 20 plant devices needing 1-second updates and the trunk cannot achieve them. Split the plant devices onto their own trunk.

Now consider one offline meter with a 1-second timeout and two retries: it adds up to 3 seconds to every cycle. That is why disabling or fixing dead devices is the first step in speeding up a slow network.

Practical design figures for BMS trunks

These are guidelines, not hard limits. Measure with the poll scheduler statistics and adjust.

How to fit more devices on a trunk

1. Raise the baud rate if every device supports it (for example 19,200 or 38,400).
2. Read registers in blocks instead of one request per value.
3. Poll only what you need, and put slowly changing values in the Slow poll group.
4. Fix or disable offline devices so timeouts do not stall the cycle.
5. Reduce timeouts and retries sensibly for devices that respond quickly, without making them so short that slow devices fail.
6. Split the trunk across more RS-485 ports or Modbus TCP gateways. See how many Modbus networks a JACE supports.

Response timeouts and retries

Two driver settings have a large effect on how many devices a trunk can serve:

• Response timeout: how long the master waits for a reply before giving up. Too long, and every missing or slow device stalls the cycle. Too short, and slow but healthy devices are marked down.
• Retries: how many times a failed request is repeated. Each retry multiplies the time lost to a dead device.

A sensible approach is to measure how quickly your devices actually respond, set the timeout comfortably above the slowest healthy device (often a few hundred milliseconds at 9,600 baud), and keep retries low. Watch the network's statistics for timeouts and CRC errors after changes.

Also check the inter-message delay some devices require between requests. Devices that need a pause before they can answer the next request will produce errors if polled back to back; a small delay fixes them at a modest cost in throughput.

Planning a large metering installation

Large sub-metering projects are where trunk sizing matters most. A typical approach for, say, 150 meters across a campus:

1. Group meters by location: one trunk per riser, plant room or building.
2. Limit each trunk to around 30–50 meters, depending on baud rate and the points read per meter.
3. Use the fastest common baud rate all meters support.
4. Read only the values you report on: typically energy totals, plus power and power factor for main meters.
5. Put meters in the Slow poll group: consumption reporting rarely needs values more often than every minute.
6. Bring distant trunks back over IP with Modbus TCP gateways rather than long serial runs.
7. Consider wireless: for scattered small loads, LoRaWAN current transformers and pulse counters avoid serial cabling altogether (see What is LoRaWAN?).

Document each trunk: devices, addresses, baud rate, termination positions and the port or gateway it connects to.

Signs a trunk is overloaded

You do not need a protocol analyser to spot an overloaded trunk. Look for:

• graphics that take many seconds to fill in when opened
• values in histories that change in steps rather than smoothly
• the poll scheduler's Busy Time near 100% and cycle times well above the configured rates
• points flickering into {stale} status
• control loops that respond sluggishly because their inputs update slowly
• complaints that problems get worse when more people use the BMS

Any of these is a cue to review the trunk with the steps above before adding more devices.

Addressing good practice

• Plan addresses in the design and record them on the network schedule and device labels.
• Leave gaps for future devices in logical blocks (for example meters 1–40, plant 50–60).
• Never leave a new device on its factory default address (often 1) when adding it to a live trunk; set its address first, or you will clash with an existing device.
• Use the same serial settings (baud rate, parity, stop bits) for every device on the trunk.

Mixing device types on one trunk

Devices from different manufacturers can share a Modbus RTU trunk if:

• they all use Modbus RTU (not BACnet MS/TP or a proprietary protocol)
• they support the same baud rate and framing
• each has a unique address
• they behave well electrically (correct biasing and termination)

A single badly behaved device, for example one that responds slowly or holds the bus, can degrade the whole trunk. If one model causes trouble, give it its own port or a gateway.

Modbus RTU trunk design table

Use this as a quick reference when designing trunks:

Commissioning a new trunk

When bringing a Modbus RTU trunk online, add devices one at a time rather than all at once:

1. Wire and terminate the trunk, and check A–B resistance with power off (about 60 Ω).
2. Power the controller and the first device, set the device's address and serial settings, and confirm it responds.
3. Add each further device, confirming communication before moving on.
4. Add points with block reads and assign poll groups.
5. Reset the poll scheduler statistics, run the trunk under normal load, and record cycle times and timeouts.
6. Label each device with its address and record everything in the network schedule.

Bringing devices up one by one makes address clashes and wiring faults obvious immediately, instead of leaving you to untangle a trunk where nothing responds.

Frequently asked questions

How many devices can be on a Modbus RTU network?

The protocol allows 247 addresses, RS-485 allows 32 unit loads per segment (more with fractional-load devices), and polling speed typically limits practical BMS trunks to a few dozen devices.

What is the Modbus slave address range?

1 to 247 for individual devices. Address 0 is broadcast and 248–255 are reserved.

Can I have more than 32 devices on RS-485?

Yes, if the devices use fractional-load transceivers, or by adding repeaters to create additional segments.

Why is my Modbus network slow with only 20 devices?

Common causes are a low baud rate, too many points in fast polling, one request per value instead of block reads, and timeouts from offline devices.

Do Modbus TCP networks have a device limit?

Not the 247-address limit in the same way, since devices use IP addresses. Practical limits are licence capacity, controller resources and device connection limits.

What baud rate should I use for Modbus RTU?

The fastest rate every device on the trunk supports reliably, commonly 19,200 or 38,400 for modern devices. Use 9,600 only if some devices require it, and keep all devices on the same setting.

What happens if two Modbus devices share an address?

Both respond to the same request, their replies collide, and the master sees corrupted data or timeouts. Give every device on a trunk a unique address.

Can two Modbus devices have the same address on different trunks?

Yes. Addresses only need to be unique on each trunk (network).

How long can a Modbus RTU cable be?

Up to about 1,200 m per segment at lower baud rates. Higher baud rates shorten the safe length, and repeaters extend it.

Do Modbus TCP gateways change the device limit?

Each gateway's serial side is its own RS-485 trunk with the usual limits. Using several gateways spreads devices over several trunks, which raises the total the system can handle.

Does a slow device slow down the whole trunk?

Yes. The master waits for every response, so a slow or non-responding device adds delay to every polling cycle on that trunk.

What is a unit load in RS-485?

A measure of how much a device's receiver loads the bus. A standard segment supports 32 unit loads; devices with half, quarter or eighth unit loads allow more devices.

Need help from a Niagara engineer?

If this guide has not solved the problem, contact the Tyrrell Products technical team on 01942 732819 or [email protected]. Tell us the controller or host type, its Niagara version and what you have already tried, and we will help you get the system running.

Related guides

• What is Modbus? RTU vs TCP
• How many Modbus networks a JACE supports
• RS-485 wiring, termination and biasing
• How the poll scheduler works