Fix S5 CPU 928B QVZ/ADF STOP: Read the ISTACK Fast

Problem Details

A SIMATIC S5 rack built around a CPU 928B (order number 6ES5928-3UB12) runs correctly for roughly two hours, then drops to STOP. The failure signature reported on the CPU front plate is:

• QVZ on the first trip, with BASP active (command output disable, all digital outputs forced to 0).
• After a manual reset/restart attempt, the CPU stops again but now with ADF on and BASP active.
• Intermittently, during otherwise normal operation, the fault LED on one 32-point digital output module lights for about a second.

Rack population, left to right:

The only communication partner is an OP (operator panel). Relevant history: the external 24 VDC supply feeding the input side failed and was repaired; the fault pattern began after that repair.

How to Read the ISTACK on a CPU 928B

The interrupt stack is dumped from the programming device (STEP 5 PG software, Test > STACKS > ISTACK) after the CPU has gone to STOP and before you power-cycle or overall-reset it. An overall reset destroys the evidence.

Work the dump in this order:

1. Read the STOP cause bits. These are the flagged control bits in the first ISTACK screen — for example STP-BEF (stop caused by an STP statement inside the user program), QVZ, ADF, NAU, ZYK, BAU. Multiple bits can be set if a subsequent error occurred during error handling.
2. Read the block identification. The ISTACK names the block that was executing (in this case PB 90) and the relative address (STEP address counter, SAC) of the statement.
3. Locate the offending statement. The reported relative address is normally the address of the next statement to be executed. So a dump showing relative address 0006 means you inspect the statement at relative address 0005 in PB 90 — that is the instruction that actually triggered the fault.
4. Read OP-REG. The operation register holds the machine-code word of the instruction being processed. In this fault the dump showed OP-REG: D9A4. Decode it against the STEP 5 machine-code list to confirm the operand type and the absolute byte address the CPU tried to reach.
5. Read the accumulators and the data block register if the failing statement is an indirect/indexed access — these reveal the computed pointer value that produced the illegal address.

To go from a relative address to source code, open PB 90 in STEP 5 in STL with address display. The addresses shown are word offsets from the block header, matching the ISTACK SAC directly.

Root Cause Analysis

Two candidate causes fit the evidence, and they are not mutually exclusive.

Candidate 1 — Faulty or non-responding I/O module

ADF with a fixed block/address pair (PB 90, relative address 0005/0006) means the statement at that point references a peripheral byte that the S5 bus does not acknowledge. Practical triggers:

• The module is fitted but its bus interface has failed, so it stops acknowledging after it warms up (explains the ~2 h delay).
• The 32 DO module whose fault LED flashes has an output driver in short-circuit/overload shutdown; the on-board protection trips, the module signals fault, and in the worst case stops acknowledging.
• The absolute byte address written in the program does not correspond to any fitted module — the two empty slots (slot 4 and slot 17) are a strong hint that addresses were shifted after a hardware change.

Cross-check whether the module identified by the ISTACK address is the same module that shows the flashing fault LED. If it is, you have a single-point failure and the diagnosis is closed.

Candidate 2 — Repaired 24 VDC supply still degraded

The failure started after the input-side 24 VDC supply failed and was repaired. A supply that broke down under overload commonly has a second damaged component that only misbehaves once the unit reaches thermal equilibrium. The chain is self-reinforcing:

1. An output short or overload draws excess current.
2. The repaired supply heats beyond design margin and its output sags or ripples.
3. Modules on the sagging rail stop acknowledging on the bus, or the CPU sees a bus timeout.
4. CPU goes to STOP with QVZ/ADF, BASP drops all outputs.

The two-hour delay is the classic signature of a thermal or electrolytic-capacitor-related defect rather than a logic bug.

Candidate 3 — Illegal absolute address in PB 90

The decoded operation register value D9A4 was interpreted as a bit access on byte 164 with bit number 9. Bit numbers in STEP 5 are only valid in the range 0-7, so a bit 9 reference is not a legal I/O bit and would be produced by a mis-typed absolute address, by a corrupted block, or by an indirect access computing an out-of-range pointer.

Diagnostic Procedure

1. Capture the ISTACK before anything else. Print or save both dumps (the QVZ trip and the ADF trip). Note block, relative address, OP-REG, and every set STOP cause bit.
2. Map the failing address to a slot. Build a table of slot vs. absolute byte address range from the actual rack, including the two empty slots. Verify the address in the ISTACK falls inside a range that is physically populated.
3. Verify PB 90 source. Open PB 90 in STL with addresses, read the statement at relative address 0005 and the two statements around it. Check for hard-coded absolute peripheral addressing (L PB, T PB, L PW, T PW, or bit operations on I/Q bytes) with a byte number that was valid before the hardware change but is not valid now.
4. Measure the 24 VDC rails under load, hot. Log the supply output for the full two-hour run — a handheld reading at power-up proves nothing. Look for voltage sag, ripple growth, or a rail that drifts as the enclosure warms. Compare against the module specifications for permissible input voltage range and ripple.
5. Chase the output fault LED. Identify the exact channel on the 32 DO module that flags. Disconnect the field wiring for that channel and run the machine. If the fault LED stops and the CPU survives past two hours, the defect is in the field wiring or the load, not the module.
6. Substitution test. Swap the suspect DO module with an identical spare, or move it to the known-good address range and re-address in the program. If the fault follows the module, replace it; if the fault stays with the slot, the problem is the backplane/bus or the supply feeding that slot.
7. Thermal check. With an IR thermometer, log the case temperature of the repaired supply and the suspect module at the 90-minute mark. A component running far above its neighbours identifies the failing part.

Corrective Actions

Verification

1. Clear the ISTACK (overall reset only after the dumps are saved), download the corrected program, and start the CPU.
2. Run the machine continuously for at least 4 hours — double the previously observed 2-hour time-to-failure — with the enclosure closed so thermal conditions are representative.
3. Log the 24 VDC rail at start, 1 h, 2 h and 4 h. Voltage and ripple must remain inside the module input specification for the whole run.
4. Confirm no module fault LED illuminates, even momentarily, during the run.
5. After the run, pull an ISTACK/BSTACK read while the CPU is still in RUN — the stacks should be empty of new entries.
6. Archive the corrected PB 90 and the slot-to-address map with the machine documentation so the next hardware change does not reintroduce the addressing error.

Preventive Notes

• Keep a printed slot/address map inside the enclosure door. Empty slots in an S5 rack are the most common source of later ADF faults after a module is added or moved.
• Fuse or individually protect output groups so a single field short trips a fuse rather than driving the shared 24 VDC supply into thermal failure.
• Prefer replacement over repair for switch-mode supplies feeding a PLC I/O rail. A partially repaired supply produces exactly this class of intermittent, temperature-dependent fault.
• Take an ISTACK dump every time the CPU stops, not just the first time. The QVZ dump and the ADF dump in this case carry different information; discarding either loses the fault chain.