An M580 IOScanner (Modbus TCP master) that keeps pairing the wrong unit ID with the wrong data block on an S7-1500 (slave) is being answered by a server that does not use the unit ID to select a data block. The fix is on the Siemens side: define one register map on the S7-1500 that contains both the write area and the read area. Then point one IOScanner device line at it with separate read and write ranges.
Symptoms of crossed unit IDs on one Modbus TCP link
The installation has separate read and write data blocks in the S7-1500. Two slave IDs were created to reach them, and the scanner appeared to attach the wrong ID to the wrong block. Use the table to decide which mechanism is active before changing anything.
| Observation | Likely cause | Check |
|---|---|---|
| Device line 1 and device line 2 return identical data | S7 server answers every unit ID from the same register map | Capture traffic; compare register payloads for unit ID 1 vs 2 |
| Writes from the scanner land in the read block, or the reverse | Two server instances or mappings share one connection definition, so the S7 cannot tell them apart | Compare connection parameters of each server instance in the S7 project |
| Data is shifted by one word | Wire addresses are 0-based; 4xxxx notation is 1-based | Write a known value to word 0 and locate it in the DB |
| No response, or exception replies, on one device line | Server rejects the unit ID or the address range falls outside the mapped area | Read the exception code in the capture; compare start address and length against the mapped area size |
Why the unit ID does not select a data block
A Modbus TCP frame starts with the MBAP header: transaction ID (2 bytes), protocol ID (2 bytes, value 0), length (2 bytes), and the unit identifier (1 byte). The function code and data follow. The unit identifier exists to reach serial slaves behind a TCP-to-serial gateway. A native TCP server is identified by IP address and TCP port, and many implementations either ignore the unit ID or accept a single value.
If the S7-1500 server ignores the field, the two IOScanner device lines with different IDs talk to the same register map. The result looks like swapped IDs, but the scanner sent the IDs correctly. Each server instance on the S7 side also terminates exactly one connection definition. Two instances sharing the same partner address and local port cannot be distinguished by unit ID. Read the help page of the Modbus server instruction in TIA Portal to see whether it evaluates the unit ID, and which DB access type and data type the holding-register area requires.
Procedure: one register map on the S7, one device line on the M580
- Size the S7 holding-register area to cover both directions. Place the write region (data the M580 writes) at the low offsets and the read region (data the M580 reads) after it. Do not let the two ranges overlap.
- Keep the existing separate read and write DBs if other logic depends on them. Add cyclic copy logic between them and the holding-register DB: write region to the write DB, read DB to the read region. This adds one scan of latency on each direction.
- Configure one Modbus server connection on the S7-1500: the M580 IP address as partner, the TCP port used by the scanner, and passive connection establishment. Confirm in the instruction help whether the S7 checks the unit ID, then set the same value in the scanner.
- In the M580 IOScanner, create one Modbus TCP device line for the S7-1500. Enter the IP address and the unit ID. Define the read range (start address, length) and the write range (start address, length) on that same line. Standard function codes are 3 (read holding registers) and 16 (write multiple registers).
- Set the address offset deliberately. The wire address is zero-based. If the S7 area begins at holding register 0, the scanner read or write start address is 0.
- If two separate S7 server instances are required, give each its own connection definition, distinct on the TCP side. Point each scanner device line at the matching endpoint. Do not use the unit ID as the routing key.
Verification checks with expected readings
- Ping the S7-1500 from a laptop on the same subnet. Expected: replies with no loss, and the server connection shows established after the scanner starts.
- Capture on a mirrored port with the Modbus/TCP dissector. Expected: every request carries the configured unit ID, function code 3 or 16, and the configured start address and quantity. Every response echoes the transaction ID and unit ID.
- Write a known value to scanner output word 0 (for example 1234). Expected: the value appears at the first mapped word of the S7 write DB and nowhere in the read DB.
- Change a value in the first word of the S7 read region. Expected: the same value appears at scanner input word 0 within a few scan cycles, and word 0 of the write region stays unchanged.
- Write distinct values to the first and last words of each region. Expected: they arrive at the first and last mapped words with no shift. This exposes length and offset errors.
- Read the device health status in the scanner. Expected: the device line reports healthy after start-up and stays healthy across several minutes of traffic.
- Unplug the Ethernet cable for a few seconds and reconnect. Expected: the health status drops and then recovers without power-cycling either CPU, and the S7 server connection re-establishes on its own.
Recurring pitfalls on M580-to-S7-1500 Modbus links
- Fixing it only in the scanner. Re-entering unit IDs on the M580 changes nothing if the S7 server maps both IDs to the same area. The correction is in the Siemens project.
- Overlapping ranges. A read range that overlaps the write range returns stale or self-written data, which looks like crossed blocks.
- Wrong DB access type. An area that the server instruction cannot address (access type or data type outside what the help page allows) produces exceptions or unchanged data. Check the instruction help.
- Word-order and offset assumptions. Modbus registers are 16-bit. 32-bit values and REAL values need a matching word order on both sides, and the 0-based vs 1-based offset must be settled before commissioning.
- Two server instances on one connection definition. The S7 cannot route between them, so responses come from whichever instance owns the connection.
FAQ
What happens if two Modbus TCP unit IDs point to different DBs on the same S7-1500 connection?
The S7-1500 cannot route by unit ID unless the program does it, so both requests are served from the same register map. The scanner then shows identical or swapped data. Merge both DBs into one mapped area with separate read and write offsets.
What happens if the M580 unit ID does not match what the S7 server expects?
Depending on how the server instruction treats the unit ID, the request is either ignored or answered with an error or no reply. The scanner then flags the device line as unhealthy. Read the instruction help for its unit ID behavior and enter the same value in the scanner line.
What happens if the read and write ranges overlap in the holding-register area?
The scanner writes data into words it also reads back, so the read side echoes the master's own output. Set non-overlapping start addresses and lengths on the S7 map and in the scanner line.
How do I confirm the map is correct after the change?
Write 1234 to scanner output word 0 and confirm it appears at the first mapped word of the S7 write DB. Then change the first word of the S7 read region and confirm the same value at scanner input word 0.