Problem Overview
When a Function Block (FB) is edited, saved, and prepared for download inside the Siemens SIMATIC Manager (STEP 7 V5.x) or TIA Portal, the programming tool may display the information prompt:
"When this block is loaded, the CPU goes into the STOP mode. Do you want to continue?"
(German original: "Beim Laden dieses Bausteins geht die CPU in STOP. Wollen Sie jetzt den Baustein laden?")
The message is raised by the editor when the FB interface signature has changed such that the existing Instance Data Block (IDB) in the CPU is no longer consistent with the new FB declaration. The wording is a precaution, not a guarantee: the CPU may transition to STOP on the next scan cycle if it accesses an IDB operand that no longer exists. If the IDB has been regenerated and downloaded alongside the FB, or if OB121 has been loaded, the CPU remains in RUN.
This reference covers the root cause, the four standard recovery procedures, preventive controls, and the verification steps expected after the load.
Root Cause Analysis
What counts as an "interface change"?
An FB interface change is any modification to the INPUT (IN), OUTPUT (OUT), IN_OUT, or STATIC (STAT) sections of the FB declaration table. Adding a tag, removing a tag, changing a data type, reordering tags, or renaming a tag all trigger the warning. Edits inside the TEMP section do not count as interface changes because temporary variables exist only in the call stack of one OB/FB/FC invocation and are never persisted to the IDB.
| Declaration section | Persisted to IDB? | Triggers "load STOP" warning? | IDB regeneration needed? |
|---|---|---|---|
| INPUT (IN) | Yes | Yes | Yes |
| OUTPUT (OUT) | Yes | Yes | Yes |
| IN_OUT | Yes (passed by reference) | Yes | Yes |
| STATIC (STAT) | Yes | Yes | Yes |
| Multi-instance declarations | Yes (in parent IDB) | Yes | Yes (parent IDB) |
| TEMP | No (stack only) | No | No |
| Block parameters (FB, FC, DB, SDB, etc.) | No | No | No |
| Comments and title only | No | No | No |
Why the CPU transitions to STOP
The IDB on the CPU stores the runtime instances of every STAT, IN, OUT, and IN_OUT declaration. Each declaration occupies a fixed offset inside the IDB. When STEP 7 or TIA Portal downloads a new FB whose declaration layout has shifted (for example, a new BOOL added between two existing tags), the existing IDB becomes too short or its offsets no longer match the FB symbol map.
On the next call to the FB, the CPU executes L DBn.DBWx or T DBn.DBWx at an offset that lies beyond the IDB's actual length or at an offset tied to a renamed symbol. The access fails, the CPU logs a programming error in the diagnostic buffer, and – unless OB121 is present – the CPU transitions to STOP with the STOP and SF (System Fault) LEDs illuminated.
Technical Details: OB121, IDB Lifecycle, and Multi-instances
OB121 (Programming Error OB)
OB121 is the standard Organization Block executed by the S7-300/400 and S7-1200/1500 CPUs when an access error is detected during program execution. Loading OB121 does not erase the underlying fault; it intercepts the event so that the CPU does not transition to STOP. The diagnostic buffer still records the access error, and the CPU continues to the next OB scan. OB122 is the analogous OB for I/O access errors.
Single-instance versus multi-instance IDB
| FB instantiated as | IDB location | Regeneration command path |
|---|---|---|
| Single-instance (called from OB/FC/FB as a separate DB) | Standalone DB (named "InstDB" or numbered by user) | Delete IDB → cut/paste FB call to regenerate → save → download both |
| Multi-instance (called from inside another FB) | Block inside parent FB's IDB at a fixed offset | Parent FB and parent IDB must be regenerated and downloaded together |
| Called through an Instance DB with a fixed number | DB with explicit number (e.g., DB100) | Delete DB100 → re-instantiate call → confirm DB100 reused → download |
When the warning fires
The warning fires whenever STEP 7 / TIA Portal computes a new interface signature for the FB that differs from the signature stored in the existing IDB. The signature is a hash of the declaration layout. Any change in:
- Number of tags in IN, OUT, IN_OUT, STAT
- Data types of those tags
- Symbol names of those tags
- Order of declarations in those sections
- Initial values of STAT tags (changing only the initial value may still shift the signature on some firmware versions)
updates the signature and raises the warning on the next save. Renaming a tag also counts as a change because the symbol database inside the IDB is regenerated.
Solution Procedures
Procedure A – Bulk download with refresh of accesses (recommended)
- Finish editing the FB and click Save. Acknowledge the warning dialog by clicking Yes only when the remaining steps are ready; otherwise click No and complete the regeneration first.
- Open every block that calls the modified FB (OB, FC, FB). For each call site, right-click the FB box and select Check and update accesses (STEP 7 V5.x: menu File → Check and update accesses or right-click on call → Update; TIA Portal V13+: right-click on call → Update block call, or rebuild the project).
- Save each calling block after the refresh.
- In the project tree, multi-select the modified FB and its associated Instance DB (Ctrl/Shift-click both).
- Right-click and select Download to device → Software (all) in TIA Portal, or PLC → Download in STEP 7 V5.x.
- Confirm the multi-block download. STEP 7 transfers the FB and the freshly regenerated IDB in a single online session so the CPU never holds an inconsistent view of the program and its instance data.
Advantage of this procedure: every call site is automatically repointed at the regenerated IDB, the new IDB number (if it changed) is captured, and renamed/added/retyped tags are reflected in every block that referenced them.
Procedure B – Manually recreate the Instance DB
- In the offline project tree, locate the IDB associated with the modified FB. The name is typically InstDB<FB-name> in TIA Portal or the user-assigned DB number in STEP 7 V5.x.
- Right-click the IDB → Delete block. Confirm the deletion in the dialog.
- Open the block that calls the FB (OB/FC/FB). Cut the FB call instance from its network with Ctrl+X (or the block's cut command).
- Paste the FB call back into the same network. The programming tool re-instantiates the call and creates a new IDB sized to match the current FB interface. The new IDB may receive a new DB number.
- Save both the calling block and the new IDB.
- Multi-select the calling block and the new IDB and perform a bulk download.
Procedure C – Download while CPU is in STOP
- Switch the CPU to STOP via the programming software (Online → Stop) or via the mode selector on the CPU front panel.
- Observe the STOP LED and any SF/BF LED. Confirm that the CPU has reached STOP for the reason you intend to repair, and that the diagnostic buffer is clean except for prior programming errors you are about to fix.
- Download the modified FB and the regenerated IDB while the CPU is stopped.
- Issue Reboot (warm restart) or Cold restart as required before returning the process to production.
Procedure D – Load OB121 as a guard
- Add a new Organization Block in the project root.
- In the block properties, set the OB number to 121. The programming tool will automatically select the correct interface template for the programming error OB.
- Write the body: typically a single increment of a "ProgramFault_Counter" STAT or instance DB tag, plus any application-specific latching logic.
- Save the OB and download it to the CPU.
- Re-attempt the FB edit save and reload. The warning still appears, but the download will not stop the CPU because OB121 will absorb any access error.
Verification
- After downloading, switch the CPU to RUN.
- Open Online & Diagnostics → Diagnostics buffer. The most recent entry should be the warm/cold restart. Confirm there is no "Programming error, OB not loaded" entry and no access error against the modified FB's IDB.
- In an online watch table, read every STAT variable that was added, removed, or renamed in the interface. New tags should read
0on first scan, then the value set by the program. Tags that no longer exist should be reported as Invalid operand. - In TIA Portal, open Properties → Information → Interface signature on the FB. Compare the signature between the offline block and the online block – they must match.
- Open the network containing the FB call. Above the FB box, the IDB number is shown (for example,
DB20 ("InstDB_Motor")). Confirm that this matches the regenerated IDB and that any HMI/OPC references point at the same number. - Force a process scan by setting a known value on an IN parameter and verifying the OUT and IN_OUT parameters update as expected.
Troubleshooting Matrix
| Observed symptom | Likely cause | Remedy |
|---|---|---|
| Warning fires every save even though no tags were added | An automatic declaration change (e.g., the Auto-declare plug-in added a comment) shifted the signature | Set Auto-declare to manual, save, recompile |
| CPU goes to STOP on the next scan after download | IDB was not regenerated or was downloaded alone | Use Procedure A (bulk download) or Procedure B (recreate IDB) |
| Diagnostic buffer shows "Programming error, OB not loaded" | OB121 not present in CPU | Load OB121 using Procedure D |
| Newly added STAT variable reads 0 even after the program writes it | IDB was not regenerated and offset still maps to old symbol | Regenerate IDB via Procedure B |
| HMI tag shows wrong value after FB edit | IDB number changed and HMI is still pointing to old DB number | Update HMI tag DB number; or fix IDB number post-regeneration in TIA Portal |
| Warning fires after editing the parent FB only, not the child FB | Multi-instance change inside parent FB | Regenerate parent IDB; download parent FB + parent IDB |
| CPU was already in STOP before the download attempt | Independent STOP cause (hardware fault, wired STOP, OB82/85/86) | Read diagnostic buffer; clear root cause; then perform STOP download per Procedure C |
| Interface signature of online block does not match offline | Two engineers saved different versions; partial download | Re-compile project; cancel ongoing downloads; redo bulk download |
| Warning fires on the first ever save of a brand-new FB | First save creates the interface where none existed before | Expected behaviour – close the dialog with Yes, then instantiate the FB to generate the first IDB |
| FB edit triggers prompt for an unrelated FB | Symbolic references across the project were not refreshed | Compile project; "Check and update accesses" project-wide |
Differences Between STEP 7 V5.x and TIA Portal
| Step | STEP 7 V5.x | TIA Portal V13 and later |
|---|---|---|
| Save FB, acknowledge warning | Dialog "Beim Laden dieses Bausteins geht die CPU in STOP" | Equivalent English/localized dialog with link to help topic |
| Refresh call sites | Right-click call → Update; or menu File → Check and update accesses | Right-click call → Update block call; or full project compile |
| Regenerate IDB | Delete IDB, cut/paste FB call | Right-click FB → Instantiate; or full project compile |
| Bulk download | Multi-select FB + IDB → Download | Download to device → Software (all) – picks up dependents automatically |
| Load OB121 | Insert OB121 from Standard Library → Organization Blocks | Add new OB, set number 121, write body |
| Inspect interface signature | Block properties → Interface tab → Time stamp | Block properties → Information → Interface signature |
| Pin a fixed IDB number after regeneration | Manually assign DB number before re-instantiating | Use "Instance DB" with explicit number in the FB's call properties |
Edge Cases and Field Notes
Renaming a STAT tag only
If only a STAT tag's symbol is renamed (with no change in offset), STEP 7 still raises the prompt because the symbol resolution inside the IDB no longer matches the FB's interface. The IDB is logically inconsistent and must be regenerated. Otherwise the new symbol remains unresolved and any symbolic access in the project will compile against the new name while the IDB bytecode continues to reference the old one.
Editing an FB used as a library type
If the FB is reused as a master copy or library type in multiple projects, the prompt fires per project. Each project needs its own regenerate-and-bulk-download cycle. Plan a maintenance window for cross-project library updates and broadcast a single commit hash so every engineer regenerates from the same source.
F-CPU (fail-safe) behaviour
On an F-CPU (for example, S7-1500F or ET200SP F-CPU), F-FBs carry additional signature tracking. The prompt may be accompanied by an F-runtime-group inconsistency event. OB121 cannot suppress safety-related access errors; F-OBs follow their own lifecycle (F-OB100, F-OB121, F-OB123). Always regenerate the F-IDB and confirm the F-signature before download. Online safety mode may need to be disabled and the safety program re-validated.
HMI coupling
If an HMI tag or OPC UA node binds to a STAT variable in the IDB and that IDB is regenerated with a different number, all HMI/OPC references must be re-pointed. Build a matrix of (IDB number, STAT tag) before regeneration, and a matrix of (new IDB number, renamed STAT tag) after. Update the HMI/OPC configuration and retag the connections before the next panel refresh.
Bulk changes across many FBs
If you modify many FBs in a single maintenance window, regenerate the entire project tree top-down rather than per-FB. In TIA Portal: Compile → Software (rebuild all blocks). Then perform a single Download to device → Software (all) so every IDB is consistent before the CPU executes any of the calling OBs.
Concurrent engineering
When two engineers edit overlapping blocks in the same project, partial saves can leave the offline project with mixed signatures. The offline project must be compiled fresh (not just the offline/online differ check) before any download. Otherwise the prompt may fire on a block that the engineer did not modify.
Diagnostic Buffer Events to Watch For
| Event class | Trigger | Meaning |
|---|---|---|
| "Programming error, OB not loaded" | Access error with no OB121 present | CPU will transition to STOP |
| "Programming error, OB121 loaded" | Access error with OB121 present | OB121 absorbed the error; CPU stays in RUN |
| "STOP due to programming error" | STOP triggered by access error | Mode change event, with timestamp and OB121 missing flag |
| "Interface inconsistency DBn" | TIA Portal pre-load check (when enabled) | Offline IDB signature differs from FB signature |
| "Download block FBx" | Successful FB download | Logged with version, timestamp, and user |
| "Download block DBy" | Successful IDB download | Logged with version, timestamp, and user |
LED Indicators on Common CPUs
| CPU family | STOP | SF (System Fault) | BF (Bus Fault) if relevant | Notes |
|---|---|---|---|---|
| S7-300/S7-400 | Solid | Solid | Off (unless PROFINET involved) | RUN LED off |
| S7-1200 | Solid orange | Solid red | Flashing red if PN involved | MAINT may blink if firmware update pending |
| S7-1500 | Solid orange | Solid red | Solid or flashing red | MAINT red on F-CPU after safety STOP |
| ET200SP CPU | Solid orange | Solid red | Solid red | PWR LED green, no LINK/ACT on relevant port |
Prevention and Best Practices
- Pin fixed IDB numbers for production FBs so regeneration never changes the DB number that HMI or external clients bind to.
- Keep the FB's interface signature under version control (TIA Portal exports Interface tab or XML export). Promote a deliberate, reviewed, deliberate interface change through your normal change-management gate.
- Always bulk-download the FB and its IDB after any interface change. Never download a single block after an interface edit while the CPU is in RUN.
- Standardize interface layouts using UDT (User-Defined Data Type) in TIA Portal or DBT (Data Block Type) in STEP 7 V5.x. UDT-based STATs are migrated automatically when the UDT is recompiled.
- Keep OB121 loaded in development projects. Remove it (or load an OB121 that raises a non-resettable latched bit) in production only after confirming all IDBs are consistent.
- Lock the project with a password so inadvertent interface edits do not propagate.
- Schedule interface changes during planned downtime with a documented rollback plan that includes the previous FB and IDB versions.
Key Takeaways
- The "load STOP" prompt is informational: it tells you that an FB interface change has made the existing IDB inconsistent.
- The CPU only goes to STOP if it accesses the inconsistent IDB on the next call – which it will, unless the IDB has been regenerated and downloaded alongside the FB.
- The recovery path is always: regenerate the IDB and download it together with the FB.
- OB121 is a guard, not a fix. Use it as a development safeguard, never as a production mechanism.
- Bulk downloading the FB + IDB (Procedure A) is the safest, most repeatable recovery path. Manual IDB recreation (Procedure B) is the fallback when bulk download is unavailable.
FAQ
Does "the CPU goes into the STOP mode" mean the CPU will certainly stop?
No. The wording is a precaution: the CPU will stop if it accesses an IDB operand that no longer exists after the FB interface change. If you regenerate and download the IDB alongside the FB, or load OB121 first, the CPU remains in RUN.
Is changing a TEMP variable the same as changing the interface?
No. TEMP variables exist only on the call stack of a single invocation and are not stored in the Instance DB. Adding, removing, or renaming a TEMP variable does not raise the "load STOP" warning and does not require IDB regeneration.
Can I just download the FB without re-downloading the IDB?
Yes, the programming tool will allow it, but the old IDB will remain in load memory. The next call to the FB will then raise a programming access error. Either regenerate the IDB first and download it as part of the bulk download, or load the FB and regenerated IDB together.
Why does the warning appear even when I only create the FB the first time?
Creating an FB defines an interface where none existed before. STEP 7 treats the first save as an interface change from the empty prior state, so the warning fires once, on first save, even though no actual data has been lost yet. The first IDB is created when the FB is instantiated, either automatically by the compiler or manually by a call site.
What happens if I ignore the warning and click "Yes"?
The programming tool will proceed with the download. The CPU will hold the old IDB and the new FB until the next call to the FB, at which point a programming access error is logged to the diagnostic buffer. If OB121 is loaded, the CPU stays in RUN; otherwise the CPU transitions to STOP with the STOP and SF LEDs illuminated.