S7-1500 1515T STOP on Maximum Program Cycle Time Exceeded (OB80)

S7-1500 1515T STOP on Maximum Program Cycle Time Exceeded (OB80)

Problem Description

The 1515T-2 PN CPU enters STOP mode intermittently and unpredictably. The diagnostic buffer reports Temporary CPU error: Maximum program cycle time exceeded with parameter value 6000 ms, followed by Time error, OB80 start requested, Time error (OB start event), and finally CPU changes to STOP mode (no OB processing). The application continues running for hours or days under the same logic, then trips to STOP without any code change, after the same OBs that were previously executing without error.

Normal measured cycle time before the trip is <50 ms. The trip occurs in cyclic OB1 at a routine that previously completed within its allocated time slice. No WHILE, FOR, or infinite loops exist in user code. The fault is triggered by an architectural issue in the interaction of cyclic OB1, time-driven OB3x, hardware OB4x, and the motion-control technology OBs (OB91/OB92) instantiated by the SIMATIC RotaryKnife v1.2.2 application.

This is a classic case of interrupt OB queue overflow under motion load, not a code bug. The first trip logs the OB80 start event; if no OB80 is present (or if OB80 itself overruns), the CPU transitions to STOP with the diagnostic event CPU changes to STOP mode (no OB processing).

Affected Hardware and Software Environment

Diagnostic Buffer Decoded

The buffer in the original fault contained the following sequential entries. The first two are generated by the S7-1500 firmware when the cyclic watchdog fires; the remaining entries describe the error-handling chain. The 6000 ms parameter is the configured cycle monitoring time, not the actual time exceeded. The actual time will be ≥ 6000 ms because that is the configured trip point.

The discrepancy between the <50 ms nominal cycle and the 6000 ms actual time is the diagnostic signature of interrupt OB queue overflow. The CPU firmware has been spending several seconds on interrupt servicing before the watchdog fired.

Root Cause: Interrupt OB Queue Overflow Under Motion Load

When one or more interrupt OBs (cycle, hardware, time-of-day, or motion) have execution times that, when summed across the same scan, exceed the cycle monitoring time, the following sequence occurs:

1. OB1 starts. Cycle interrupt OB30 (phase offset 0) fires immediately. OB30 takes 8 ms.
2. Mid-execution of OB30, OB31 (hardware interrupt from drive) fires. OB31 is queued.
3. OB30 finishes. CPU returns to OB1.
4. OB31 fires from the queue. OB31 takes 4 ms. During OB31, OB32 (next cycle interrupt) fires, queued.
5. OB31 finishes. OB32 fires. OB32 takes 12 ms. While running, three more hardware interrupts are queued.
6. CPU returns to OB1. OB1 still has 30 ms of work to do. While doing it, OB30 (next period) fires, queued.
7. The cumulative time the CPU has spent in the original OB1 pass is now >50 ms and growing. The motion-control OB91 is also queued.
8. When the cycle time exceeds the configured 6000 ms, the firmware invokes OB80.
9. Because the interrupt load is the root cause and OB80 cannot resolve it, OB80 either is not loaded (CPU STOP) or is loaded but also exceeds its budget (CPU STOP).

The trigger is rarely a code change. It is a timing change in the actual I/O or motion environment. As long as the queued interrupts drain before the next periodic interrupt, the cycle stays healthy. When a particular scan sees all of them stack up at once (for example, a material-feed registration mark arriving exactly when the next cycle interrupt fires), the queue overflows and OB80 starts.

For the SIMATIC RotaryKnife V1.2.2 application, the most likely source is the interplay between:

• OB91 (MC-Servo) running at the PROFINET IRT isochronous cycle (typically 1 ms on the 1515T-2 PN)
• OB92 (MC-Interpolator) running at the application cycle
• The TO_Cam and TO_CamTrack technology objects used for the cutting-wheel synchronization
• Cycle interrupt OBs (OB30-OB38) configured by the application for the cam track and product tracking
• Hardware interrupts from the registration-mark input (typically a print-mark sensor)

When the print-mark arrival coincides with a cam-track recalculation, multiple OBs can be in execution or queued simultaneously. The application code runs correctly; the architecture is fragile.

S7-1500 Cycle Time Architecture Overview

The cycle time of an S7-1500 CPU is the sum of all OB1 execution time plus all interrupt OB time consumed during one OB1 pass. The relationship is defined in the Siemens TIA Portal documentation:

T_cycle_total = T_OB1 + Σ T_interrupt_OBs_executed_within_one_OB1_pass

The maximum allowable value is:

T_cycle_total < T_cycle_monitor

Where T_cycle_monitor is set in CPU Properties → Cycle → Maximum cycle time (range 1-6000 ms; default 150 ms). The S7-1500 uses a strict priority scheme. Higher-priority OBs preempt lower-priority ones. Default S7-1500 OB priorities are:

If two OBs of equal priority become due at the same instant, the second is queued. If a third is due before the first has completed, the second is queued behind the first. Queue depth is small (typically 1-2 same-priority pending events). When the queue is full and another interrupt of the same priority arrives, the firmware reports queue overflow — for cycle interrupts this surfaces as the cycle-time-exceeded OB80 event with fault code 16#0001.

For motion applications, the most important fact is that OB91 (MC-Servo) runs synchronously with the PROFINET IRT cycle and has the highest deterministic real-time requirement. Any delay in OB91 directly impacts the drive setpoint update and can cause following errors. The CPU firmware does not let OB91 starve, but if OB91 is forced to wait because a higher-priority OB is in execution, the system jitter increases.

The Siemens documentation for the S7-1500 functional description covers this in detail:

Cycle time and maximum cycle time (cycle monitoring time) – S7-1500

Step-by-Step Diagnostic Procedure

Before changing any project, perform the following to characterize the actual fault.

1. Capture the Complete Diagnostic Buffer

• Open TIA Portal → Online → Diagnostics → Diagnostic buffer.
• Click "Save as text" and store with timestamp.
• Do this every time the CPU trips. The first three entries after the last user event identify which OB was active at the moment of overflow.

2. Read OB80 Start Information

• Double-click the OB80 entry in the diagnostic buffer.
• Note OB80.STRT_INF (bytes 4-5): the fault code.
• Fault codes include 16#0001 (maximum cycle time exceeded), 16#0002 (OB not loaded — STOP triggered), 16#0007 (queue overflow due to interrupt nesting).
• Cross-reference against the OB priorities and the time stamps of the queued OBs.

3. Measure Real Cycle Time with RUNTIME

• Open the program block(s) in TIA Portal.
• Right-click → RUNTIME → Start measurement.
• Run for at least 30 minutes under full production conditions.
• Open the RUNTIME log. Look for the longest single-block execution and the longest OB-level execution.
• Typical findings: OB1 <50 ms, OB30 (cam calc) spikes to 12 ms, OB91 MC-Servo is steady at 0.8 ms, but at certain scan numbers the cumulative time is 120 ms+.

4. Use the Trace Function for OB-Level Timing

• In TIA Portal: Project tree → Traces → New trace.
• Add measurement points: OB1.PIP, OB30.PIP, OB31.PIP, OB40.PIP, OB91.PIP, OB92.PIP.
• Record at 1 ms resolution for 60 s, repeated during a known-fault condition.
• Look for: simultaneous activation, queuing, and the scan where the cumulative time crosses 6000 ms.

5. Audit Interrupt OB Priorities and Phase Offsets

• Open the device configuration for the CPU.
• Navigate to the OB properties for OB30-OB38, OB40-OB47.
• Tabulate: OB number, priority, phase offset, period.
• For RotaryKnife applications, the application library sets defaults; document them before changing.

6. Confirm the Application Library

The SIMATIC RotaryKnife V1.2.2 library is delivered as a TIA Portal HSP or as a function block library. The official entry is at the SIOS article linked below.

SIMATIC RotaryKnife V1.2.2 – SIOS application entry

Read the application notes. The library documents the expected OB30-OB38, OB91, OB92 load and the cycle-monitoring setting the project was designed against.

Interrupt OB Reorganization Procedure

The fix is architectural, not code-level. Apply the following in order, testing between each step. Before any change, back up the project to a known-good state and create a "test" copy so the running system can be restored immediately if a change worsens performance.

Step 1: Inventory All OBs in the Project

In the typical fault case, OB30/OB31/OB32/OB35 are all running with phase offset 0, and OB40 fires frequently from the print-mark sensor on misaligned material. All four OBs can be in the queue at once.

Step 2: Stagger Phase Offsets

Set the phase offsets of OB30-OB38 so that no two cycle interrupts can fire at the same instant, and ensure each completes before the next fires. Recommended mapping (assuming base PROFINET IRT cycle of 1 ms):

General rule: phase_offset[i] ≥ period[i-1] of the previous OB + worst-case execution time of the previous OB. This guarantees the previous OB is fully complete before the next fires.

Step 3: Lower Hardware Interrupt Frequency

• The print-mark sensor typically runs faster than the print-mark periodicity requires. Filter the input in the HW config:
  • Input filter: 1-2 ms (depends on sensor bandwidth)
  • Debounce in OB40: ignore events <5 ms apart
• If the print-mark spacing is variable due to material stretch, gate OB40 with a "valid window" derived from the cam track or the encoder position so OB40 only fires once per product.

Step 4: Reduce Interrupt OB Workload

• For OB30 (cam calculation), move the per-scan cam-curve interpolation into OB35 (slower cycle) where possible. Only the cam-track phase correction must run at the servo cycle.
• For OB32 (HMI data exchange), raise its period to 100 ms or move the bulk of the work to OB1.
• For OB40 (registration mark), do not call the entire product-tracking sequence in the interrupt. Set a flag, return from OB40 quickly, and let OB1 process the registration event.

Step 5: Avoid Calling Cyclic OBs Faster Than Required

The Siemens guidance is explicit: do not call an interrupt OB faster than the controlled device can react. On a 1515T-2 PN:

• PROFINET IRT cycle: 1 ms (drive setpoint update) — keep OB91 here
• Application cycle (cam, registration mark, product tracking): 4-10 ms is sufficient
• HMI data exchange: 50-100 ms
• Logging, statistics, non-critical diagnostics: 100-500 ms

A 1 ms cycle interrupt on a 1 ms PROFINET cycle is acceptable only if the OB does little work. For a heavily loaded RotaryKnife, 4-8 ms is the practical lower bound for OB30-OB32.

Step 6: Disable Interrupts Around Time-Critical OB1 Logic

For sections of OB1 that must be atomic (for example, reading a synchronized axis position and writing a synchronized setpoint), use SFC 39 (DIS_IRT) and SFC 40 (EN_IRT) to mask hardware interrupts.

// SCL example: atomic read-modify-write in OB1
DIS_IRT();     // mask interrupts OB40-OB47
// read shared DB
// modify shared DB
EN_IRT();      // re-enable

Step 7: Confirm OB80 Is Loaded and Healthy

• Add OB80 to the project if it is not present. At minimum, set a marker in OB80 and increment a counter.
• A loaded OB80 prevents the immediate STOP. The CPU will continue to run, giving the operator time to react, and the diagnostic buffer will log the time error.
• Do not rely on OB80 to "fix" the issue. It only delays the STOP. The interrupt architecture still needs to be fixed.

Step 8: Apply the Change, Download, and Monitor

• After the test project is modified, perform a STOP → RUN cycle on the test PLC.
• Use TIA Portal online to monitor OB priorities, phase offsets, and the diagnostic buffer live.
• Run for at least 24-48 hours of full production before declaring success.

Configuration: Cycle Monitoring Time

The cycle monitoring time is the watchdog that triggers OB80. It is set in TIA Portal under:

Device Configuration → CPU → Properties → Cycle → Maximum cycle time

The Siemens S7-1500 documentation specifies the valid range as 1 ms to 6000 ms. The default is 150 ms. The "parameter value: 6000 milliseconds" in the diagnostic buffer means the maximum value had already been selected. The Siemens documentation for the S7-1500 functional description covers this in detail:

Cycle time and maximum cycle time (cycle monitoring time) – S7-1500

Recommended settings for a RotaryKnife-class motion application:

Setting the cycle monitoring time too high hides the problem. Setting it too low causes nuisance trips. The correct value is the smallest value that gives a 2-3× safety margin over the worst observed cycle time.

Motion Control Specific Considerations (RotaryKnife)

The SIMATIC RotaryKnife V1.2.2 application uses the S7-1500 Motion Control function blocks and the technology objects TO_Cam, TO_CamTrack, TO_SynchronousAxis. The relevant OBs are:

• OB91 (MC-Servo): runs at the PROFINET IRT cycle. Reads actual values from the drive, writes setpoints, processes the MC-Regulation blocks. Latency here causes drive following error.
• OB92 (MC-Interpolator): runs at the application cycle (typically a multiple of the PROFINET cycle). Executes the MC-Interpolator blocks and the cam interpolation.
• OB30-OB38 (Cycle interrupts): typically used by the RotaryKnife application for product tracking, registration-mark event handling, and the cam-track synchronization.
• OB40-OB47 (Hardware interrupts): used for the print-mark sensor input and any other high-speed discrete I/O.

For the application to remain stable, the architecture must ensure:

1. OB91 never gets preempted by an OB that exceeds its budget.
2. OB92 completes within the application cycle.
3. The cycle interrupts fire only when their result is actually needed (not faster).
4. Hardware interrupts fire only on a real, debounced event.

The SIOS application page for SIMATIC RotaryKnife V1.2.2 documents the recommended OB structure and the cam-track configuration:

SIMATIC RotaryKnife V1.2.2 – SIOS application entry

If the application has been modified (different cycle interrupt period, additional hardware interrupts, added HMI polling in OB1), revert to the application defaults first and re-apply changes one at a time.

Verification and Long-Term Monitoring

After applying the architectural changes, run the following verification tiers:

Immediate Verification (within 1 hour)

• No OB80 events in the diagnostic buffer.
• RUNTIME measurement shows the longest single OB execution is well under 50 ms.
• Trace shows no overlapping OB execution at any 1 ms boundary.

24-Hour Verification

• Run a full production shift. Confirm zero OB80 events.
• Monitor the motion following error on the drives. It should remain within the configured tolerance.
• Verify the registration-mark correction is still accurate (cut position vs. print position).

Long-Term Verification (1-4 weeks)

• Spot-check the diagnostic buffer weekly.
• Track the cycle time trend in the CPU's online diagnostics. The 1515T-2 PN displays min, max, and current cycle time.
• Re-run the RUNTIME measurement monthly to catch drift from project changes.

Permanent Instrumentation

• Add a counter that increments in OB80. Reset in OB1 startup.
• Add a "last OB80 time" tag using RD_SYS_T.
• Add a per-OB execution time histogram using trace.
• If the project supports it, export the diagnostic buffer to a higher-level SCADA for trend analysis.

Preventive Best Practices

1. Always load OB80. A loaded OB80 prevents the immediate STOP and gives time to react. Log the event, sound an alarm, and let production continue until a planned intervention.
2. Never run with a 6000 ms cycle monitoring time as a permanent setting. 6000 ms is the maximum, not a target. Set the watchdog to a value that catches the fault, not one that hides it.
3. Stagger OB phase offsets from the start. Default 0/0/0/0 is the worst possible setting. Set phase offsets to ensure no two OBs collide.
4. Match interrupt period to the controlled device. Do not poll faster than the device can act. 500 µs interrupts for a sensor that updates every 1 ms is wasted CPU time.
5. Keep interrupt OBs short. Do work in OB1, not in the interrupt. Use flags or shared DBs to communicate from interrupt to cyclic.
6. Do not call user FBs from OB91. OB91 is reserved for the motion control blocks. Calling user code there breaks determinism.
7. Use DIS_IRT/EN_IRT sparingly. They are for time-critical consistency, not for routine use.
8. Document the OB architecture. Include a table of OB number, priority, phase offset, period, and purpose in the project documentation. Update it whenever the project changes.
9. Re-measure after any change. Adding a single FB to OB1 can shift the cycle time by 10 ms. Adding a hardware interrupt handler to OB40 can shift the cycle time by 50 ms under load.
10. Use the application library defaults as a baseline. The RotaryKnife V1.2.2 library documents the intended architecture. Modify only with measurement-backed justification.

Troubleshooting Matrix

FAQ