Resolving S7-300 Modbus TCP I/O Mapping Issues on 315-2 PN/DP

1. Problem Statement

An Siemens S7-300 CPU 315-2 PN/DP (firmware V3.2.3) is configured as a Modbus TCP server using a third-party Modbus/TCP library. A WinCC Flexible runtime acts as the Modbus TCP client. Communication succeeds: the client can read and write the Modbus-mapped data blocks (DB) on the PLC without protocol errors. However, the physical inputs and outputs of the S7-300 do not reflect the Modbus traffic, and the physical I/O does not write back into the Modbus data areas either.

Symptom summary:

• Modbus client writes a coil → the corresponding bit in DB14 changes, but the LED on the digital output module does not change state and the load does not energize.
• Modbus client reads a discrete input → the corresponding bit in DB15 always returns the value last written by the program, not the actual level on the digital input module.
• Modbus client reads an input register → the word in DB13 returns the application value, not the converted value of the analog input module.
• No protocol errors are generated. Save_Done_NDR is TRUE, Save_STATUS_MODBUS = 16#A090, Save_STATUS_CONN = 16#A100 / 16#7002, Count_Error stays at zero.

The behavior described is a classic S7-300 Modbus data-routing problem, not a protocol problem.

2. Environment and Configuration

The relevant hardware and software stack for this case is:

Modbus data area mapping declared in the example project (kept by the user, addresses re-mapped to the actual slot addresses of the project):

The mapping in the table is declarative only. The IT4Industry Modbus/TCP FB does not perform any implicit move between the S7 process image and the Modbus data block; it only reads and writes the DB. The user must populate the data exchange in user code.

3. Root Cause Analysis

The MODBUSPN FB (FB102) implements a Modbus TCP server that is decoupled from the S7 process image. It exchanges a data image that the integrator must keep in step with the real I/O. When the program is written as a "DB-only" implementation, the Modbus traffic stays inside the DB and never reaches the periphery. This is the exact situation visible in the symptom list.

Three architectural facts have to be respected to make the link work:

1. Digital outputs (coils) must be written to the process image of outputs, not just to a DB. The simplest path is to copy the relevant word(s) of DB14 to the peripheral output area (e.g. QB4) in OB1, or to PQW addresses if a module is configured outside the process image.
2. Digital inputs (discrete inputs) must be read from the process image of inputs, not from a DB. The bit that the client reads for "input 0" must be the current value of I0.0, not a static bit in DB15. The user has to copy the process image into the DB before the FB executes, or the FB has to be configured with the input I-address as the data source.
3. Analog input registers (input registers) must be read from the peripheral input area, not from a DB. For an SM 331 placed at the slot of PEW 288, the AI conversion value is refreshed by the module every basic cycle and is read using L PEW 288 / T DBW .... Analog outputs (holding registers intended for outputs) must be written with L DBW ... / T PQW ....

The status values observed in the project confirm the protocol layer is healthy and point the diagnostic away from communication and towards the I/O glue logic:

Because the counters Count_Done and Count_Error behave correctly, the TCP link on port 502 is open and the FB is replying. The bug is therefore not on the network, the firewall or the FB itself — it is in the data glue between the DB and the process image.

4. Diagnostic Procedure

Use the following sequence to confirm the data glue is the problem and to gather the values you need to fix it.

1. Open the VAT "Modbus_Status" online and force the following tags to TRUE for one OB1 cycle after the client writes a coil:
   • Save_Done_NDR — latches TRUE when a request was processed without error.
   • Save_Error — latches TRUE if a Modbus exception occurred; pair with Save_STATUS_MODBUS in the same cycle.
2. Watch Count_Done and Count_Error. A rising Count_Done with steady Count_Error confirms that the client request is reaching the FB. If Count_Done is steady, the problem is on the network side (firewall, IP, port 502 closed, wrong PN interface selected).
3. Open the cross-reference for DB14 / DB15 / DB13 in STEP 7 (V5.5: Options → Reference Data → Display). Verify that each DB has at least one "W" access from OB1 (or another OB) that touches the I/O area. If the cross-reference shows only the FB102 access, the DB is isolated and the bug is confirmed.
4. Open HW Config and write down the actual I-addresses of the DI, DO and AI modules. The slot and the I-address can be edited independently; the I-address is what the user program uses.
5. Check the OB1 scan time and the process image partition in HW Config (object properties of the CPU → "Cycle/Clock Memory" tab). The OB1 PAE/PAA refresh is what makes the inputs read by FB102 reflect the real world.
6. Verify the Modbus client configuration in WinCC Flexible: the "PLC address" on each tag must equal the bit / word offset the FB is set to use, not the slot address of the module. With the mapping table in section 2, the discrete input "0" is DB15.DBX0.0 — in WinCC it must be addressed as 0x0001 (bit 0 of word 0), and not as "I0.0".

5. Solution: Wire the DB to the Process Image

There are three equivalent ways to keep the IT4Industry Modbus/TCP data block in step with the real I/O. Pick one and document it in the OB1 cycle to keep the timing deterministic.

5.1 Option A — Direct I/O moves in OB1 (simplest)

Add the following STL to OB1 before the FB102 call (network 1) to refresh the DB from the periphery, and the following lines after the FB102 call (network 3) to push the DB back to the periphery. The I/O addresses come from HW Config; the DB offsets come from the FB102 configuration dialog.

// --- Network 1: refresh DB15 (discrete inputs) and DB13 (input registers) ---
L     IB 0
T     DB15.DBB 0          // first byte of discrete inputs
L     IB 1
T     DB15.DBB 1
L     IB 2
T     DB15.DBB 2
L     IB 3
T     DB15.DBB 3

L     PEW 288             // AI0 raw value, refreshed every OB1 cycle
T     DB13.DBW 120        // matches the word 0x120 declared in the example
L     PEW 290
T     DB13.DBW 122
L     PEW 292
T     DB13.DBW 124
L     PEW 294
T     DB13.DBW 126
L     PEW 296
T     DB13.DBW 128
L     PEW 298
T     DB13.DBW 130
L     PEW 300
T     DB13.DBW 132
L     PEW 302
T     DB13.DBW 134

// --- Network 2: FB102 (MODBUSPN) call ---
CALL  FB102, DB102
   ... // parameters as in the example

// --- Network 3: write DB14 (coils) back to the DO process image ---
L     DB14.DBD 2           // bits 32..63 = word 2 and word 3 of DB14
T     QD 4

This pattern guarantees that the FB102 sees the freshest input image and that the coil writes from the client land in the PAE on the very same OB1 cycle.

5.2 Option B — SFC14 / SFC15 (DPRD_DAT / DPWR_DAT) for consistent data

If the I/O is on a DP slave or PN device rather than the local rack, the process image is updated by SFC14 / SFC15 (consistent reading and writing of a DP / PROFINET slot). The pattern is:

// Read 4 bytes of DI from a DP slave at logical address 0
CALL SFC 14   // DPRD_DAT
   LADDR    := W#16#0
   RET_VAL  := MW 100
   RECORD   := P#DB15.DBX0.0 BYTE 4

// Write 4 bytes of DO to a DP slave at logical address 4
CALL SFC 15   // DPWR_DAT
   LADDR    := W#16#4
   RECORD   := P#DB14.DBX2.0 BYTE 4   // word 2..3 of DB14 = coils 32..63
   RET_VAL  := MW 102

SFC14 / SFC15 give a consistent snapshot regardless of OB1 scan jitter, which is the recommended pattern for S7-300 / S7-400 Modbus-to-DP bridging.

5.3 Option C — Reconfigure the FB102 data pointer

If the FB exposes a DATA_PTR or AREA_PTR input (some library versions do), point it directly at the process image. Example:

// FB102 input "AREA_PTR" := P#I 0.0 BYTE 4   // discrete inputs
// FB102 input "AREA_PTR_OUT" := P#Q 4.0 BYTE 4 // coils

This avoids the user code but ties the Modbus area 1:1 to the slot addresses of the I/O modules. The FB then does not need DB15/DB14 for those areas at all.

6. Solution: Correct the WinCC Flexible Modbus Address Mapping

The WinCC Flexible side also has to be corrected. The HMI never sees the slot addresses directly; it only sees the bits/words in the Modbus data block. A coil that the integrator wants to be Q4.0 must be addressed as the coil number that points to DB14.DBX32.0. With the example project default (coils start at 0x0020 in the FB), Q4.0 is the first coil and Q7.7 is the last one. The corresponding WinCC tag table is therefore:

Because Modbus is 1-based for register references but 0-based for bit references, the conversion to the S7 word offset is: word_index_in_DB = (Modbus_address − 1) for registers, bit_index_in_DB = Modbus_address − 1 for coils and discrete inputs. Any mismatch here produces the "data in DB, no reaction on the wire" symptom.

7. Verification

1. Coil write test: From the WinCC Flexible screen, toggle DO_bit_00. The LED on the 6ES7322-1BL00 module at the corresponding terminal must change state within one OB1 cycle. Save_Done_NDR latches TRUE; Count_Done increments.
2. Coil read-back test: With the output forced to TRUE (e.g. bridging the output terminal to 24 V or commanding the output via STEP 7 variable table), the client must read TRUE. This confirms the write is leaving the PLC, not just the DB.
3. Discrete input test: Apply 24 V to the first input terminal. DB15.DBX0.0 in the VAT must be TRUE; the HMI tag DI_bit_00 must read TRUE. If the value is always FALSE, the OB1 move IB0 → DB15.DBB0 is missing or the I-address in HW Config is wrong.
4. Analog input test: Apply 10 V to the first AI channel. The word at PEW288 must show the corresponding 16-bit value (27648 at full scale for a ±10 V input). DB13.DBW120 must mirror it; the HMI tag AI_word_00 must read the same value.
5. Error counter test: Disconnect the PC Ethernet cable. EstdConn must go FALSE; STATUS_CONN must switch to 16#7002. Reconnect within 60 s: EstdConn must return to TRUE; Count_Done resumes; Count_Error remains at its previous value (no spurious exceptions).
6. Watchdog sanity: With a 100 ms periodic client poll, OB1 scan time must stay under 50 ms to avoid the typical Modbus timeout. Use OB1_PREV_CYCLE to log the worst-case scan time in a DB.

8. Status and Exception Code Reference

Use the following compact table as a decoding aid when reading the saved STATUS_MODBUS / STATUS_CONN values in a VAT. The 16#A090 / 16#A100 / 16#7002 codes observed in the project are all non-error, but the surrounding codes are commonly triggered by mis-mapping the FB data pointer.

9. Common Side Issues and Field-Proven Caveats

• Trial license on the IT4Industry FB. The trial runs for a limited time and may degrade to a single connection. Plan a license purchase or migrate to the Siemens Modbus/TCP library part of the Modbus/TCP PN CPU package.
• Process image size. By default the S7-300 process image is 128 bytes for inputs and 128 bytes for outputs. Analog input modules often sit above 128. If the AI is outside the process image, OB1 will not refresh the I-address; the program must use L PEW 288 directly. This is exactly the case here (AI at 288…303).
• WinCC Flexible and the S7 driver. WinCC Flexible can use a "SIMATIC S7" channel to the S7-300 or a "Modbus TCP" channel. They are mutually exclusive on the same tag. The integrator must pick the Modbus TCP channel to be consistent with the FB and the FB's Coil/Register offsets.
• Endianness on the analog registers. Modbus TCP is big-endian on the wire; the IT4Industry library expects S7 INT/REAL layout (little-endian on the wire). The library handles the byte swap, but custom bit-packed coil data in FC15 (Write Multiple Coils) does not — keep coil quantities at multiples of 8 and at multiples of 16 words for register data.
• Cyclic vs. on-change polling. Coils are best polled cyclically; analog input registers can be polled on change only. In WinCC Flexible this means "Acquire: cyclic continuous" for the coils and "Acquire: on change" for the AI tags, with a non-zero limit to avoid losing transitions.
• Time-of-day, scan time and request rate. The IT4Industry trial FB processes one request per OB1 cycle. If the client bursts 30 requests/s with a 200 ms OB1, 5 of them will be dropped and counted as "no response". The Modbus client must be configured to limit the request rate to 1 per OB1 cycle, or the OB1 cycle time must be brought down.

10. Preventive Checklist for Future Projects

1. Lock the Modbus ↔ S7 mapping in a single OB1 network pair (refresh-in / push-out) and place it in the project standards. Document the DB offset for every coil and register.
2. Reserve a VAT with the four "Save_…" tags so that every support call can copy the values into a single email and start the diagnosis in five minutes.
3. Configure the WinCC Flexible Modbus driver with the same "Base offset" as the FB. Most communication failures on S7-300 are an off-by-one in the register base.
4. Use SFC14 / SFC15 for every DP/PN slave that holds more than 4 bytes of consistent I/O. Direct PAB/PAW access does not give a consistent image and can produce "bit flips" inside one 16-bit coil group.
5. On the PC side, open TCP/502 inbound in Windows Firewall (or any third-party firewall) and document the exception in the commissioning report. A closed port 502 is the single most common cause of "client sees the CPU, FB counters stay flat".
6. Schedule the OB1 cycle time budget in HW Config and set a cyclic interrupt (OB35) to poll the analog input module if the I/O is critical. The OB35 should be prioritized above OB1 for input refresh and below OB1 for output drive, otherwise a slow OB1 will gate the entire Modbus server.