Fixing S7-400 Multiple OB Request Error with SFB14 PUT

Problem Summary

A redundant SIMATIC S7-400 H station built around a CPU 417-4H drops to STOP (Internal Fault) every time the user program calls FB1010 from OB35. The diagnostic buffer of the master CPU reports "Multiple OB request error causing information buffer overflow." The same program continues to run normally when FB1010 is omitted or when only the bare SFB14 PUT / SFB15 GET blocks (without TEMP variables) are inserted. A companion receive FB that uses SFB15 GET inside its own multi-instance DB does not trip the fault.

The stack display inside STEP 7 / SIMATIC Manager shows the following nesting when the CPU transitions to STOP:

• OB1 → FB128 (SUBNET)
• OB35 → FB1010 (the offending block)

This article decodes the diagnostic event, isolates the FB1010 + SFB14 combination as the root cause, and provides a deterministic resolution sequence. It also documents the OB80 time-error path that the CPU uses to surface the fault, the local data stack sizing that must accompany any cyclic-interrupt OB on the S7-400, and the S7-300 vs S7-400 PUT/GET variant differences that frequently slip into mixed CPU projects.

Decoding the Diagnostic Buffer

The wording "Multiple OB request error" is the plain-English translation that STEP 7 prints for an OB80 time-error event raised while another OB80 (or the same OB80) is still being processed. The exact hex event ID you will see depends on the CPU firmware and the OB priority chain, but the family of events is consistent across CPU 412, 414, 416, 417 devices:

According to the Siemens documentation for Time error OB (OB 80) (S7-300, S7-400) - STEP 7, the CPU operating system calls OB 80 whenever an error occurs while executing an OB. The triggering conditions include:

• Exceeding the cycle time of OB1.
• OB being requested again before the previous execution of the same OB has finished (the classic multiple OB request condition).
• Cyclic interrupt OB (OB30-OB38) overrun.
• Time-of-day interrupt OB (OB10-OB17) overrun or interrupt loss.

If OB80 is not loaded in the CPU, the default reaction on the S7-400 is to enter STOP with the diagnostic text shown above. On the CPU 417-4H, that STOP also propagates through the H-link and bring the partner CPU into solo mode until the event is acknowledged and the original CPU is restarted.

Root Cause Analysis

Three layered causes explain why FB1010 + SFB14 PUT inside OB35 reproduces the fault while the GET-side companion FB does not:

1. SFB14 PUT holds the OB35 execution slot longer than the cyclic interrupt period

SFB14 (PUT) for the S7-400 is an asynchronously executed communication block. Once called, it starts a job to the partner CPU 315PN/DP via the S7 connection, then returns control to the caller. If REQ remains TRUE on the next OB35 cycle and the previous PUT job has not yet completed, a new PUT instance is started. With four configured S7 connections multiplexed through the same FB1010 and a multi-instance DB for PUT embedded inside the instance DB of FB1010, the worst-case execution time of FB1010 can exceed the OB35 period (default 100 ms).

When that happens, OB35 is requested again before the previous FB1010 run has returned. The CPU dispatches OB80 to report the overrun. If your project does not contain OB80 (or contains an OB80 that itself calls FB1010 / SFB14), the diagnostic buffer fills with repeated OB80 entries and ends with "information buffer overflow", and the CPU goes to STOP.

2. Local data (L-stack) size of OB35 is undersized

Each OB reserves its own slice of the CPU's local data stack. The size is configured per OB under PLC → Properties → Memory in STEP 7. FB1010 carries TEMP variables, SFB14 PUT multi-instance state, and nested call frames for any helper FCs. If the OB35 local data size is left at the STEP 7 default (typically 256 bytes for S7-400), the moment FB1010 is added the stack footprint exceeds the reservation and the CPU raises an OB80 / OB121-style event before the block even returns.

3. PUT/GET block variant mismatch

The S7-300 family uses FB14 / FB15 for PUT/GET when a CP is in the slot, and FB14 / FB15 (not SFB) when working through the PN interface. The S7-400 uses SFB14 / SFB15 always. If the project was started on a CPU 315 template and later migrated to the CPU 417-4H, the call sites in FB1010 may still reference FB14 PUT from the S7-300 library instead of SFB14 PUT from the S7-400 system blocks. The interface signatures differ in the multi-instance DB layout, which produces a corrupted ANY pointer on the first call and triggers a programming-error OB (OB121) on the next OB35 cycle.

Local Data Stack Sizing for OB35 + FB1010

The S7-400 CPU exposes a per-OB local data byte count. The total of all OBs running concurrently must fit inside the CPU-wide Local Data budget (e.g. CPU 417-4H: 64 KB). A practical sizing table for this scenario:

Procedure in SIMATIC Manager:

1. Right-click the S7-400 station → Object Properties.
2. Open the Memory tab.
3. For OB35, raise the local data size to at least 1024 bytes.
4. Repeat for OB1, OB80, OB82, OB83, OB85, OB86, OB100, OB121, OB122 if any of them are used (the FBs you call from them also consume the budget).
5. Make sure the sum across all OBs is still inside the CPU's Local Data (entire CPU) value; otherwise the CPU will reject the configuration on download.

OB80: Why the Fault Manifests as "Multiple OB Request"

When the CPU detects that the same OB has been requested again before the previous execution completed, it raises OB80 (Time Error). The CPU passes a BYTE fault code in OB80_FLT_ID and the offending OB number in OB80_ERROR_INFO. The two patterns relevant here are:

• Fault ID B#16#01 - cycle time of OB1 exceeded.
• Fault ID B#16#02 - OB called again before previous execution finished (the multiple-OB-request case).

If your project does not contain OB80, the default reaction is STOP. If your project does contain OB80 but OB80 itself blocks on the same FB1010 / SFB14 chain (because the programmer tried to "handle the error"), then OB80 is requested again while it is still running, the diagnostic ring buffer overflows, and you see the full buffer text.

The recovery is to:

1. Provide a lean OB80 that only sets a flag, increments a counter, and returns - never call SFB14/15 from OB80.
2. Fix the underlying OB35 overrun so that OB80 is never actually triggered in normal operation.

PUT Block Variant: S7-400 SFB14 vs S7-300 FB14

The block library differs between families. Confirm the variant that is actually referenced inside FB1010:

If FB1010 contains CALL FB14, DBxx with a multi-instance DB that lives inside the instance DB of FB1010, you must rebuild the block as CALL SFB14, DBNO (or as a multi-instance SFB14 inside FB1010). The same change applies to GET (SFB15). After the swap, recompile all sources and re-download.

H-System Specific Considerations (CPU 417-4H)

The CPU 417-4H is a fully redundant controller. Behaviour that does not appear on a single CPU 417 often surfaces here:

• Fail-over on master OB fault: if the master CPU enters STOP because of OB80, the reserve CPU takes over solo. The H-link is rebuilt and the diagnostic buffer of the new master receives a copy of the original event plus a W#16#6522 / W#16#6523 redundancy loss entry. This is what produced the original observation "the redundancy gone."
• Event-synchronous OB execution on both halves: on a synchronous H-link, OB35 is started on both CPUs. If the master trips, the reserve CPU may execute a partially redundant OB80 before the H-link has synchronised, which compounds the diagnostic buffer overflow.
• H-CPU connection accounting: the CPU 417-4H has a fixed number of S7 connection resources. Each configured CP443-1, each PN/IO port, and each H-link counts against that budget. With 4 active S7 connections (2 via PN/IO + 2 via CP443-1) the connection table is at the limit for some firmware versions. Confirm in NetPro → Connection overview that the table is not over-allocated; if it is, SFB14 PUT can return STATUS = W#16#8083 / W#16#80A3 on the second call, which is misread by FB1010 as a "do it again" condition and re-arms the next PUT.

Networking Topology in This Project

The four S7 connections configured between the H-station and the S7-300 stations are:

1. H-CPU (Rack 0) ↔ CPU 315PN/DP, via PN/IO port of the H-CPU. (S7 connection)
2. H-CPU (Rack 1) ↔ CPU 315PN/DP, via PN/IO port of the H-CPU. (S7 connection)
3. H-CPU (Rack 0) ↔ CPU 315PN/DP, via CP443-1 (or CP343-1 on the S7-300 side, depending on slot). (S7 connection)
4. H-CPU (Rack 1) ↔ CPU 315PN/DP, via the redundant CP. (S7 connection)

All four terminate on a SCALANCE switch between the H-station and the S7-300 stations. Only one of the four is currently active; the project still configures the others for future redundancy. For the present fault, the topology itself is not the cause, but the redundant connection table interacts with FB1010's PUT handling - see the "guard the connection table" step in the resolution procedure.

Step-by-Step Resolution Procedure

1. Confirm the diagnostic event. Open PLC → Accessible Nodes, attach online to the master CPU 417-4H, and screenshot the diagnostic buffer. The most recent entries should read "Multiple OB request error" immediately followed by "Information buffer overflow" and "STOP due to OB80."
2. Inspect the L-stack / I-stack. From the diagnostic buffer's Stack tab, click GoTo Block on each entry. Confirm the chain OB35 → FB1010 → SFB14 (multi-instance) and the offending STL/SCL line.
3. Eliminate OB80 recursion. If OB80 exists, open it and remove any call to FB1010, SFB14, SFB15, or any communication FC. Replace with a one-line SET + counter increment in a global DB. Re-download the entire program in STOP mode.
4. Resize OB35 local data. Raise OB35 local data to 1024 bytes (CPU 417-4H), OB1 to 512 bytes if it hosts the FB128 SUBNET call chain. Confirm the sum fits the CPU-wide budget.
5. Verify PUT/GET block variants. In the S7 program, locate System Blocks → Standard Library → Communication Blocks. Confirm that FB1010 calls SFB14 PUT and SFB15 GET (system blocks for S7-400), not FB14 / FB15 from the S7-300 library.
6. Switch PUT to edge-triggered REQ. The most common pattern that fixes this exact symptom is to drive SFB14 REQ from a rising edge instead of a level, so that one PUT job is started per OB35 cycle regardless of how long the previous job takes to complete. Example in STL:

         A     "send_trigger"       // BOOL, set by upstream logic
         FP    "send_trigger_edge"  // edge flag, own STATIC in FB1010 instance DB
         =     #REQ_put
   
         CALL  "PUT"                 // SFB14
          REQ   := #REQ_put
          ID    := W#16#1            // connection ID from NetPro
          DONE  := #put_done
          ERROR := #put_err
          STATUS:= #put_status
          ADDR_1:= P#DB20.DBX0.0 BYTE 100
          SD_1  := P#M 100.0 BYTE 100

   The same idea applies to SFB15 GET on the receive side.
7. Guard the connection table. In FB1010, evaluate the STATUS word of SFB14 against documented error codes. If STATUS = W#16#8083 (resource exhausted) or W#16#80A3, suppress the next REQ for at least one OB35 period. This avoids re-arming PUT faster than the partner CPU can service the connection.
8. Recompile from source. Use File → Generate Source in SIMATIC Manager, select all blocks, compile, then re-download to the station. This rewrites every instance DB and clears stale multi-instance layouts in the FB1010 instance DB that the previous CALL FB14 may have left behind.
9. Re-download in STOP. Stop both halves of the H-station, download hardware config (NetPro + HW Config) first, then blocks. Run the program cold from OB100 startup.
10. Monitor online. With the program running, watch the Cycle Time and OB35 execution time in PLC → Module Information → Performance Data. Verify OB35 worst-case execution is below 80% of its period (e.g. <80 ms for a 100 ms OB35).

Verification Checklist

Related Diagnostic Events to Watch For

Why the GET-side FB Does Not Trigger the Fault

The companion receive FB uses SFB15 GET with a multi-instance DB and the same TEMP pattern. It does not crash the CPU because GET is, in this project, driven by the partner CPU 315PN/DP (one-sided communication only). The H-station is not actively pushing jobs - it only polls. The polling rate of SFB15 GET is therefore bounded by the partner's response time and almost always finishes within the OB35 period. PUT, in contrast, is initiated by the H-station itself; if the partner or the SCALANCE switch is slow to ACK, the PUT job can exceed one OB35 cycle, and the next OB35 call re-enters FB1010 before the previous instance has finished - exactly the multiple-OB-request condition.

Alternative Architectural Fixes

If the OB35-bound PUT pattern is repeatedly fragile, consider any of the following:

• Move PUT into OB1 / a low-priority cyclic OB. A 100 ms OB35 is too tight for redundant cross-CPU PUT through SCALANCE. OB1 has the full cycle budget and tolerates the longer worst case.
• Use BSEND / BRCV (SFB12 / SFB13) for large data blocks, or USEND / URCV (SFB8 / SFB9) for small, uncoordinated packets. These have simpler state machines than PUT/GET.
• Use a single H-station-side connection with HCiR (H-CPU connection redundancy) instead of two parallel CPs. Fewer connections means a smaller connection table and lower risk of W#16#80A3.
• Insert OB80 with a SFC39 / SFC40 disable of OB35 for one cycle as a "circuit breaker" - acceptable only if you cannot fix the root cause.