Troubleshooting Siemens S5-115U ISTACK Stop Errors in PG2000

Overview: S5-115U ISTACK Stop Conditions

The ISTACK (Interrupt Stack) is the diagnostic heart of the Siemens SIMATIC S5-115U programmable controller. When the CPU transitions from RUN to STOP, the operating system copies the current stack state, accumulator contents, and a coded stop reason into the ISTACK buffer, which is preserved across power cycles when the lithium backup battery is healthy. Reading this buffer with PG2000 PLC V5.1 is the first action any service engineer should take on a stopped S5-115U.

A classic field failure pattern matches the symptoms reported on the S5-115U: the program executes correctly in Manual mode but transitions to STOP immediately when the operator selects Automatic. The ISTACK shows BATPUF, STOPZUS, STOANZ, and ASPNEP set, while the BSTACK is empty. The combination of empty BSTACK and ISTACK active is diagnostic: the operating system has not been interrupted mid-block (which would populate the BSTACK), but rather an Organization Block (OB) error handler has fired, executed a STOP statement, and brought the CPU down without leaving a normal call stack behind.

ISTACK Bit Definitions for the S5-115U

The S5-115U ISTACK is structured as a multi-page diagnostic display. Each page contains status bits, accumulator images, and the address that triggered the stop. The following bit names are decoded as they appear on a PG2000 PLC V5.1 online session.

BSTACK Interpretation on the S5-115U

The BSTACK (Block Stack) records the call hierarchy of program blocks (FB/PB/SB/DB) at the moment a stop or error occurred. PG2000 displays the stack as a list of block numbers with their associated DBs and return addresses.

An empty BSTACK with an active ISTACK is significant. It means the CPU was not executing a user block when it stopped. This rules out typical in-program faults such as:

• Division by zero in a calculation FB
• Access to a non-existent DB (DB not loaded)
• Periphery access to an I/O slot that has no module installed
• Timeout in a timer/counter FB with a zero preset

What it points to is an OB-level error handler that has been triggered, executed, and stopped the CPU before any application block was re-entered. The OB itself is the block you must open and inspect.

Common Stop Causes on the S5-115U

The S5-115U operating system calls specific Organization Blocks in response to fault conditions. Each of these OBs, if programmed with an STP statement, will halt the CPU the moment the fault occurs.

Accessing the ISTACK in PG2000 PLC V5.1

PG2000 PLC V5.1 is the on-line test front-end for the S5-115U and the rest of the SIMATIC S5 family. Use the following sequence to display the diagnostic information:

1. Connect the PG to the S5-115U via the MPI/AS511 port (serial) and power on the programmer.
2. From the project navigator, select PLC > Connect Online Target System.
3. Confirm the connection by reading the CPU status; the CPU should report STOP with ISTACK.
4. Open PLC > Diagnosis > ISTACK (the menu path may appear as Test Functions > Stack Display in localized versions).
5. Page through all ISTACK screens with PgDn / PgUp. Capture every screen, including the page that lists the active OB and the page showing accumulator and status word.
6. Open PLC > Diagnosis > BSTACK and record the block list. In this failure mode the BSTACK is normally empty, but capturing it confirms that no user block was interrupted.

Make a hard copy (PG2000 supports printing the screen with Shift+Print) and archive the ISTACK pages. They are the only forensic record of the failure once the CPU is restarted.

Locating the Faulty Organization Block

The ISTACK pointer identifies which OB was active when the stop was issued. With that OB known, apply the following systematic procedure to confirm the cause.

1. Open the OB indicated by the ISTACK pointer in PG2000 (OB19, OB23, OB24, or whichever the ISTACK reports).
2. Search for the literal STP statement. In STEP 5 / PG2000 this is the assembly equivalent of "Stop Program" and is the only instruction that issues a software stop from within an OB. Search with the editor's Find function for the three-letter string STP.
3. Comment the STP out by replacing it with a no-op such as NOP 0. If you are working on the EPROM submodule (ASPNEP set), you cannot do this on-line; see the EPROM handling section below.
4. Transfer the change to the CPU and place the CPU in RUN. If the CPU stays in RUN for at least one full OB1 cycle, the OB you just modified is the source of the stop.
5. If the CPU still stops, the ISTACK will now show a different active OB. Repeat the procedure from step 1 on the new OB.
6. If the CPU no longer stops, restore the original NOP 0 lines one at a time, restarting the CPU after each change, to confirm the original stop trigger. Once confirmed, the original STP can either be left as NOP 0 (with a maintenance note in the program header) or replaced with a controlled fault-handling routine such as setting a flag and continuing.

Handling the EPROM Submodule (ASPNEP)

The ASPNEP bit is set whenever the user memory is an EPROM submodule (the classic plug-in memory card on the S5-115U front panel). This has direct consequences for the diagnostic workflow:

• On-line editing is rejected. PG2000 will not transfer program changes to an EPROM. The Modify, Transfer, and Block Delete functions are disabled when ASPNEP is active.
• UV erase is required. The EPROM must be physically removed from the CPU, erased under a UV eraser (typically 20–30 minutes), and re-burned with an EPROM programmer before it can be re-installed.
• RAM fallback. If the CPU has internal RAM (most S5-115U CPUs do, in addition to the submodule slot), the on-line edit can be performed against RAM by leaving the EPROM submodule out. The next cold restart will then load from RAM, allowing diagnostic edits. Always verify the CPU variant supports this; some lower-tier CPUs (e.g., CPU 941 in early revisions) require a submodule to boot at all.
• Battery interaction. With ASPNEP set, the lithium backup battery is no longer needed for the user program. BATPUF is still relevant for the internal flags, timers, and counters. Removing the battery will not affect the program code on the EPROM but will reset all retentive flags.

Why Manual Mode Runs but Automatic Mode Stops

The reported behaviour — the program runs in manual mode but stops the moment automatic mode is selected — almost always points to one of three root causes:

Verification and Restart Procedure

After the offending OB is identified and the cause is resolved, perform the following verification sequence before returning the machine to production:

1. Power-cycle the CPU with the selector in STOP to clear the ISTACK.
2. Set the selector to RUN with no program executing. The CPU should remain in RUN (or transition to RUN after a clean cold restart on a CPU that does so automatically).
3. Select Manual on the operator panel and run a full manual cycle. Confirm no stop.
4. Select Automatic and run a full automatic cycle. Confirm no stop. Repeat the cycle at least three times to rule out an intermittent trigger.
5. Re-read the ISTACK in PG2000 after the test runs. It should show a clean state with no STOPZUS set.
6. Save the modified program to the project file and to the EPROM submodule (if ASPNEP was the working environment). Label the EPROM with the program name, version, and date.
7. Document the ISTACK pages, the OB that was modified, the change made, and the test results in the machine's maintenance log.

Preventive Recommendations

• Never leave a hard-coded STP in an error OB without a comment block explaining the failure mode it protects against.
• Replace battery proactively — lithium batteries on the S5-115U have a typical service life of 5 years. A weak battery will appear as BATPUF momentarily clear and re-set, often producing confusing ISTACK states.
• Keep a printed copy of the ISTACK bit definitions for the specific CPU revision mounted on the inside of the cabinet door. Field engineers will find this faster than the manual during a night shift stop.
• For EPROM-based CPUs, maintain a programming workstation (PG with EPROM eraser and burner) on site. EPROM handling is the single most common cause of extended downtime on legacy S5-115U systems.