Resolving WEFEH STOP on SIMATIC S5-155U CPU 948 During Block Status

The WEFEH stack message on a SIMATIC S5-155U CPU 948 indicates a collision between the hardware-clock-driven time interrupt (OB 33) and an in-progress CPU operation. When the collision is triggered specifically by the block status (Status) function in STEP 5 over a long CSF (Control System Flowchart) segment, the CPU drops into STOP with WEFEH reported on the programmer stack display. This article documents the failure mode, the underlying timing relationship between OB 10, OB 13–OB 18, OB 33 and the Status function, and the verified remediation path used on field machines.

1. WEFEH Error Definition and Stack Interpretation

The CPU 948 programmer interface reports WEFEH in the ISTACK (Interrupt Stack) when a request to start a time-driven interrupt coincides with a previously triggered OB that has not yet been acknowledged. The official CPU 948 reference manual (6ES5 998-3PR21, S5-155U CPU 948 Manual) classifies the condition as "Collision of timed interrupts caused by the hardware clock (OB 33)".

The German mnemonics map as follows:

WEFEH is therefore not a programming fault; it is a temporal scheduling conflict between the cyclic interrupt generator and an already-running interrupt. The CPU enters STOP because the user program cannot guarantee deterministic response to all interrupt classes simultaneously.

2. Why Block Status Triggers the Collision

The Block Status function in STEP 5 / S5-DOS / S5 for Windows samples the accumulator, status bit, RLO, AKKU 1/2 and the current operand value on every network it processes. To render a status trace across a long segment, the Status function executes the program in a tight handshake loop:

1. STEP 5 issues a single-step / force-status request to the CPU.
2. The CPU executes one network, captures register state, returns it.
3. STEP 5 displays the result.
4. STEP 5 issues the next request.
5. Loop until the segment is fully traced or the user aborts.

For a CSF segment whose graphic representation spans more than one screen (typically > 12–16 networks, or any segment containing a large DOC/SEG inline ladder), the host-to-CPU handshake can hold the interrupt-acknowledge window open for several hundred milliseconds. During that window, the hardware-clock-driven OB 33 generator continues to assert its trigger. When the CPU finally returns from Status, the pending OB 33 collides with the next scheduled OB 33 period, and the collision counter trips WEFEH.

3. Affected CPU Hardware and MLFB Revisions

The failure has been reproduced on both top-level S5-155U CPU 948 order numbers:

The 6ES5 948-3UA11 / 3UA12 distinction is largely memory-equipped versus memory-spare; the interrupt generator logic is the same silicon. Field experience indicates revisions at or above hardware status 4 are generally more tolerant because the interrupt-arbiter FIFO was widened, but the same combination of a fast OB 10 (≤ 10 ms) plus a long Status pass will still trip WEFEH on the highest-revision modules. The CPU 948 runtime data sheet (Siemens Support ID 4132283, CPU 948 – Runtimes of Data Handling Blocks) shows the arithmetic and data-handling block execution times that compound the Status window on heavily instrumented segments.

4. Root Cause: OB 10 at 10 ms on CPU 948

The most common cause is an OB 10 (time-of-day interrupt) or OB 13/14/15 (cyclic time interrupt) configured to a base period at or below 10 ms. On the CPU 948 the hardware clock that drives OB 33 has a fundamental period of 10 ms. Any user-configured OB whose phase aligns with OB 33 — and whose acknowledge window is held open by the Status handshake — will overflow the arbiter after one missed ack.

The failure recipe is therefore:

1. An OB (typically OB 10) is scheduled at a 10 ms base period.
2. A second interrupt class (OB 1 cyclic, OB 21/OB 22 restart, OB 33 hardware-clock) is running concurrently.
3. STEP 5 issues Block Status on a long CSF segment.
4. The Status handshake extends beyond 10 ms.
5. The hardware clock asserts a new OB 33 trigger before the previous one is acknowledged.
6. WEFEH is raised; the CPU switches to STOP.

For comparison, the standard interrupt classes on the S5-155U are summarised in the table below.

The CPU 948 manual (6ES5 998-3PR21) recommends a minimum configurable interrupt period of 100 ms for any OB that is expected to coexist with the Status function. The 10 ms period is legal, but the CPU 948 has no spare capacity margin to absorb a multi-hundred-millisecond blocking operation under that condition.

5. Diagnostic Procedure

Before any code change or hardware swap, confirm the ISTACK and reproduce the fault with a controlled sequence. The procedure below minimises risk to the running process.

5.1 Capture the ISTACK at the moment of STOP

1. Connect the programming device (PG) to the S5-155U via the AS511 / TTY or SINEC H1 port used in normal engineering access.
2. Launch STEP 5 (or S5 for Windows) and select PLC > ISTACK.
3. Read out the ISTACK. Verify the top entry is WEFEH and that the interrupt status byte (SAPA / SAPB / PAFE / STOZ / STEU) points to an OB class in the 31–38 range or to OB 33 specifically.
4. Note the interrupt stack nesting depth (EOP / EOFFSET) — values above 4 indicate the CPU was inside a deeply nested Status pass when the fault fired.

5.2 Cross-check the OB parameter block (DX 0)

1. Open DX 0 in the STEP 5 editor.
2. Record the configured base period for OB 10 (and OB 13–18, OB 31–38 if used).
3. Anything at or below T = 10 ms is the prime suspect.

5.3 Reproduce the fault deterministically

1. Bring the machine to a safe state (drive enable OFF, axes parked, E-STOP ready).
2. Switch the CPU to STOP/RUN with the test program loaded.
3. From STEP 5, open the affected FB/OB.
4. Select the longest CSF segment (the one that exceeds one screen).
5. Activate Block Status (F8 / hotkey depending on the STEP 5 build).
6. Observe the CPU status LED. The expected observation is a near-immediate transition to STOP with the red STOP LED latched, and WEFEH appearing in the ISTACK.

5.4 Verify the OB 33 period with an oscilloscope or SST

If the PG link supports it, dump the SST (System Status) and confirm OB 33 active and overdue counts. The 6ES5 998-3PR21 manual documents the relevant SST bytes (SST 14–17 for OB 33 activity).

6. Solution A: Lengthen the OB 10 / OB 13 Base Period

The first, least-invasive fix is to raise the cyclic interrupt period out of the 10 ms range.

6.1 Procedure

1. In DX 0, locate the OB 10 parameter field. Change the base period from 10 ms to 100 ms (or 250 ms if the application tolerates it).
2. If OB 13, OB 14 or OB 15 is also configured at 10 ms, raise them to ≥ 100 ms as well.
3. Reprogram the CPU: PLC > Transfer DX 0 to AG.
4. Cold restart (OB 20) or warm restart (OB 21) the CPU.
5. Re-run the Block Status reproduction (Step 5.3 above). WEFEH should no longer occur.

6.2 Example DX 0 parameter block (BEFORE / AFTER)

// DX 0 (BEFORE) - WEFEH-prone
KS = 'OB10PER'      // 8-char tag
KT = 10.0           // 10.0 ms - too fast for Status

// DX 0 (AFTER) - WEFEH-safe
KS = 'OB10PER'
KT = 100.0          // 100 ms - Status compatible

7. Solution B: Split Long CSF Segments

If the OB 10 period is fixed by the process, the next-best fix is to shorten the window the Status function needs. Break any CSF segment that exceeds one screen into two or more shorter segments.

7.1 Procedure

1. Identify every CSF segment in the active program whose printout or on-screen width exceeds 80 columns or 25 rows.
2. Inside the STEP 5 editor, place a segment delimiter (BEA / BE) at the natural mid-point of the offending segment.
3. Insert a comment segment header so engineers can still navigate the original logical block.
4. Re-assemble the FB / OB.
5. Transfer the block to the AG.
6. Verify with the Block Status reproduction. WEFEH should clear once all oversized segments are split.

7.2 Why this works

Status on a segment is bounded by segment length. A 6-network segment takes roughly 6 × 50 ms = 300 ms; a 3-network split takes 150 ms, well under the 10 ms OB 33 collision margin when OB 10 is at 100 ms. Splitting does not change the program logic, only the Status probe granularity.

8. Solution C: Reduce the Status Sampling Rate

STEP 5 supports a Status-Interval or Status-Count parameter that controls how often the host samples the CPU during a continuous Status pass. Increasing this interval reduces the handshake frequency and the window in which OB 33 can pile up.

8.1 Procedure

1. In STEP 5, open PLC > Status settings (path varies by STEP 5 version: S5-DOS, S5W, S5 for Windows).
2. Locate the Status interval / trigger field.
3. Change the value from the default (1 network per request) to multi-network mode, e.g. 4 or 8 networks per request.
4. Confirm the change and re-initiate the Block Status on the suspect segment.

This option is the least invasive for code, but it degrades the resolution of the live trace. Use it as a stopgap while you implement Solution A or B in parallel.

9. Solution D: Hardware Swap and Revision Considerations

If the application cannot tolerate any of the above, swap to a known-good CPU. Verify the following before reinstallation:

Re-seat the CPU in the same slot to keep addressing and CP assignment consistent. After power-up, perform an OB 20 cold restart and confirm the WEFEH class does not re-enter the ISTACK under the same Status workload.

10. Verification

After any of the four solutions, run the following validation sequence. None of these checks should be skipped: a CPU that boots cleanly once can still trip WEFEH on the third or fourth Status pass.

1. ISTACK clean boot. Power up, perform OB 20 cold restart. Read ISTACK: must show no WEFEH, no QVZ, no SPFEH entries.
2. Cycle test. Run the production program for 30 minutes with OB 10 active. Confirm ISTACK still clean.
3. Status reproduction. Perform the Block Status reproduction on every previously-failing segment, three times each. WEFEH must not appear.
4. Multi-engineer test. Have a second engineer simultaneously perform Status from a different PG on a different segment. The combined load should not regress to WEFEH.
5. Long-run soak. With multiple Status sessions over a four-hour window, confirm no latent WEFEH entries appear in the ISTACK history buffer.

11. Troubleshooting Matrix

12. Preventive Best Practices for S5-155U CPU 948 Programs

1. Default OB periods to 100 ms. Reserve 10 ms OBs for genuinely real-time control loops that have been benchmarked against the Status workload.
2. Cap CSF segments at 8 networks. Add this as a coding standard for the maintenance team. Long segments hurt readability anyway.
3. Document the OB configuration in DX 0. A comment field in DX 0 listing every active OB and its period allows the next engineer to see the constraint instantly.
4. Mark Status-sensitive blocks. Add a comment flag in the FB header (// STATUS-SAFE: N <= 8) so future edits do not inadvertently grow the segment.
5. Maintain a known-good spare CPU. For each MLFB variant on site, keep at least one Rev 05 board in electrostatic-bag storage with a verified battery.
6. Audit the rack for mixed revisions. Some fault combinations only appear when a Rev 04 and a Rev 01 board coexist in the same multi-processor rack.

13. Related Stack Messages and Cross-References

The WEFEH condition is sometimes confused with QVZ (cycle-time overflow). The decision tree is straightforward:

Refer to Siemens Support entry 4132283 for the data-handling block runtimes that influence the QVZ boundary, and the CPU 948 manual (6ES5 998-3PR21) for the official WEFEH definition and OB parameter reference.

14. Field Commissioning Checklist

1. Confirm OB 10 / OB 13 / OB 14 / OB 15 base periods in DX 0.
2. Audit each program block for CSF segments exceeding one screen.
3. Apply Solution A (raise OB period) unless process requires ≤ 10 ms.
4. Apply Solution B (split segments) on any block still failing Status.
5. Apply Solution C (lower status rate) as a last software resort.
6. Apply Solution D (hardware swap to Rev 05+) only if 1–3 do not resolve.
7. Run the four-hour soak with multi-engineer Status traffic.
8. Document final OB periods, segment counts, and CPU revision in the maintenance log.