How to Fix Modbus TCP Reading the Wrong Device
Two tags that should read two separate devices show the same numbers, or a device's data suddenly looks like a neighbor's. The comms are healthy, every poll succeeds, but the values are coming from the wrong place. This is a routing problem, not a decode or a wiring one: something in the path from your SCADA to the physical device is crossing requests. This guide walks the causes in order of likelihood - shared unit IDs, a default IP, colliding serial addresses, and connection reuse - each with a test to confirm it and a fix.
Fix Modbus TCP reading wrong device in one line: Modbus TCP reading one device as another means two tags are routing to the same physical device because they share an identifier they should not. The usual causes, most likely first, are two tags with the same unit ID at a gateway, two devices with the same serial address behind one gateway, a wrong or duplicated IP address, and a gateway reusing one connection across devices. Diagnose by reading a device-unique value at each address and fixing whichever identifier is shared.
First Check: Read a Device-Unique Value
Confirm the crossover is real before hunting causes, because a coincidence of similar readings is not the same as crossed routing. Find a register that differs between the two devices - a serial number, a firmware version, a fixed configuration value, or a distinct live measurement - and read it from both tags. If both return the same device-unique value, the routing is genuinely crossed and both tags are hitting one physical device. If the unique values differ, the devices are distinct and your matching process values are just a coincidence, and this is not the fault to chase.
This device-unique read is the single most useful test in the whole procedure, because it converts a vague suspicion into a fact and it is also how you verify the eventual fix. Function code 43 device identification, where a device supports it, returns vendor and product strings that are ideal for this, described under a Modbus function code. Once you have confirmed two tags return one device's identity, you know the problem is in routing and can work the causes below in order.
Fix a Shared Unit ID at a Gateway
The most common cause is two tags configured with the same unit ID pointed at the same gateway IP, so both route to the same serial device. Check each tag's unit ID and confirm they differ and each matches its intended device's serial address. If both were left at a default of 1, both reach whatever sits at serial address 1, which is exactly the crossover you see. Setting the unit ID correctly per device is the core of resolving Modbus TCP unit-ID confusion at a gateway.
A subtler version is two devices behind the gateway that genuinely share the same serial slave address, so even distinct unit IDs cannot separate them if the gateway maps them the same way. Confirm from the gateway configuration which serial address each physical device holds; if two collide, re-address one device or use the gateway's remap to give each a unique virtual identifier, the mechanism under a Modbus gateway unit ID remap. The end state is that each device is reachable by a distinct unit ID that no other device shares.
Rule Out Duplicate or Wrong IP Addresses
On native Modbus TCP devices, where each has its own IP, a crossover usually means an IP problem. Two tags configured with the same IP obviously reach the same device, so check the IPs are distinct and correct. Less obviously, two physical devices accidentally set to the same IP address create a network conflict where whichever device answers first responds to both tags, and the data appears to jump between them. Verify each device holds the IP you think it does, and that no two devices share one.
A wrong IP that happens to belong to a real but different device is the trickiest form, because the poll succeeds and returns valid data - just from the wrong device. Cross-check each device's configured IP against the site's address plan, and use the device-unique read to confirm the IP you are polling really reaches the device you intend. The general shape of Modbus TCP addressing, where the IP identifies the device, is covered under Modbus TCP vs Modbus RTU.
Check Connection Reuse and Verify the Fix
Some gateways multiplex several devices over a single TCP connection, and a poorly behaved gateway or driver can occasionally return a reply on the wrong connection, delivering one device's data to another's tag. This shows as an intermittent crossover rather than a constant one - most polls are correct, but occasionally a value appears on the wrong tag. If the device-unique reads are usually right but sometimes swap, suspect connection handling in the gateway or a request-response mismatch, which overlaps with the connection problems under fixing a Modbus TCP connection reset by a gateway.
Whatever the cause, verify the fix with the same device-unique read that confirmed the problem: after correcting the shared identifier, each tag must return its own device's distinct value, consistently, over many cycles. Then watch the two tags in your SCADA through a real process change and confirm they move independently - if one device's reading rises while the other stays put, as physics dictates, the routing is genuinely separated. Two tags that finally show two different devices' data, cycle after cycle, is the completed fix.
Frequently Asked Questions
Why do two Modbus TCP tags show the same data?
They are routing to the same physical device. The most common reason is two tags sharing a unit ID at a gateway, so both reach the same serial slave; the next is two devices sharing a serial address behind one gateway, or two tags pointed at the same or a duplicated IP. Confirm by reading a device-unique register from both tags: if both return the same identity, the routing is crossed and you fix whichever identifier is shared.
How do I prove which physical device a Modbus tag is reading?
Read a register whose value is unique to that device - a serial number, firmware version, or a fixed configuration value - or use function code 43 device identification where supported. Compare that value against the device's known identity. This device-unique read both confirms a crossover exists and verifies the fix afterward, because after correcting the routing each tag must return its own device's distinct value.
Can a wrong IP address cause Modbus TCP to read a different device?
Yes. If a tag's configured IP belongs to a different but real device, the poll succeeds and returns valid data from the wrong device, with no error to warn you. Duplicate IPs on two physical devices cause a similar crossover where one device answers for both. Cross-check each configured IP against the site address plan and confirm with a device-unique read that the IP reaches the device you intend.
Sources and verification
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
- Modbus Application Protocol Specification - Modbus Organization
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.