Siemens S5-90U/95U Fault Diagnosis and Advanced Programming

Fault diagnosis and advanced programming practice of Siemens S5-90U/95U programmable controller

In the field of industrial automation, Siemens SIMATIC S5 series controllers have created an era with their durability and reliability. Although the S7 series has become mainstream nowadays, classic controllers such as S5-90U and S5-95U are still operating stably on numerous key production lines around the world. For engineers who maintain these 'old horses', mastering a system and efficient diagnostic and debugging methods is far more urgent than learning a new PLC. This article will delve into the internal world of S5-90U/95U, providing you with a comprehensive technical guide from hardware structure, diagnostic tools to advanced programming techniques.

1. System Overview: Performance Boundaries of Compact Controllers

S5-90U and S5-95U are compact controllers designed by Siemens to meet automation tasks in the mid to low performance range. Their biggest feature is modularity, scalability, and powerful functionality.

S5-90U: As an economical entry-level option, it comes with 10 digital inputs and 6 relay outputs, and can be expanded with up to 3 S5-100U bus lines (6 slots) through the IM 90 interface module. Its user program memory is 4KB, suitable for replacing traditional contactor and relay control systems.

S5-95U: With more powerful performance, it comes with 16 digital inputs, 16 digital outputs, 8 analog inputs (0-10V, 10 bit resolution), 1 analog output, 4 interrupt inputs, and 2 high-speed counter inputs (up to 5kHz). The user program memory is up to 16KB and supports up to 16 bus units (32 slots), which can handle more complex closed-loop control and communication tasks.

Understanding these hardware boundaries is the first step towards efficient diagnosis. For example, when the program cannot be loaded, the first thing to check is whether it is S5-90U but the program size exceeds 4KB, or if the compiled program has caused internal RAM overflow (the manual states that even if the STEP 5 program is less than 16KB, it may overflow after compilation, causing the STOP LED to flash).

2. Core diagnostic tools: Deep application of ISTACK and BSTACK

When a PLC unexpectedly enters STOP mode, the first reaction of most engineers is to reset or re download the program, but this often overlooks the root cause. The S5-90U/95U provides powerful internal analysis tools - Interrupt Stack (ISTACK) and Block Stack (BSTACK), which are the "black boxes" for troubleshooting.

ISTACK: The 'first witness' of the cause of the malfunction

ISTACK is a memory area inside the CPU used to store the cause of faults. When the PLC switches from RUN to STOP or fails to start, critical information will be recorded in ISTACK. By calling the ISTACK function through the programmer (PG), you can obtain the following decisive clues:

Control bit display: For example, ZYK bit indicates scan cycle timeout, NAU indicates central controller power failure, PEU indicates external I/O bus not ready, STUEB indicates block stack overflow (nested depth exceeding 16 layers).

Error ID (Cause of Interr.): This is the key to locating the issue.

NNN: The program cannot be interpreted. This is usually a 'compiler error', meaning that the STEP 5 statement you wrote has a syntax error or logic that cannot be converted by the compiler. At this point, REL-SAC (relative to STEP address counter) in ISTACK will point to the address after the error statement. You need to convert this hexadecimal address to decimal and then find the specific location in the corresponding block (such as PB7).

TRAF: Data transmission error. Common reasons include: the accessed data block (DB) is not opened or does not exist; The data word number specified in the program statement exceeds the length of the DB. For example, a DB defined as 10 words, but the program attempts to write the 11th word.

SUF: Replacement Error (S5-95U only). This usually occurs when the function block (FB) passes the wrong actual parameters when calling, or when an integrated FB is called in the interrupt program, and the FB is being processed by another program.

ZYK: Scan cycle timeout. The program execution time has exceeded the set monitoring time (default 300ms). Possible reasons may include dead loops in the program, frequent interrupts, or prolonged monitoring of STATUS through the programmer.

BSTACK: "Navigator" for program execution path

BSTACK records jump information during program execution, including which DB was open before the jump, the starting address of the called block, and so on. In structured programming, when errors occur within deeply nested blocks, BSTACK can clearly reveal how the program progressed step by step to the point of error.

For example, the system reports a TRAF error, indicating a DB access error. By examining BSTACK, you may find that the program execution path is: OB1->PB2->FB4, and when calling FB4, data block DB5 is open. This way, you can quickly lock in the statements accessing DB5 in FB4 instead of aimlessly searching throughout the entire program.

3. System Parameterization: The Clever Use and Pitfalls of DB1