Siemens S7 Hardware Interrupt OB Execution Timing in the CPU

Overview: Where Hardware Interrupts Land in the S7 Scan

On every Siemens S7-300, S7-400, S7-1200, and S7-1500 CPU, the user program does not run as a single uninterrupted loop. The operating system (firmware) executes a sequence called the scan cycle that is built from organization blocks (OBs) plus a fixed set of housekeeping tasks. Hardware interrupt OBs (OB40 in the classic family, OB40–OB47 depending on event) are asynchronous, event-driven OBs that can preempt the main cyclic program OB1. The practical question is therefore not whether they will fire but exactly when, with what priority, and what state the process image is in at the moment they take control.

This reference consolidates the cycle description from the S7-300 CPU Specifications manual (entry ID 8860591) with the modern OB description from the S7-1500 hardware interrupt OBs documentation (TIA Portal V20) and the equivalent S7-1200 hardware interrupt OBs documentation (TIA Portal V20).

The S7 CPU Scan Cycle, Step by Step

The classic S7-300 cycle (CPU 312 IFM through 318-2 DP) is described in the CPU Specifications manual as six discrete phases. The same skeleton, with minor reordering, applies to S7-400, S7-1200, and S7-1500. The order of operations in each scan is:

1. The operating system starts the cycle monitoring time (OB1 cycle watchdog, default 150 ms for S7-300, configurable per CPU).
2. The CPU writes the values from the process image of the outputs (PIQ) to the output modules.
3. The CPU reads the state of the inputs of the input modules and updates the process image of the inputs (PII).
4. The CPU processes the user program and executes the instructions contained in OB1 and any blocks called by OB1.
5. At the end of the cycle, the operating system executes any tasks that are pending (for example downloading and deleting blocks, sending and receiving global data, diagnostic fetches).
6. The CPU returns to the start of the cycle and restarts the cycle monitoring time.

The cycle is therefore not fixed in duration. It is a soft real-time loop whose length varies with:

• User program execution time in OB1.
• Time consumed by interrupt OBs (hardware, time-of-day, cyclic, diagnostic, error).
• Communication load over MPI, PROFIBUS, PROFINET, and Industrial Ethernet.
• Online/diagnostic tools (watch tables, force tables, trace, status).
• Block download/delete operations and run/stop transitions.

The online "Cycle" tab in the CPU properties (TIA Portal or STEP 7) reports the shortest, longest, and current cycle time so that the engineer can quantify this variation directly on the running controller.

OB Priority Classes Across S7-300, S7-400, and S7-1500

Every OB carries a priority class that determines whether it can interrupt a currently running OB. Two OBs of the same priority class cannot interrupt each other; they are queued. A lower-priority OB is interrupted by a higher-priority OB the moment the higher-priority OB becomes ready to run (subject to the current instruction completing and the OB being enabled in the CPU configuration).

On the S7-1500 family, the hardware interrupt OB is OB40 only; the TIA Portal V20 documentation describes a single "Hardware interrupt OB" entry whose event-binding (which channel triggers it) is assigned in the module properties. S7-1200 behaves the same way in principle, with the assignment of an event to exactly one hardware interrupt OB per channel, as stated in the linked S7-1200 reference page.

Process Image of Inputs (PII) and Outputs (PIQ) Inside an OB

The process image is a per-cycle-consistent copy of the I/O that the user program reads instead of touching the backplane each time. Its update is bound to the OB that owns it:

• OB1: the PIQ is written to the modules at the start of OB1; the PII is read from the modules at the start of OB1 (S7-300/400 conventional sequence). Within a single pass of OB1, all reads of the PII return the values that were latched at the start of that pass, and all writes to the PIQ are flushed at the end.
• Hardware interrupt OB (OB40, etc.): by default, the PII/PIQ is not updated when the OB starts or finishes. The interrupt code sees the same PII snapshot that the interrupted OB1 was using. Outputs written into the PIQ during the interrupt are held until the next PIQ flush point of OB1.
• Forced flush: an interrupt OB can request an explicit update by calling SFC26 UPDAT_PI (refresh PII) and SFC27 UPDAT_PO (flush PIQ) for partial ranges. S7-1500/1200 also support multiple process image partitions, which can be assigned to specific OBs and updated independently.

The decisive rule is therefore: the PII/PIQ update is an integral part of the OB that performs it, and it has the same priority class as that OB. There is no "global PII" that all OBs share; each OB that has been configured with a process image partition updates only that partition at its own priority.

Communication in the Cycle: MPI vs. PROFIBUS/PROFINET vs. Ethernet

The cycle composition question is most often raised because the engineer is unsure whether the time spent servicing communication is "inside" the cycle or "outside" it. The answer is platform-specific:

The mnemonic that follows from this: PROFIBUS and PROFINET are ASICs that run independently of OB1, while MPI and most user-level Ethernet services do not. A heavy PROFINET load therefore does not show up in OB1_CYCLE_TIME even though it consumes I/O bandwidth; a heavy MPI load does.

When a Hardware Interrupt OB Executes

A hardware interrupt is reported by a module that is configured for "Hardware interrupt" (rising edge, falling edge, or both, or in the case of an FM/CP, by a module-specific event such as a comparator match, gate closing, or PN controller status). The firmware records the event, sets the corresponding event in the diagnostic buffer, and requests OB40. OB40 then runs when the current instruction of the currently running OB finishes, provided:

1. OB40 has been loaded into the work memory and the CPU is in RUN.
2. No OB with a priority strictly higher than OB40 is currently active.
3. The OB execution nesting depth limit (8 in classic S7-300, configurable up to 24 in S7-400, 6 in S7-1500 by default) is not already full.

Concretely, the scenarios raised in the field report are:

• Hardware interrupt between OB1 scans: the firmware has just left OB1 and is in phase 5 (pending OS tasks, including MPI servicing). The interrupt becomes pending; OB1 has already returned. OB40 starts at the first scheduling point and the next OB1 pass resumes only after OB40 completes.
• Hardware interrupt during phase 2 (PIQ output) or phase 3 (PII input): not possible. The PIQ/PII update is performed by the operating system at priority 1 (the same class as OB1) under interrupt lock. OB40 cannot preempt the update; the interrupt is queued and starts after the update completes.
• Hardware interrupt during user program (phase 4): OB40 starts at the next instruction boundary. State of the PII/PIQ is whatever it was when OB1 began; OB40 sees the same snapshot.
• Hardware interrupt during MPI communication (phase 5): the MPI handling is part of OB1 priority 1 work; OB40 preempts it.

The "how immediately is immediate" question is answered by the S7-300 CPU Specifications manual: the worst-case reaction time to a hardware interrupt is given by the sum of the current instruction time plus the interrupt enable time of the ASIC plus the OB40 entry/exit overhead. For the S7-300 family this is documented in chapter 4 ("Interrupt response time") of the manual and is on the order of a few hundred microseconds for a standard CPU. S7-1500 hardware interrupt reaction is documented per CPU in the device manual ("Interrupt response time" section of the technical specifications).

OB Nesting, Stack Depth, and Queuing

The CPU maintains a fixed-size interrupt stack. Each OB activation consumes one stack entry. When the nesting depth is reached, additional interrupts of any priority are queued rather than dropped, up to a queue limit. The limits in firmware release V4.x of the S7-300 family are:

Two rules follow from this:

• If the same hardware event fires faster than the OB can service it, the queue fills and an OB80 time error is generated on the second overflow, with diagnostic entry "OB40 queue overflow" (event ID 0x3501 in S7-1500 / 0x2521 in S7-300). The PLC does not go to STOP automatically unless configured to do so.
• If a hardware interrupt OB is missing (not loaded), the firmware raises an OB85 priority-26 error with the start info event ID "OB not loaded". This is the most common cause of an unexpected STOP at startup when the program is only partially downloaded.

Cycle Time Composition and How to Read It

The reported OB1 cycle time is computed by the firmware and stored in two tags that can be read from the user program:

• OB1_PREV_CYCLE (DWord, ms): the duration of the previous OB1 execution, measured from start to return.
• OB1_CYCLE_TIME (Word, ms, S7-300) / OB1_CUR_CYCLE (S7-1500): the duration of the currently running OB1.
• OB1_MIN_CYCLE / OB1_MAX_CYCLE (S7-1500 only, IEC timers): sliding min/max of the last n cycles.

The cycle time formula presented in the S7-300 manual is:

T_cycle = T_pi_update + T_user_program + T_communication + T_interrupt_OB_time + T_operating_system_overhead

where:

• T_pi_update: time to read inputs into the PII and write PIQ to outputs. For a fully populated ET200M on PROFIBUS this is on the order of 1–5 ms per 32 bytes of I/O; for a PROFINET device it is parallel and typically negligible.
• T_user_program: OB1 execution including all FC/FB calls. Can be observed with the S7-300/400 "Program status" or with the S7-1500 "Function runtime measurement" tool.
• T_communication: time spent in MPI/PG/OP communication at the end of the cycle. Visible in the online "Cycle" tab as a separate bar.
• T_interrupt_OB_time: time spent in hardware / cyclic / time-of-day / diagnostic OBs that pre-empt OB1.
• T_operating_system_overhead: typically 100–500 µs per scan on a CPU 315-2 PN/DP; higher on S7-1500 with activated security features.

Configuring Hardware Interrupts in STEP 7 and TIA Portal

The procedure is essentially the same on the two engineering tools, with cosmetic differences.

1. Enable the interrupt on the module: in the device configuration, open the digital input (or FM/CP) properties, switch to the "Inputs" or "Basic parameters" tab, and tick the rising/falling-edge event(s) you want.
2. Assign an OB: for each enabled event, set the "Hardware interrupt OB" to OB40 (default) or to a user-defined OB such as OB41, OB42. STEP 7 / TIA Portal will create the empty block skeleton on first download if you confirm the prompt.
3. Bind the start info: inside the OB, read OB40_POINT_ADDR (DWord, 12 bytes for classic S7-300) to find the module and channel that triggered the interrupt. For a DI module this is the bit pattern of the channel that fired.
4. Optional process image partition: in TIA Portal, assign a process image partition to OB40 (e.g. PIP 2) and bind the relevant module channels to that partition. The partition is updated automatically when OB40 runs, and flushed when OB40 returns. This is the only way to make OB40 "see fresh" inputs without a manual UPDAT_PI call.
5. Set the OB priority: open OB40 properties, change the priority if needed (must be unique and not collide with other OBs in the configuration).
6. Download: hardware configuration and software to the CPU in STOP first, then RUN.

Inside the OB itself, a minimal handler template is:

// OB40 Hardware Interrupt - read the source channel
#iChannelMask := OB40_POINT_ADDR;       // DWORD
#bEdgeRising   := (OB40_FLT_ID) = 0;     // rising-edge event
IF (#bEdgeRising) THEN
    // service code: latch input, set a flag, increment counter
    "dbCounts".iEdgeCounter := "dbCounts".iEdgeCounter + 1;
END_IF;

The exact symbol set (OB40_POINT_ADDR vs. local variable LADDR vs. POINT_ADDR) depends on the CPU family. The TIA Portal V20 help pages list the input interface of the hardware interrupt OB for S7-1500 and S7-1200 explicitly.

Verification and Online Diagnostics

Three independent methods are recommended to confirm that the hardware interrupt is firing on the running CPU:

1. Diagnostic buffer: in TIA Portal, go online to the CPU, open "Diagnostics > Diagnostic buffer", and filter for "Event ID 0x1151 / OB40 / Hardware interrupt". Each event lists the module logical address, the channel, and the time stamp with microsecond resolution.
2. Cycle / OB1 statistics: in the CPU's online "Cycle" view, observe the OB1_MAX_CYCLE and the time the CPU spent inside OB40 (visible as a separate bar in the S7-1500 cycle composition chart).
3. Trace / function runtime measurement: on S7-1500, configure a trace on the OB40 local variable LADDR or on a user-defined RetVal that counts entries. This is the most reliable way to confirm the timing relative to OB1, since the trace timestamp is taken in the same hardware clock as the OB start.

Common Pitfalls in the S7 Interrupt Architecture

Five error patterns recur in the field. Each is paired with the diagnostic signature to look for.

S7-1200 and S7-1500 Specifics

The TIA Portal V20 documentation for S7-1500 and S7-1200 hardware interrupt OBs is explicit on a few points that differ from the S7-300/400 classic view:

• Single hardware interrupt OB per event: "You can assign an event that triggers an alarm to precisely one hardware interrupt OB." This means a single rising-edge event on a specific channel cannot be split between two OBs; it must be routed to one OB, and the OB itself decides what to do based on the start info.
• Single OB40 only on S7-1500: there are no OB41–OB47 in the S7-1500 firmware in the same way as S7-300/400. S7-1500 allows you to create OB41–OB47 in the project but the runtime model is "single hardware interrupt OB, multiple event bindings". Confirm against the device description in TIA Portal for the specific CPU.
• Process image partitions: S7-1500 firmware supports up to 31 PIPs (PIP 0 is the system partition, PIP 1 is the OB1 partition). PIPs are assigned to OBs in the device configuration under the module > "Process image" drop-down.
• Event-driven data block initialization: the S7-1500 firmware has optimized blocks that can be flagged as "retain on OB start"; this affects whether instance DBs are re-initialized on OB40 entry, which can cause confusion if the OB40 and OB1 share a DB.
• Isochronous mode: on PROFINET IRT with isochronous OBs, OB40 can be triggered in synchronism with the PN cycle (Ti/To). This is the only way to guarantee deterministic input sampling at a fixed phase relative to OB1, and it requires explicit configuration of the PN topology in TIA Portal.

For the full reference of the start info interface and the configurable priority in TIA Portal V20, see the S7-1500 hardware interrupt OBs page and the equivalent S7-1200 hardware interrupt OBs page. For the underlying cycle definition on the older S7-300 family, the CPU 312 IFM to 318-2 DP specifications manual (entry ID 8860591) remains the authoritative source.