Modbus Scanner: How to Scan a Modbus Network and Find Devices (2026)

A Modbus scanner solves the most common problem you hit when you take over an existing installation: there is a bus full of devices, but nobody knows which slave addresses are used or what baud rate the devices speak. Without a scan you work blind. With a scan you have the full address list in a few minutes.

This guide shows how to use a Modbus scanner on both Modbus RTU (RS485) and Modbus TCP, which free and paid tools installers reach for every day, and the three pitfalls that make a scan fail: duplicate addresses, an unknown baud rate, and the broadcast address 0. It is written for installers in HVAC, refrigeration, solar, and EV charging, not for protocol authors.

Key takeaways

• Modbus slave addresses run from 1 to 247. A scanner polls each address one at a time and flags the addresses that answer.
• If you do not know the serial settings, sweep baud rate, parity, and stop bits. 9600 8N1 and 2400 8N1 cover most devices.
• Two devices set to the same address on one bus collide and produce CRC errors. Fix it by connecting devices one at a time.

What does a Modbus scanner actually do?

A Modbus scanner is a tool that systematically addresses every possible slave ID on a bus and records which addresses answer. The scanner sends each unit ID a small read request, usually function code 0x03 (read holding registers) for one register at address 0x0000, and notes whether a valid reply comes back within the timeout.

The valid address range is fixed in the Modbus Application Protocol Specification V1.1b3 from the Modbus Organization. An individual device uses an address between 1 and 247. Address 0 is the broadcast address (write only, no reply), and 248 to 255 are reserved. A scan therefore walks those 247 addresses and ticks each one where a device responds.

One point matters most: a scanner only finds devices that speak the same serial settings as the scanner itself. If a device sits at 19200 8E1 while you scan at 9600 8N1, it stays invisible. For the frame layout and the slave address, see the Modbus RTU explainer. For the protocol as a whole, see our complete guide to Modbus.

What you need before scanning

For an RTU scan you need a USB to RS485 converter, the cable to the bus (A, B, and ideally GND), and a scan tool on your laptop. For a TCP scan you only need network access to the subnet where the devices or the gateway live.

Note down what you already know: the number of devices that should be on the bus, and whether the manufacturer states a default baud rate. An Eastron SDM630 energy meter, for example, starts at 2400 8N1 (Eastron SDM630 Technical Datasheet), while many PLC-linked devices sit at 9600 or 19200.

Step by step: scanning a Modbus RTU network

The order is always the same: first find the address at known serial settings, and only if that turns up nothing, work out the serial settings themselves.

1. 1

   Connect the scanner and pick starting settings

   Connect the USB to RS485 converter to A and B of the bus. Start with the most common setting: 9600 baud, 8 data bits, no parity, 1 stop bit (8N1). Set the response timeout generously, around 300 milliseconds, so slow devices can keep up.

2. 2

   Scan the full address range 1 to 247

   Have the tool poll each address with function code 0x03 or 0x04 for one register. In modpoll you do this in a loop: modpoll -m rtu -a <id> -r 1 -c 1 -b 9600 -P none /dev/ttyUSB0. Addresses that return a valid frame are occupied. Write them down.

3. 3

   If nothing answers, sweep the serial settings

   If the whole scan stays silent, the baud rate or framing is wrong. Sweep the combination of baud rate and framing until you get a valid CRC. In practice: start at 9600 8N1, then 2400 8N1, then 19200 8N1, then the even-parity variants (8E1).

The Modbus over Serial Line Specification V1.02 names 9600 and 19200 baud with even parity as the standard, but manufacturers often deviate. Plan for seven common baud rates (1200 to 115200) and three framings (8N1, 8E1, 8O1). The function codes you use here, such as 0x03 and 0x04, are explained in the Modbus function codes reference.

The three pitfalls when scanning

A scan that returns nothing, or nonsense, almost always comes down to one of these three causes.

Pitfall 1: two devices with the same address. If two devices sit at address 3, both answer every poll to address 3 at the same instant. Their frames overlap on the bus, which produces CRC errors and unreadable data. You cannot scan reliably in that state.

The fix is point-to-point work: disconnect every device, connect one, read or set its address, connect the next. That gives each device a unique address between 1 and 247 and the collision disappears.

Pitfall 2: the broadcast address 0. Address 0 is reserved for broadcast writes to all devices at once. Devices never reply to it by definition, so you will never discover a device on address 0. Skip address 0 and start at 1.

Pitfall 3: the bus is physically disturbed. A missing termination resistor, swapped A and B lines, or an over-long spur makes devices drop out at random. A device that answers on one scan and not the next points to a wiring problem, not an address problem. See the RS485 wiring guide for termination and polarity.

Scanning Modbus TCP on port 502

For Modbus TCP, scanning runs in two layers. First you find which IP addresses on the network listen on TCP port 502, the standard Modbus port. Then you scan the unit IDs behind each IP, because a TCP to RTU gateway can bridge several RTU devices behind a single IP.

For the first layer you use nmap: nmap -p 502 --open 192.168.1.0/24 finds every host with an open Modbus port. Nmap also has a dedicated script: nmap --script modbus-discover -p 502 <ip> enumerates the unit IDs and, via Read Device Identification (function code 0x2B, MEI type 0x0E), tries to read the vendor and product (Nmap NSE modbus-discover documentation). For the port and frame layout of TCP, see the Modbus TCP explainer.

Which scanner tools can you use?

No single tool does everything. These are the options installers reach for most, from free CLI to paid GUI.

For a one-off job on site, a free GUI such as CAS Modbus Scanner is the fastest. If you want to automate scanning or wrap it in a script, modpoll and pymodbus are more practical.

Troubleshooting a scan

An exception response (for example function code 0x83) is actually good news during a scan: it means there is a device on that address, only the register you asked for does not exist. The address is occupied.

Scanning continuously from the cloud

A one-off scan gives you a snapshot. In practice a fleet changes: a technician adds a meter, a device goes silent on a failed power supply, or someone changes an address. Scanning again by hand does not scale across dozens of sites.

This is where the ModbusCloud Gateway fits. The Gateway performs auto-discovery on the connected bus and keeps polling the known addresses continuously. If a device disappears or a new address appears, you see it in the dashboard immediately instead of at the next service visit. Paired with automated Modbus alerts, you get a notification the moment a device drops out, with no need to scan on site.

Frequently asked questions

Next steps

A good scan starts with the right serial settings and ends with a clean address list without duplicates. Combine this approach with the Modbus RTU explainer to understand what goes across the bus byte by byte, and with the Modbus function codes reference to read your scanner's requests.

Do not want to scan on site every time something changes? The ModbusCloud Gateway takes over the discovery and polling work and keeps your fleet in view continuously. Book a short demo to see how it works across multiple sites.