SIMADYN D Task Administrator Error E Resolving PM5 Processor

1. Problem Overview: The "E" Fault on a Downcoiler Gap Control Rack

A Siemens SIMADYN D controller used in the downcoiler section of a flat steel plant produces a persistent Task Administrator Error on the 7-segment display of the PM5 processor in the Gap Control Rack (station designation VX011). The single-character code E lights one of four failure modes documented for the SIMADYN D operating system:

• Cycle error – A task cannot be processed within its configured sampling time.
• Task backup – A non-high-priority task is restarted because its deadline was missed.
• No free local buffer – The data buffer is exhausted; the task start is skipped.
• Software watchdog – The base sampling time is not processed for four consecutive cycles. The basic clock timer is reinitialized with the configured base sampling time and processing continues.

The fault is acknowledged by pressing S1 on the processor front panel, but it returns within seconds. The fault has been present for approximately two years without halting production, but eliminating it is necessary because the watchdog reset of the base clock corrupts deterministic timing on the gap-control loop that governs strip tension and interstand gap.

2. Hardware Context of the Affected Station

The affected SIMADYN D station is built from the standard Siemens module set used in rolling-mill applications. The relevant modules in VX011 are:

The station also communicates with an IBA process-data acquisition (PDA) PC. Two data paths exist:

1. VX011 PM5 ↔ CS22 ↔ master SIMADYN ↔ ICS1 ↔ IBA-PC – fiber-optic path.
2. VX011 CS7 ↔ IBA field link – used for direct signal requests via SD-request.

Both paths carry SER04B telegrams. SER04B is the cyclic serial driver function block inside the SIMADYN D library and is the primary source of background CPU load in this configuration.

3. Root Cause: Sustained Cyclic Task Overload

Connecting the PSL (Processor Status / Load) function block on the live system shows that the cyclic-task load percentages at the PM5 outputs Y1 and Y3 are above 150%. A cyclic-task load above 100% means the task cannot finish inside its configured sampling interval; the operating system marks each missed deadline and eventually trips the watchdog. This is the root cause of the recurring "E" fault.

The most common cause of T1/T3 overload in a rolling-mill SIMADYN D is the growth of the SER04B workload driven by the IBA PDA. Each additional analog signal requested by IBA increases the cyclic-task time by a known, linear amount.

4. SER04B Cyclic Load Formula and IBA Interaction

The cycle time required by a single SER04B instance in a SIMADYN D task is:

t_SER04B = (80 + n × 6) μs

where:

• 80 is the fixed overhead of the SER04B instance in microseconds.
• n is the number of analog values transmitted per cyclic frame.
• 6 μs is the incremental cost per analog value.

Example load values:

If the configured sampling time of the task that hosts SER04B is, for example, 10 ms and IBA requests 200 analog values, SER04B alone consumes 128% of that task – guaranteeing a cycle error. The same instance can sit comfortably in a 50 ms slow task even at 200 values.

5. IBA Communication Modes: SD-lite vs SD-request

IBA connects to SIMADYN D in one of two modes, and the diagnostic path differs:

The site in question uses an IBA system that connects through fiber optics via CS22 (rack-to-master) and ICS1 (master-to-IBA-PC). Because the load scales linearly with the number of analog values requested, this is the first place to look when the PSL block reports cyclic-task overflow.

6. Step-by-Step Diagnostic Procedure

Use this ordered checklist on a running PM5. All steps can be performed online without disturbing the process; only step 6 involves a configuration change.

1. Confirm the display fault. Read the 7-segment code on the PM5 front panel. E confirms a Task Administrator Error; the four sub-codes are not user-readable from the display alone and must be derived from the PSL block and SYF4 outputs.
2. Insert the PSL block into the live program. PSL reports the load of every cyclic task. Place one PSL instance per CPU. Record the values at Y1 through Y5 (T1 through T5) under normal production load.
3. Check the load thresholds. Any task with load > 100% will trip a cycle error. Tasks > 150% will trip the software watchdog within four cycles.
4. Identify the cyclic task hosting SER04B. Open the function-block list and locate every SER04B instance. Record the configured sampling time (the task in which each SER04B runs).
5. Count IBA-requested analog signals. In the IBA PDA project, list the analog channels sourced from VX011. Cross-check against the address-book entries (FP.FB.Connector) for SD-request, or the telegram definitions for SD-lite.
6. Calculate SER04B load. Apply t = (80 + n × 6) μs per instance. Compare to the configured sampling time. If the sum exceeds the sampling time, the task is overloaded.
7. Inspect SYF4 block outputs. Inside the @simd3 system function package, the SYF4 block exposes detailed task-status information, including the identity of the task that triggered the last watchdog event. Read its outputs while the "E" is active to localize the failure.
8. Decide mitigation path. Move SER04B to a slower task, reduce the analog count, raise the sampling time, or distribute load across stations (see Section 8).
9. Verify after change. Repeat step 2 and confirm all PSL outputs are < 80% under worst-case production load, with margin for transient peaks.

7. Locating the @simd3 System Function Package in STRUC G

The system function package @simd3 contains the SYF4 block needed to read detailed task-error information. On STRUC G installations, function packages have three file extensions:

• .CFP – source code (C-function package)
• .GFP – compiled binary (G-function package) loaded into the target
• .MFP – macro / metadata file

For @simd3, the file shipped with every project is typically @simd3.gfp. The full source @simd3.cfp is not required for routine diagnostics; the compiled GFP is loaded automatically when the CPU boots. The reference implementation is in the STRUC G demo project – copy @simd3.gfp from the demo project directory if it is missing from the active project. Once present, instantiate the SYF4 block in a low-priority task and read its outputs online to capture the failing task identifier.

8. Task Load Reduction Strategies

Apply the following measures, starting with the lowest-risk changes. Always re-measure PSL output after each change.

9. Configuration Adjustments: Sampling Time, Task Assignment, and SER04B LIM

Three concrete configuration changes are available without modifying function-block logic:

9.1 Raise the basic sampling time

Locate the @simd3 configuration in STRUC G and increase the value of the basic sampling time parameter (commonly T0 or TBASE depending on the STRUC G version). The watchdog reinitializes to the new value on the next fault. Trade-off: control loops in the same task lose bandwidth.

9.2 Shift SER04B to a slower task

In the function-block configuration panel of STRUC G, change the task assignment of the affected SER04B instances from T1 or T2 to T4 or T5. The monitoring refresh rate drops to match the slower task, but the gap-control loop in T1 is unaffected.

9.3 Use the SER04B LIM connector (SD-request mode)

SER04B exposes a special input connector named LIM (limit) that constrains the number of cyclic operations performed per scan. Setting LIM to a value lower than the IBA request count caps the cyclic load, at the cost of dropping the excess analog updates. This is the safest single change for an SD-request installation.

10. Active Monitoring Loads (IBA / IBS) Add CPU Cost

An active IBA or IBS monitor that is currently polling SIMADYN D adds CPU load beyond what is visible in the static program. Turning monitoring off did not change the fault in the field case because the configured cyclic load was already above 100%; however, when reducing analog count, expect additional margin once monitoring is re-enabled because each active monitor generates extra service traffic. Re-measure PSL outputs with monitoring active to capture the realistic production load.

11. Verification After Mitigation

Use this checklist to confirm the fault is eliminated:

1. PSL outputs Y1 through Y5 are all below 80% under full production load.
2. The 7-segment display does not show E for at least 72 hours of continuous production.
3. Gap-control performance is unchanged – strip tension and interstand gap remain within tolerance.
4. IBA PDA continues to capture all required analog signals at the requested refresh rate.
5. SYF4 outputs show no task-error flags during the 72-hour window.

12. Preventive Maintenance Recommendations

• Track PSL outputs during every STRUC G program change. A rising trend on T1 or T3 is an early warning of cyclic-task saturation.
• Maintain a documented list of IBA-requested analog channels per SIMADYN D station. Review whenever IBA scope is changed.
• Reserve at least 20% load margin on every cyclic task for transient peaks during mill acceleration and strip head threading.
• Keep a copy of @simd3.gfp from the STRUC G demo project in the project source tree so SYF4 diagnostics are always available.
• Avoid placing SER04B in the same task as time-critical control blocks (gap, tension, hydraulic position loops).
• Before any program modification, record the current PSL output to provide a baseline for comparison after the change.

13. Quick-Reference Troubleshooting Matrix

14. References in Authoritative Documentation

For the SIMADYN D assembly and programming methodology that underpins the procedures in this article, consult the Siemens industry support publication SIMADYN D System Manual (dyn_system_e.pdf). This document describes the programming entry path used by STRUC G, the function-block model (CFP / GFP / MFP), and the recommended load-margin conventions for cyclic tasks.