Resolving Intermittent S5 to WinCC Tag Communication Failures

Architecture Overview: S5 to WinCC over Industrial Ethernet

SIMATIC S5 controllers (S5-90U, S5-95U, S5-100U, S5-115U, S5-130W, S5-135U, S5-150U, S5-155U) communicate with SIMATIC WinCC V5.x / V6.x / V7.x through the SIMATIC NET communications processors CP 1413 (10 Mbit/s Ethernet, AUI/BNC) or CP 1430 (10/100 Mbit/s Ethernet, RJ45). The CP module plugs into the S5 rack and presents a TCP/IP socket to WinCC; on the PLC side it exchanges data with the CPU through the S5 backplane using dual-port RAM.

WinCC acts as the active partner: it opens the connection, issues Fetch/Write requests, and closes the session. The S5 CP and its associated FBs are passive: they answer the request via an RK512-like frame that includes the source data type (DB, IB/PB, QB/PAB, FY/Flag), the start address, and the length. The maximum payload per Fetch request is 255 bytes from a single memory area; WinCC consolidates adjacent tags into packed reads to reduce request count.

The PLC never initiates traffic on this link; the FB SYNCHRON, FB SEND, and FB RECEIVE blocks only service requests that WinCC has placed in the CP's mailbox. This single-direction traffic pattern is the root of most of the issues encountered in the field, because the FBs must be cyclically serviced in OB1 or the mailbox fills and tag values freeze or return stale data.

Hardware and Software Prerequisites

Verify the CP firmware matches the COM tool revision. Mismatches between CP 1430 firmware (e.g. V3.x, V4.x, V5.x) and COM 1430 V5.x manifest as connection establishment failures (SF LED lit on the CP) rather than intermittent data errors. The CP 1413 ships with firmware 3.x; CP 1430 with firmware 1.x through 5.x. Documented firmware upgrade procedures are bundled with the COM tool.

Required STEP 5 Function Blocks

Three FBs are mandatory on the S5 side, regardless of whether WinCC is doing Fetch/Write or whether the S5 is exchanging data with another PLC via SEND/RECEIVE:

OB20 (manual restart), OB21 (manual restart with memory reset), and OB22 (automatic restart) are the three restart OBs in S5. Calling FB SYNCHRON from one of these ensures the CP dual-port RAM is in a defined state before OB1 starts scanning FB 120 / FB 121 / FB 126 / FB 127.

RLO / VKE Handling Before Block Calls

VKE (Verknüpfungsergebnis) is the German acronym for RLO, the Result of Logic Operation in STEP 5. The status bit VKE/RLO determines whether an FB call is conditional (executed only when RLO = 1) or unconditional (executed regardless).

Use either:

*  Direct unconditional call (preferred for the ALL blocks)
      JU   FB 126        * SEND-ALL  (RLO forced to 1 internally by JU)
      JU   FB 127        * RECEIVE-ALL

*  Conditional call with explicit RLO = 1 (also valid)
      O    M  199.0      * OR a flag that is TRUE
      ON   M  199.0      * OR-NOT same flag  ->  RLO = 1
      JC   FB 120        * call SEND only if RLO = 1
      O    M  199.0
      ON   M  199.0
      JC   FB 121        * call RECEIVE only if RLO = 1

The pattern O Mx.y / ON Mx.y is a classic STEP 5 idiom that produces RLO = 1 regardless of the actual bit state, because OR and OR-NOT of the same operand always yield 1. The unconditional JU is functionally equivalent and clearer in modern code reviews, but the JC idiom survives in legacy STEP 5 listings.

Audit your OB1 for any of the following: FB 126 or FB 127 called with a real condition flag, FB 120 / FB 121 called inside a sub-FB whose entry condition depends on process state, or FB calls placed after an early BEA (block end absolute) due to a fault path. All of these defeat the cyclic servicing the CP needs.

SEND-ALL / RECEIVE-ALL vs Single SEND / RECEIVE

FB 126 is parameterised internally as FB 120 with Auftragsnummer (A-NR, job number) = 0,0. FB 127 is FB 121 with A-NR = 0,0. The job number zero is a wildcard that means "process all configured jobs".

Indirect parameterisation: FB 126 / FB 127 can read their interface values from a DB if the call site supplies a DB pointer in the formal parameters. A common pattern is the ALL FB listing zero defaults that are then overwritten from a configured parameter DB. Inspect the actual FB call list in your STEP 5 listing to determine whether defaults or DB-driven values apply.

WinCC Active / PLC Passive Configuration

In the WinCC S5 Ethernet channel, set the connection type to Active. WinCC will then open the TCP connection, send Fetch and Write telegrams, and close on shutdown. The CP 1430 never dials out.

For a pure WinCC HMI station you do not need FB 125 (FETCH) on the S5; FB 120 and FB 121 (or FB 126 / FB 127) are sufficient. Fetch is only required when the S5 is the active partner pulling data from another PLC.

Typical WinCC-side configuration parameters:

WinCC Tag Packing Mechanism

WinCC implements a request-packing layer on top of the Fetch primitive. For SIMATIC S7 this is documented in the WinCC Information System under Communication > SIMATIC S7 Protocol Suite > Read/Write optimisation; the S5 channel uses the same optimiser and the same rules.

Packing rules:

1. Tags belonging to the same data area (DB, I, Q, F, M) and contiguous address range are merged into a single Fetch request.
2. Tags using the same WinCC update cycle are grouped together; if two tags share both area and cycle, they are guaranteed to be packed.
3. A non-contiguous tag forces a separate Fetch. Example: DB100.DW0 and DB100.DW10 on a 2-byte word tag both read as 12 contiguous bytes (DW0, DW2, DW4, ..., DW10). Example: DB100.DW0 and DB100.DBX5 do not pack and cause two requests.
4. A Fetch request can read at most 255 bytes from a single area; the optimiser splits larger spans automatically.
5. Bit-level tags (DBX, I, Q) are packed to the enclosing byte: requesting DB30.D0.0 and DB30.D0.4 reads a single byte, not two bit requests.

Consequence: mixing tags from many different DBs, areas, and update cycles defeats the optimiser. Each combination spawns a separate Fetch telegrams, the CP mailbox backs up, and intermittent read failures appear at the HMI.

Data Block Consolidation for Performance

The fastest configuration is one in which all HMI-bound tags live in a single mirror DB (for example, DB 30) and the WinCC channel reads from that DB only. The PLC application code updates DB 30 every cycle with the current snapshot of the relevant process state, including:

• Hardware input snapshots copied from IB x (PIA image) at the start of OB1.
• Output mirror flags copied from QB y.
• Flag-byte snapshots copied from FY z.
• Computed process values from flags, timers, counters, and arithmetic results.

This pattern produces one large Fetch per update cycle, fits well under the 255-byte limit, and isolates the HMI from raw hardware-address access. Raw I, Q, and F reads from WinCC are valid (the CP services them through RK512 type codes) but are slower and more difficult to audit.

Common Failure Modes and Diagnostics

Online Diagnostic Procedure with COM 1413 / COM 1430

1. Connect a PG to the CP's PG (AS511) port. Not every serial-to-USB converter supplies the voltages the CP expects on the AS511 pins; use a Siemens PG cable or a documented industrial converter.
2. Start COM 1413 (for CP 1413) or COM 1430 (for CP 1430) and select Online > Load from CP to retrieve the active job table.
3. Inspect each job's A-NR, source DB, target DB, partner, and current status word. The status word reports per-job error codes such as 0x0001 (job busy), 0x0002 (job complete), 0x8001 (partner not reachable), 0x8002 (length error), 0x8004 (no data available).
4. Use the CP's job monitor to watch live Fetch/Write activity. A heavy increase in CP load is expected when running COM online; do not leave the monitor active in production.
5. If a job is permanently in busy, the corresponding FB is not being called with RLO = 1. Fix the call site and re-verify.

Verification Procedure

1. In STEP 5, open the program file and confirm that FB SYNCHRON is called from OB20 / OB21 / OB22 and that FB 120, FB 121, FB 126, and FB 127 are all called from OB1 with RLO = 1.
2. In WinCC Explorer, open the S5 channel, list all tags, and sort by address range. Tags from the same data area and update cycle should be grouped.
3. Open the WinCC channel diagnostics (right-click connection > Connection status or System diagnostics). Confirm Connection established, Read/Write OK, and an acceptable Fetch count per cycle.
4. Force a known value in a tag's source address via STEP 5 variable status and confirm the WinCC tag updates within the configured cycle plus one PLC cycle.
5. Run the system for at least 30 minutes under normal process load and confirm zero connection drops, zero stale-value events, and CP SF LED off.

Safety and Lifecycle Notes

For long-life plants, lock down firmware revisions of both the CP and the COM tool, store the current STEP 5 program and WinCC project in a versioned repository, and document the FB call pattern in a commissioning report so that future maintenance engineers do not introduce the classic RLO = 0 regression.

FAQ