Multi-Protocol PLC Discovery: How to Automatically Identify Devices on Your Factory Network [2026]

Commissioning a new IIoT gateway on a factory floor usually starts the same way: someone hands you an IP address, a spreadsheet of tag names, and the vague instruction "connect to the PLC." No documentation about which protocol the PLC speaks. No model number. Sometimes the IP address is wrong.

Manually probing devices is tedious and error-prone. Does this PLC speak EtherNet/IP or Modbus TCP? Is it a Micro800 or a CompactLogix? What registers hold the serial number? You can spend an entire day answering these questions for a single production cell.

Automated device discovery solves this by systematically probing known protocol endpoints, identifying the device type, extracting identification data (serial numbers, firmware versions), and determining the correct communication parameters — all without human intervention.

This guide covers the engineering details: protocol probe sequences, identification register maps, fallback logic, and the real-world edge cases that trip up naive implementations.

Why Automated Discovery Matters

In a modern manufacturing facility, you might have:

• 50–200 PLCs across multiple production lines
• 3–4 protocol families (EtherNet/IP, Modbus TCP, Modbus RTU via gateway, sometimes PROFINET)
• 10+ device types from different manufacturers (Allen-Bradley, Schneider, Siemens, ABB, Mitsubishi)
• No centralized device registry (the maintenance team's "master list" is a 2019 Excel file)

Manual commissioning at this scale means weeks of engineer time. Automated discovery can reduce that to hours.

But automated discovery isn't just about speed. It's about correctness:

• Eliminates misconfigured protocol settings (polling a Modbus device with EtherNet/IP commands)
• Catches IP address conflicts before they cause intermittent failures
• Detects device replacements (new serial number on a known IP address)
• Validates that the physical device matches the configuration database

The Multi-Protocol Probe Sequence

The key challenge: given an IP address (and optionally a TCP port), determine which industrial protocol the device speaks and what type of device it is.

Step 1: Try EtherNet/IP First

EtherNet/IP is the more structured protocol, and a successful EtherNet/IP connection gives you richer device identification data. The probe sequence:

1. Open a CIP connection to the device's default TCP port (44818)
2. Read a known identification tag — most Allen-Bradley controllers expose a device_type tag that returns a uint16 identifier
3. If the read succeeds, you've confirmed EtherNet/IP and identified the device type
4. Read serial number components — typically three separate tags: year, month, and unit number

# EtherNet/IP probe (conceptual)
Protocol: ab-eip
Gateway: <ip_address>
CPU: micro800
Tag: device_type → read uint16 → e.g., 1024 = Micro820, 1017 = Portable Chiller

The CIP (Common Industrial Protocol) layer handles session registration, connection establishment, and data encoding. What matters at the probe level is the tag path format:

• Micro800 series: Tags are string-named (e.g., device_type, serial_number_year)
• CompactLogix/ControlLogix: Tags can be program-scoped (e.g., Program:MainProgram.DeviceType)
• Third-party CIP devices: May use different tag structures entirely

Step 2: Fall Back to Modbus TCP

If the EtherNet/IP probe fails (connection refused, timeout, or tag not found), try Modbus TCP:

1. Open a Modbus TCP connection to the device's TCP port (default 502)
2. Read identification registers — the register address depends on the device type, but there are common conventions

For initial identification, read input register 800 (address 0x300320 in 6-digit notation). Many industrial controllers store a device type identifier here:

# Modbus TCP probe (conceptual)
Function Code: 04 (Read Input Registers)
Start Address: 800
Count: 1

If this returns a recognized device type code, you can determine the register map for serial number extraction.

Step 3: Read Device Identity

Once you know the device type, you know where to find serial number components. Different device types store identity data in different registers:

Example register maps by device type:

Device Type	Protocol	Year Register	Month Register	Unit Register	Register Type
Portable Chiller (1017)	Modbus TCP	Input 23	Input 22	Input 24	FC04
Central Chiller (1018)	Modbus TCP	Holding 510	Holding 520	Holding 500	FC03
TCU Controller (1021)	Modbus TCP	Holding 1038	Holding 1039	Holding 1040	FC03
Micro800 Series	EtherNet/IP	Tag-based	Tag-based	Tag-based	CIP Read

Notice the inconsistency — even within the same manufacturer, different product lines use different register locations and even different Modbus function codes. This is the reality of industrial automation, and it's why automated discovery needs device-specific profiles.

Step 4: Build the Serial Number

Once you have year, month, and unit components, compose the composite serial number:

Serial Number (32-bit):
  Bits 31–24: Year (8 bits, 0–255)
  Bits 23–16: Month (8 bits, 1–12)
  Bits 15–0:  Unit Number (16 bits, 0–65535)

This packed format is compact for storage and transmission while preserving manufacturing traceability. The year and month identify the production batch; the unit number identifies the specific device.

Validation rule: If the year component is zero, the serial number is invalid — either the register doesn't contain serial data, or the device hasn't been provisioned. Treat this as a discovery failure for that specific device and flag it for manual inspection.

Modbus Address Conventions

Modbus addresses follow a decades-old convention that still trips up engineers who learned about Modbus from modern tutorials:

6-Digit Address Range	Modbus Function Code	Description
000001–065536	FC01 (Read Coils)	Discrete outputs (bits)
100001–165536	FC02 (Read Discrete Inputs)	Discrete inputs (bits)
300001–365536	FC04 (Read Input Registers)	Input registers (read-only, 16-bit)
400001–465536	FC03 (Read Holding Registers)	Holding registers (read/write, 16-bit)

The key insight: the address prefix determines the function code. An address of 300800 means "input register 800, use FC04." An address of 400500 means "holding register 500, use FC03."

Automated discovery must parse these address conventions correctly, because using the wrong function code doesn't just fail — some PLCs will return garbage data from the wrong function code instead of an error, leading to silent data corruption.

The Off-by-One Problem

There's a historical inconsistency in Modbus addressing: are addresses 0-indexed or 1-indexed? The protocol itself is 0-indexed (address 0 is the first register). But the 6-digit convention is 1-indexed (register 400001 is address 0 in the holding register space).

In practice:

• Strip the prefix: 400500 → 500
• Subtract the base: 500 - 0 = 500 (some implementations subtract 1, some don't)
• Use that as the wire address in the Modbus PDU

This is a notorious source of off-by-one bugs. If your probe reads the wrong register, you get the wrong device type. Always verify by reading a known register with a known value during testing.

Handling Connection Failures

Factory networks are messy. Your discovery probe will encounter:

Timeout (No Response)

The device isn't at this IP address, the port is firewalled, or the device is powered off. Set a connection timeout of 2 seconds — long enough for slow PLCs, short enough to not block discovery of 200 devices.

Connection Refused

A TCP RST from the device means the IP is reachable but the port isn't open. This commonly happens when:

• The device speaks EtherNet/IP (port 44818) but your probe tried Modbus (port 502)
• The device is a managed switch or HMI, not a PLC
• The PLC's communication module hasn't been configured

Connection Succeeds, Read Fails

This is the most informative failure. It means the device speaks the protocol, but the specific registers/tags you're reading don't exist. Possible causes:

• Wrong CPU type: You probed for Micro800 tag names, but it's a CompactLogix
• Firmware version: Older firmware may not expose identification tags
• Device type: It's a third-party device that uses the same protocol but different tag structures

When this happens, log the protocol confirmation (the device does speak Modbus TCP / EtherNet/IP) and flag it for manual configuration.

Connection Instability

Some PLCs limit concurrent connections. If your gateway's discovery probe connects while the HMI and SCADA system are already using all available connections, the probe gets rejected or causes one of the existing connections to drop.

Best practice: Discovery should run during maintenance windows or use a dedicated Ethernet port on the PLC (if available). Never run discovery against a production PLC without coordinating with the controls engineer.

Modbus RTU Discovery

Modbus RTU over RS-485 adds a layer of complexity because:

1. No TCP connection — you're on a serial bus, and multiple devices may share the same bus
2. Slave addressing — each device has a unique address (1–247), and you must know the address to communicate
3. Serial parameters must match — baud rate, parity, data bits, and stop bits must be identical between gateway and device

Serial Parameter Negotiation

If you don't know the serial parameters, you have to try common combinations:

Common Industrial Serial Configurations:
  9600 baud, 8N1 (most common default)
  19200 baud, 8N1 (many newer devices)
  38400 baud, 8N1 (high-speed devices)
  9600 baud, 8E1 (European preference)
  19200 baud, 8E1

For each combination, send a probe to slave address 1 (most common default) and wait for a response. If you get a valid Modbus response frame (correct CRC), you've found the right parameters.

Timing on RS-485

Modbus RTU requires strict timing:

• 3.5 character silent interval between frames (at 9600 baud = 4.06ms)
• 1.5 character inter-character timeout within a frame (at 9600 baud = 1.74ms)
• Response timeout: Typically 100–500ms, configurable per installation

Set byte timeout and response timeout explicitly. The defaults in most Modbus libraries are tuned for fast local connections, not 200-meter RS-485 runs in electrically noisy environments.

Bus Scanning

To find all devices on an RS-485 bus, scan addresses 1–247 sequentially. For each address:

1. Set the slave address
2. Flush the serial buffer (critical — stale bytes from previous failed probes can corrupt the next read)
3. Send a read request (e.g., read input register 800)
4. Wait for response with timeout
5. If response received: device found at this address
6. If timeout: no device (or wrong parameters)

At 9600 baud with a 200ms timeout per address, a full bus scan takes ~50 seconds. At 19200 baud with a 100ms timeout, it's ~25 seconds.

Building a Device Registry

Discovery produces a mapping of:

{
  "ip_address": "192.168.1.100",
  "port": 502,
  "protocol": "modbus_tcp",
  "device_type": 1017,
  "serial_number": {
    "year": 24,
    "month": 6,
    "unit": 1042,
    "composite": 0x18060412
  },
  "discovered_at": "2026-03-01T01:00:00Z"
}

This registry becomes the source of truth for your IIoT platform. Key operations:

New Device Detected

A device at a new IP address or a new serial number on a known IP. Action: provision the device in the platform, assign a default tag configuration based on device type, and alert the plant engineer for review.

Device Replaced

Same IP address, different serial number. Action: archive the old device's data, provision the new device, and carry forward any custom tag configurations (since the replacement is usually the same model).

Device Missing

A previously discovered device no longer responds. Action: set the device's link state to "down" and begin retry probes at a lower frequency (e.g., every 60 seconds instead of continuous polling). After a configurable timeout (e.g., 30 minutes), alert maintenance.

Configuration Drift

The device type at a known IP address has changed. This usually means someone swapped the PLC for a different model without updating the configuration. This is a critical alert — the tag configuration is almost certainly wrong, and the data being collected is garbage.

Real-World Edge Cases

Dual-Protocol Devices

Some PLCs support both EtherNet/IP and Modbus TCP simultaneously. The discovery probe will succeed on the first protocol tried (EtherNet/IP, per our sequence) and may never test Modbus.

This is usually fine — use whichever protocol provides better access to the data you need. EtherNet/IP offers richer data typing (structured tags vs. raw registers), while Modbus is simpler and more universally supported.

NAT and Port Forwarding

In facilities where PLCs are behind a NAT gateway (common in multi-site deployments), the default ports may be remapped. Port 502 externally might route to port 502 on one PLC, while port 503 routes to a different PLC.

Discovery must support configurable port lists per IP range.

VLAN Segmentation

Modern factories segment OT and IT networks with VLANs. The discovery gateway must be on the correct VLAN to reach the PLCs. If your probe can reach the IP but gets no response, check VLAN routing before assuming the device is offline.

High-Availability PLCs

Some PLC configurations use redundant pairs with a shared virtual IP. Discovery might see the active controller's serial number, then after a failover, see the standby controller's serial number at the same IP. This looks like a "device replaced" event but isn't.

Handle this by checking the device type — if it matches and the serial numbers are in the same year/month range, it's likely a redundancy pair, not a replacement.

Security Considerations

Device discovery is essentially a network scan, and it has security implications:

1. Don't scan production networks without authorization. An aggressive scan can crash fragile PLCs or trigger IDS alerts.

2. Limit scan scope. Scan only the IP ranges and subnets that are expected to contain PLCs. Never scan the corporate IT network from the OT side.

3. Rate-limit probes. Don't send 100 connection attempts per second. One probe per second per target is sufficient and won't alarm network monitoring tools.

4. Log everything. Discovery probes are legitimate operational activity, but they look identical to reconnaissance attacks. Log your discovery runs with timestamps, source IPs, and results so security teams can distinguish them from threats.

5. Use read-only operations. Discovery should ONLY read registers, NEVER write. A stray write to the wrong register on a PLC can alter process parameters, open valves, or start motors. This is not theoretical — it has happened.

How machineCDN Handles Discovery

machineCDN's edge gateway includes built-in multi-protocol device discovery that probes EtherNet/IP and Modbus TCP endpoints automatically during commissioning. It maintains device type profiles with register maps for serial number extraction, supports both TCP and RTU variants, and automatically provisions discovered devices with appropriate tag configurations.

For large facilities with hundreds of PLCs, this eliminates the multi-week manual commissioning process and ensures every device is correctly identified and configured from day one.

---

Commissioning an IIoT deployment across multiple PLCs and protocols? See how machineCDN automates device discovery to get from installation to data in hours, not weeks.