Resolving Hardware Interrupt Lost on S7-1500 ET 200SP DI8 HS

Problem Overview: "Hardware Interrupt Lost" on S7-1500 with ET 200SP DI8 HS

The diagnostic event "Hardware interrupt lost" appears in the S7-1500 CPU 1515-2 PN diagnostic buffer when an ET 200SP IM 155-6 PN HF station hosts two or more DI 8x24VDC HS (High Speed) digital input modules configured for hardware-interrupt edge detection. The error triggers as soon as a third channel — or a third module — is enabled with a rising-edge or falling-edge hardware interrupt, particularly when the assigned OB4x organization block cannot drain the pending-event queue faster than new events are inserted.

In a typical application, nine pulse sources run at approximately 100 Hz. With every channel generating a hardware interrupt, the system must absorb 900 interrupt events per second. When the OB4x execution time, system overhead, and PN/IE I/O update cycle exceed the inter-event interval on the busiest channel, the S7-1500 reports lost interrupts in the diagnostic buffer and the pulse-count data becomes unreliable.

Affected Hardware and Configuration

The configuration referenced in the field case includes the following components:

The DI 8x24VDC HS supports a 0.05 ms input filter (configurable up to 20 ms in TIA Portal under Module parameters > Inputs > Input delay). For pulse rates in the 100 Hz range, the default filter is acceptable; the bottleneck is not the input filter but the interrupt handling path.

Diagnostic Buffer Entries

When the OB4x event queue overflows, the S7-1500 writes the following entries to the online & diagnostic view of the CPU:

Open the diagnostic buffer via Online & Diagnostics > Diagnostic buffer in TIA Portal and sort by time. A repeated 0x1421 entry within milliseconds of a 0x1155 entry is the signature of OB saturation. The detailed event view lists the slot of the DI8 HS module and the channel that caused the overflow.

Root Cause Analysis

Three independent factors combine to saturate the S7-1500 hardware-interrupt subsystem in this configuration:

1. Single-Threaded OB4x Execution

OB4x is non-reentrant on the S7-1500. Once OB40 begins executing, additional hardware-interrupt events on any channel are queued — they do not preempt the running OB. The queue depth is configurable in OB40 properties (right-click OB40 > Properties > General > Priority & Queue). The default is typically a depth of 1 to 2 events. If the OB40 execution time exceeds the inter-event interval on the busiest channel, the queue fills immediately and subsequent events are lost.

2. Per-Slot Interrupt Latency on the ET 200SP

Each event must traverse the PROFINET cycle from the IM 155-6 PN HF to the CPU, be processed by the PROFINET interface, and then be handed to the OB dispatcher. With 9 channels on two DI8 HS modules, the worst-case latency for the 9th event in a burst is on the order of 2–4 PROFINET update cycles. The S7-1500 PROFINET cycle is typically 1 ms, so a worst-case latency of 2–4 ms is not unusual.

3. OB40 Payload

If OB40 reads, modifies, and writes global tags, calls FB instances, or accesses the standard process image, the execution time can easily reach 200–500 µs per event. At 900 events per second, that is 90–180 ms of CPU time per second consumed by OB40 — well above the budget the S7-1500 allots to interrupt processing on a 100 µs tick.

Solution Matrix

Five practical approaches resolve the diagnostic. The right choice depends on whether the application must stay on the DI8 HS modules or can accept a technology module, and whether the count value or only the edge timing matters.

Solution 1: Tune OB40 Priority, Queue Depth, and Payload

This is the first thing to attempt when the hardware is already mounted and the budget does not allow a technology module.

Step 1 — Raise the OB priority

Right-click OB40 > Properties > General > Priority and set the priority to 16 or higher. Higher-priority OBs preempt lower-priority OBs and cycle interrupts. OB1 default priority is 1; time-of-day OB (OB10–OB17) defaults to 2–9; cyclic OB3x defaults to 7–15. Setting OB40 to priority 16 ensures it preempts OB1 and OB3x immediately.

Step 2 — Expand the event queue

On the same Priority & Queue tab, increase the Queue depth (number of pending start events). For nine sources, set it to 8. This allows eight OB40 start events to stack while OB40 is running. The 9th event in a burst is still lost, but the buffer absorbs short transients.

Step 3 — Enable diagnostic buffer entry on overflow

Activate the checkbox Generate diagnostic buffer entry on event loss. This is the only reliable way to detect overflow during commissioning; the application code cannot observe a lost event because no event is delivered.

Step 4 — Minimize OB40 payload

OB40 should contain only the minimum work required. A recommended pattern:

// OB40 - Hardware interrupt
// Reads the slot that triggered the interrupt from OB40_HEADER info
// Stores the channel bit pattern in a global DB for OB1 to process

#tempSlot := OB40_HEADER.SLOT;       // slot number that raised the event
#tempChannel := OB40_HEADER_CHANNEL; // 0..7 on the DI8 HS

// Disable nested interrupts during the increment
DIS_AIRT();   // Delay interrupt processing
gDB_PulseCount[#tempSlot].Count[#tempChannel] := 
    gDB_PulseCount[#tempSlot].Count[#tempChannel] + 1;
EN_AIRT();    // Re-enable interrupt processing

Step 5 — Disable OB40 self-nesting

Do not call an FB from OB40 that itself takes longer than the inter-event interval. If a second event arrives while the FB is running, the queue absorbs it; once the queue fills, the 0x1421 event is logged.

Solution 2: Replace OB40 with Cyclic OB3x and Direct Input Access

For a 100 Hz pulse stream, cyclic polling is fast enough. The S7-1500 supports a 1 ms minimum cycle time for OB3x on firmware V2.0 and later; on firmware V2.5 and later the minimum is 500 µs. With a 1 ms cycle, the worst-case sampling error is 1 ms, which is acceptable for cumulative pulse counting.

Configuration steps

1. Add OB30 (Cyclic interrupt) to the program. Right-click Program blocks > Add new block > Organization block > OB30.
2. Open OB30 properties > General > Cycle time and set the period to 1 ms.
3. Open the DI8 HS device configuration in TIA Portal. Under Module parameters > Inputs > Channel assignment, set the input delay to 0.05 ms (the minimum) to preserve edge fidelity.
4. Disable the hardware interrupt on every channel — the channels remain digital inputs, but OB40 will not fire.
5. In OB30, read the process image of the input word using the P access qualifier:

   // OB30 - Cyclic interrupt, 1 ms
   // Read the input word with immediate process-image update
   #currentWord := %IW20:P;   // 16-bit snapshot of the DI8 HS input word

6. Compare #currentWord with the previous snapshot stored in a global DB. For every rising bit, increment the corresponding counter in the DB. This is the classic rotary buffer pattern: the DB holds 1 ms snapshots, OB1 processes the buffer at its own pace.

Sample OB30 code

// OB30 - 1 ms cyclic interrupt
VAR_TEMP
    tInfo     : WORD;     // current snapshot
    tInfoOld  : WORD;     // previous snapshot (read from gDB_RingBuf[gDB_Head])
    tDelta    : WORD;     // XOR of new and old
    i         : INT;
END_VAR

#tInfo := %IW20:P;                       // read live inputs
gDB_RingBuf[gDB_Head] := #tInfo;          // store in rotary buffer
gDB_Head := gDB_Head + 1;
IF gDB_Head >= 100 THEN gDB_Head := 0; END_IF;

// Edge detection (rising)
#tDelta := #tInfo XOR NOT gDB_RingBufPrev;
gDB_RingBufPrev := #tInfo;

// Increment per channel
FOR #i := 0 TO 7 DO
    IF (#tDelta AND SHL(WORD#1, #i)) <> 0 THEN
        gDB_PulseCount[#i] := gDB_PulseCount[#i] + 1;
    END_IF;
END_FOR;

Verification

After commissioning, monitor the diagnostic buffer for 0x1421 events for at least 10 minutes of full pulse activity. The buffer should remain clean. In OB1, read gDB_PulseCount[i] via the HMI and confirm the counts increment at the expected rate (100 counts/second per channel).

Solution 3: Use the DI8 HS Built-in Count Mode

The DI 8x24VDC HS module supports a Count mode on channel groups. In TIA Portal, the DI8 HS exposes two counting channels: Channel 0 (inputs 0–3) and Channel 1 (inputs 4–7). Each counting channel can count rising edges on its assigned input and gate the count with a hardware-controlled enable. The count value is read from the slot via the I/O address space — no OB4x is involved.

Configuration

1. Open the DI8 HS device view in TIA Portal.
2. Select the channel group (0 or 1) and set the operating mode to Counting.
3. Assign the count input, gate input, and direction input as needed.
4. Set the upper and lower count limits.
5. Read the count value in the user program using the I/O address slot, e.g. %ID100 for a 32-bit count at slot 2.

Limitation

Each DI8 HS module supports two counting channels, so the module covers 4 of the 8 input pins as count sources. The remaining 4 pins return to standard digital-input behavior. For 9 pulse sources, the count-mode approach on the two DI8 HS modules covers 4 sources, leaving 5 — which is why the hybrid approach (Solution 5) is usually required.

Solution 4: Add a TM Count 1x24V Technology Module

The TM Count 1x24V (6ES7138-6AA01-0BA0) is a single-channel 24 V counter module with a maximum count frequency of 200 kHz, configurable gate control, and a hardware comparator output. It is the right solution when pulse timing must be captured deterministically with sub-microsecond latency.

Wiring and slot layout

Each TM Count requires:

• One BaseUnit of type BU15-P16+A0+2D (6ES7193-6BP00-0BA0) for the incoming signals and power.
• One BaseUnit of type BU15-P16+A0+2B (6ES7193-6BP00-0BA1) for the outgoing continuation.
• 24 V supply on the BaseUnit, wired to the encoder/pulse source.

For nine sources, nine TM Count modules are required, which is the same BaseUnit footprint as nine DI8 HS modules plus an additional nine for the continuation. The hardware cost is significant, but the application CPU load drops to zero for pulse counting.

Configuration

1. Add a TM Count 1x24V to the ET 200SP station in the device configuration.
2. Under Module parameters > Counter > Operating mode, select Count continuously or Count once.
3. Set the count direction to Count up for positive pulse counting.
4. Configure the gate input for the start/stop behavior of your process.
5. Use the CTRL_HSC instruction (S7-1500 Motion Control library) to read and reset the count value in the user program.

Advantages

• Counting is independent of the CPU cycle and the OB4x dispatcher.
• No diagnostic-buffer "Hardware interrupt lost" events.
• Deterministic timing at the module level.
• Sub-microsecond latency — well below the 100 Hz pulse period.

Solution 5: Hybrid Configuration

When the budget is constrained and full coverage of all nine sources is required, configure both DI8 HS modules for counting mode (covering 4 sources) and use a third, non-HS digital input module for the remaining 5 channels with hardware interrupts on the rising edge only. Standard DI modules such as DI 8x24VDC ST (6ES7131-6BF00-0AA0) support hardware interrupts, although with a wider minimum input filter of 0.05 ms and a longer hardware-interrupt latency than the HS variant.

Layout

OB40 configuration for the standard DI

Apply the same priority-16, queue-depth-8 settings to OB40. Because the ST module has a 0.05 ms input filter and the hardware interrupt signal is routed through the same OB4x dispatcher, the same tuning rules apply. The risk of lost interrupts is greatly reduced because the ST module handles only 5 channels, and the OB40 queue can absorb a 5-event burst with depth 8.

Verification Procedure

Whichever solution is selected, run the following verification steps before signing off the commissioning:

1. Diagnostic buffer sweep. Connect TIA Portal online, open Online & Diagnostics > Diagnostic buffer, clear the buffer, then run the process for 30 minutes at full pulse rate. Confirm zero 0x1421 "Hardware interrupt lost" entries.
2. Per-channel count verification. Display the count tags on the HMI or in the watch table. Each channel should increment at exactly 100 counts/second (plus or minus 1 count due to the OB cycle). Use a stopwatch and the watch table to confirm.
3. CPU load check. Open Online & Diagnostics > Cycle & load and confirm OB1 cycle time remains under 5 ms and CPU load under 70%. OB40 or OB30 execution time should be logged in the diagnostics.
4. Burst test. Force the 9 pulse sources to start in the same millisecond (use a test fixture with a common trigger) and confirm that the count increment on every channel matches the burst count.
5. Long-term soak. Leave the system running for 24 hours and re-check the diagnostic buffer for any 0x1421 events. If even one occurs, increase the queue depth by 2 or move to Solution 4 (TM Count).

Common Pitfalls

Engineers frequently run into these issues when commissioning DI8 HS hardware interrupts:

• Reading the standard process image instead of %IW:P. In OB30, %IW20 returns the process image refreshed at the end of the last OB1 cycle. %IW20:P returns the live input value. For 1 ms cyclic OB3x on a 100 Hz signal, only the P qualifier provides correct edge detection.
• Forgetting to enable the channel in the hardware config. The DI8 HS channel must be set to Enabled (not just Active) for hardware interrupts to fire. Check Module parameters > Inputs > Channel [n] > Enable.
• Using DIS_IRT on S7-1500. DIS_IRT and EN_IRT are S7-300/400 instructions. On the S7-1500 they are recognized as syntax errors at compile time on firmware V2.0 and later. Use DIS_AIRT / EN_AIRT.
• Queue depth set to 1. The default OB40 queue depth of 1 is rarely sufficient for a multi-channel hardware interrupt. Set it to 8 or more for nine pulse sources.
• Calling FBs from OB40. Any FB that itself waits on a condition (timer, communication, etc.) will block OB40 for longer than the inter-event interval and overflow the queue.

Diagnostic Reference Summary

Standards and Reference Documentation

For the authoritative descriptions of hardware-interrupt handling on the S7-1500, refer to the S7-1500 System Manual section "Program execution" and the ET 200SP System Manual. The DI 8x24VDC HS module manual describes the input filter, hardware-interrupt, and count-mode parameters. The TIA Portal online help, accessible via F1 in any OB properties dialog, documents the Priority & Queue tab fields and their valid ranges. The general concept of hardware interrupts as asynchronous signals to a processor is described in the Wikipedia article on interrupts at https://en.wikipedia.org/wiki/Interrupt.