How to Configure Multiple Modbus Slaves in One Modbus Sim

Most real Modbus networks aren't one master talking to one device. A SCADA system polls a dozen energy meters. A PLC network reads from eight remote I/O racks. An IIoT gateway aggregates readings from fifteen sensors on a single RS-485 bus. If you only ever test against a single simulated slave, you're testing a scenario that almost never happens in production — and you'll miss the bugs that only show up under multi-device load.

This guide covers how to configure and run multiple Modbus slaves in one modbus sim session: Unit ID addressing, port-based TCP addressing, mixed TCP/RTU setups, and a Python script to verify everything is responding correctly.

What "Multiple Slaves" Means in a Modbus Simulator

When people search for a "modbus sim" that supports multiple slaves, they usually mean one of two things:

• Multiple independent slave instances — each with its own register map, running inside the same simulator application, so you don't need to open five separate programs to represent five separate devices.
• Multiple Unit IDs on a shared connection — a single TCP socket or serial bus where several virtual devices respond to different Unit ID (Slave ID) numbers, exactly like a real RS-485 network with several field devices sharing one cable.

ModbusSimulator supports both models, and you can mix them: run some slaves on separate TCP ports, others sharing a port with distinct Unit IDs, and RTU slaves on a virtual or real COM port — all in the same session.

Common Use Cases for Multi-Slave Testing

Scenario	What You're Testing	Typical Slave Count
SCADA commissioning	Master polling many devices without timing out or dropping tags	10–50
PLC remote I/O network	Remote rack addressing, watchdog behavior when a rack drops offline	4–16
IIoT / MQTT gateway	Gateway correctly maps each device's registers to its own MQTT topic	5–20
RTU serial bus	Bus-level collisions, response timing, Unit ID conflicts	2–32
Fault-tolerance testing	Master behavior when one of many slaves goes offline mid-poll	Any — take 1 offline

Step 1 — Plan Your Addressing Scheme Before You Start

Before opening the simulator, decide how each slave will be identified. This avoids the single most common multi-slave mistake: two devices accidentally sharing the same address.

• Modbus TCP, separate ports: device 1 on port 502, device 2 on port 503, device 3 on port 504, and so on. Simple to configure, easy to debug, but you must open a firewall rule per port if testing across a network.
• Modbus TCP, shared port: all devices on port 502, each with a unique Unit ID (1–247). This matches how many real Modbus TCP gateways aggregate serial devices behind one IP.
• Modbus RTU, shared bus: all devices on the same COM port / baud rate, each with a unique Unit ID. This is the closest simulation of a physical RS-485 network.

Keep a simple table (spreadsheet or text file) mapping device name → Unit ID → port/COM → register range. You'll need it again the moment something doesn't respond as expected.

Step 2 — Create the First Slave

Open ModbusSimulator and add a new Slave instance. Choose the protocol (TCP, RTU, ASCII, or one of the cross-framing variants), then set:

• Device name — something meaningful, e.g. "Meter-01" rather than "Slave1"
• Unit ID — start at 1 and increment for each additional device
• Port / COM port — per your addressing plan from Step 1
• Register map — holding registers, input registers, coils, and discrete inputs with realistic starting values

Save and start the slave. Verify it responds using the simulator's own Master mode or a separate poll tool before adding more devices — it's far easier to debug one slave in isolation than to debug five at once.

Step 3 — Add Additional Slave Instances

Repeat the process for each additional device, incrementing the Unit ID and/or port. For a shared-port setup:

For a separate-port setup, replace the Unit ID column with sequential ports (502, 503, 504, 505, 506) and keep Unit ID at 1 for every device — both approaches are valid, and which one you choose should match how your real master or SCADA system will actually connect.

Step 4 — Mixed TCP and RTU Slaves

If you're testing a gateway that bridges Modbus RTU field devices to a Modbus TCP/SCADA network, run RTU slaves on a virtual COM port pair (or a real USB-to-RS485 adapter looped to itself) alongside your TCP slaves. This lets you simulate the entire chain — RTU field devices → gateway → TCP master — without any physical hardware. See our Modbus-to-MQTT bridge testing guide if your gateway also needs to publish to MQTT.

Step 5 — Verify Everything With a Poll Script

Once your slaves are running, verify addressing with a quick Python script using pymodbus. This example polls five slaves sharing one TCP port with distinct Unit IDs:

from pymodbus.client import ModbusTcpClient

HOST = "127.0.0.1"
PORT = 502
UNIT_IDS = [1, 2, 3, 4, 5]

client = ModbusTcpClient(HOST, port=PORT)
client.connect()

for uid in UNIT_IDS:
    result = client.read_holding_registers(address=0, count=4, slave=uid)
    if result.isError():
        print(f"Unit {uid}: ERROR - {result}")
    else:
        print(f"Unit {uid}: {result.registers}")

client.close()

Run this against your simulator and confirm every Unit ID returns its own distinct register values. If two Unit IDs return identical data, double-check you didn't accidentally clone a slave configuration without changing its Unit ID.

Common Multi-Slave Mistakes

• Duplicate Unit IDs on the same connection — the master will only ever "see" one of the two devices, usually whichever responds first. Always keep your addressing table up to date.
• Port conflicts — if two slaves try to bind the same TCP port with no Unit ID separation, the second one will fail to start. Windows will usually report "address already in use."
• Polling too fast for too many devices — a master hammering 30 slaves at a 100 ms interval each will queue requests and may start timing out. Increase the poll interval or stagger requests across devices.
• Forgetting RTU bus timing — on a shared serial line, only one device can transmit at a time. If your simulated slaves respond too quickly relative to your configured RTU inter-frame delay, you may mask timing bugs that would appear on a real RS-485 bus.
• Testing only the "happy path" — take one slave offline mid-test to confirm your master or SCADA handles a single device dropping out without stalling the whole poll cycle.

Scaling Up: From 5 Slaves to 50

Once your addressing scheme and register maps are validated with a handful of devices, scaling to a full commissioning-scale test (20–50 slaves) is mostly a matter of repeating Step 3 with your naming/Unit ID convention. Save your multi-slave project file so you can reload the entire fleet instantly for regression testing after any change to your master's polling logic, SCADA tag database, or gateway firmware.

For a broader walkthrough of simulator basics before you dive into multi-slave setups, see our step-by-step beginner tutorial. If you specifically need to simulate a slave device with no PLC on hand at all, check how to simulate a Modbus slave without a PLC. And for a deeper look at slave-side configuration options, see the Modbus slave simulator guide.

Frequently Asked Questions

Can one Modbus simulator run multiple slaves at the same time?

Yes. A Modbus sim like ModbusSimulator can run multiple independent slave instances in a single application window. Each slave gets its own register map, and for TCP each slave listens on a distinct port or shares one port with a unique Unit ID. For RTU, multiple slaves share the same serial line but respond only to their own Unit ID.

What is the difference between Unit ID and port for multiple slaves?

Unit ID (also called Slave ID or Slave Address) identifies a device within a single Modbus TCP connection or a shared RTU bus — values 1 to 247 are valid, with 0 reserved for broadcast. Port-based addressing means each slave listens on its own TCP port with its own IP socket. You can combine both approaches depending on how your master or SCADA polls devices.

How many Modbus slaves can a simulator run at once?

This depends on the tool. ModbusSimulator supports dozens of concurrent slave instances on a typical Windows machine, limited mainly by available TCP ports and system memory. For serial RTU, the practical limit is the 247 addressable Unit IDs per bus, though most test setups use far fewer.

Why would I need multiple slaves in a Modbus sim instead of one?

Real plants rarely have a single Modbus device. Testing with only one simulated slave hides bugs that only appear under multi-device load — timeouts from polling too many devices too fast, Unit ID collisions, or a master that mishandles one device dropping offline while others stay up.

Can I simulate a mix of Modbus TCP and RTU slaves together?

Yes. ModbusSimulator lets you run TCP slaves and RTU slaves (over real or virtual COM ports) in the same session — useful for testing gateways that bridge Modbus RTU field devices to a Modbus TCP/SCADA network.

How do I avoid port conflicts when running many TCP slaves?

Assign each slave a unique combination of IP and port, or a shared port with unique Unit IDs. A common pattern is to start at port 502 for the first device and increment by one for each additional slave, keeping a naming convention so your master configuration matches the simulator exactly.

Does simulating multiple slaves slow down polling performance?

A small performance hit is normal as slave count grows, but ModbusSimulator handles dozens of slaves at 1-second poll intervals without issue on typical hardware. If response latency grows, check for CPU contention, reduce poll frequency, or split high-count tests across multiple simulator instances.

Can I script or automate multi-slave test scenarios?

Yes. ModbusSimulator includes a REST API for programmatic control, and you can also drive multi-slave scenarios externally with Python (pymodbus), letting you script value changes, simulated faults, and offline/online transitions across many virtual devices for automated regression testing.