S7-1500 TO Load Error 'Cannot Be Applied in RUN' Troubleshooting

Problem Description

On a SIMATIC S7-1500 / S7-1500T controller, an attempt to download project changes in RUN mode fails with the diagnostic message:

"Changes to the technology object cannot be applied in RUN"

The CPU drops out of RUN and the diagnostic buffer records an accompanying event:

"Temporary CPU error: Buffer overflow for OB 92 events — buffer size: 2 events, priority class 24 — Function will continue (system reaction)"

The same symptom has been reproduced on a CPU 1516-3 PN controlling nine SINAMICS S200 servo drives configured in PROFINET IRT with Motion Control technology objects (TOs). After every change to any DB or FC in the project, the load attempt is rejected and the CPU falls into STOP.

Field experience shows the error can be triggered even when the edit appears unrelated to motion: modifying an unrelated DB or FC can re-instantiate an MC_Power block, which TIA Portal classifies as a change to a currently active TO.

Affected Hardware, Firmware and Software

Root Cause #1 — MC_Power (or MC_TorqueLimiting) on an Active TO

The most common root cause is documented in Siemens FAQ 109781646:

A changed (instance) data block cannot be loaded in RUN if it contains instance data of an MC_Power instruction and the associated axis is enabled.

Mechanically, every time a MC_Power instance DB is recompiled (for example because the engineer edited an unrelated part of the same FB or a higher-level FC), the technology object flags the change as a TO-level modification. The CPU compares the online and offline project, sees a delta on the active TO, and refuses the load to prevent a runtime inconsistency between the motion kernel and the user program.

Why unrelated edits trigger this

• The PLC re-uses the same instance DB for MC_Power across multiple callers.
• Adding a tag, comment, or a small ladder rung in a parent FC alters the DB layout, and TIA Portal marks it "modified."
• The TO has no concept of "unrelated" change: from its perspective the instance DB has changed and the axis is enabled, so the load is unsafe.

Root Cause #2 — PROFINET IRT Send-Clock and Sync-Domain Mismatch

A second, less obvious root cause is a misconfigured PROFINET IO IRT sync-domain send-clock. In the validated 9-axis S200 application, raising the send-clock from 1 ms to 4 ms eliminated the error entirely with no other change to the logic.

Why this happens:

1. At 1 ms send-clock, the motion kernel generates an OB 92 (servo) event per drive per bus cycle.
2. Nine drives × 1 kHz = 9 000 events/s arriving in the OB 92 event queue.
3. The default OB 92 event buffer holds only 2 events per priority class (matches the diagnostic message).
4. When TIA Portal issues a download, it briefly stalls the bus, the queue overflows, and the CPU classifies the overflow as a TO-level inconsistency — surfacing as "Changes to the technology object cannot be applied in RUN."
5. Switching to 4 ms (or 2 ms if the application timing permits) drops the event rate by a factor of 4, keeping the queue healthy during the load window.

Root Cause #3 — OB 92 Buffer Overflow

The OB 92 buffer overflow is a symptom, not a cause, but it correlates strongly with the TO load error. Per the Siemens FAQ 109973555 (referenced in the original engineering discussion), the OB 92 event queue is dimensioned for short bursts only. If the queue overflows, the system reaction is to mark the TO as "config-changed" and abort the RUN download.

The overflow reaction "Function will continue (system reaction)" is intentionally non-fatal so that the axis does not hard-stop on a transient queue spike, but it does leave the TO in a state where the next load attempt is refused.

Diagnostic Procedure

Follow this sequence before changing any setting:

1. Go online with the CPU in TIA Portal.
2. Open Project tree → Technology objects and look for the yellow warning triangle on any TO icon. Any TO showing a warning or error must be acknowledged before further investigation.
3. Open Diagnostics → Diagnostic buffer and filter for "OB 92" and "Technology object".
4. Read the current PROFINET sync-domain send-clock: Devices & networks → PROFINET subnet → Properties → Sync domains.
5. Read the current MC_Power enable state: online → <TO> → StatusWord. Bit StatusWord.X0 (Operational) = 1 means the axis is enabled.
6. Compare online vs. offline: Right-click the CPU → Compare → Online/offline. Look for any instance DB flagged as "modified."
7. Cross-check the MC_Power.Enable and MC_Power.StartMode tags in the affected instance DB. If a change is present, the load will be refused.

Resolution Steps

Resolution A — Eliminate the MC_Power Instance-DB Change

1. Disable the axis (MC_Power.Enable := FALSE) or call MC_Stop followed by MC_Reset before the download.
2. Use Download to device → Consistent download of all blocks instead of "Download selected blocks."
3. If the change is to a non-motion DB, move the MC_Power call to a dedicated, rarely-edited FC and put the MC_Power instance DB in its own optimized block.
4. Enable Compile with → "Recreate optimized block interfaces" only when strictly necessary; each reset re-baselines the instance DB and can be falsely flagged as a TO change.

Resolution B — Adjust the PROFINET IRT Send-Clock

1. Open Devices & networks → PROFINET IO → Properties → Sync domains → Send clock.
2. Increase the send-clock from 1 ms to 2 ms or 4 ms. Valid S7-1500 IRT send-clocks are 0.25, 0.5, 1, 2, 4, and 8 ms.
3. Re-assign the Servo cycle of each TO (TO → Hardware → Servo) to an integer multiple of the new send-clock. For S200 the typical pairing is 4 ms send-clock ↔ 4 ms servo cycle, or 1 ms send-clock ↔ 1 ms servo cycle.
4. Re-validate all motion tuning (Kv, filter times, following error) — a slower cycle changes control-loop dynamics.
5. Recompile the project and perform a full download in STOP, then transition back to RUN.

Resolution C — Address OB 92 Overflow

1. Confirm firmware ≥ V2.9 on the CPU (later firmware enlarges the OB 92 queue).
2. Reduce the number of TOs that generate servo events in the same sync domain by splitting the project into multiple sync domains if the application allows.
3. Avoid background tasks (HMI tag polling, web-server scraping) during commissioning, because they can stall the bus and amplify the overflow.
4. Per FAQ 109973555, install the OB 92 event-buffer handling FB and the supplementary diagnostic block from the Siemens FAQ package.

Verification

After applying any of the resolutions above, verify the fix as follows:

1. Bring the CPU online and confirm no yellow triangles on any TO icon in the project tree.
2. Make a benign edit (for example, add a comment inside a non-motion FC).
3. Trigger Download to device → Software (only changes) while the CPU is in RUN.
4. Confirm the load completes without the "Changes to the technology object cannot be applied in RUN" dialog.
5. Re-read the diagnostic buffer; there should be no new OB 92 buffer-overflow entry.
6. Run a controlled motion profile (jog to a test position, then a positioning command) and confirm following error and status bits match the pre-change behavior within the expected tolerance band.

Field-Proven Tips for Multi-Axis Systems

• Limit the number of axes per PROFINET IRT sync domain to ≤ 8 for commissioning convenience, even if the controller supports more. Splitting helps localize overflow events.
• Use consistent download for the first commission, then revert to "Download changes only" for normal operation.
• Disable the "Recompile all blocks" option in TIA Portal when the goal is only to update a tag — it forces unnecessary instance-DB regeneration.
• For each MC_Power instance, place it in a dedicated, separately compiled FB so an edit to the main process logic does not regenerate the motion instance DB.
• Document the active send-clock and servo cycle in the project header; a change to these values is a TO-level change and will require a STOP download.
• Keep the TIA Portal version aligned with the SINAMICS S200 support package (SSP) version. Mismatches can surface as TO load errors even when the configuration is sound.

Related Configuration Pitfalls

The TIA Portal V20 status and error bits documentation lists the bit-level meaning of every error that can leave a TO in a non-loadable state, including the configuration-error path that is often the underlying cause of an OB 92 overflow on multi-axis systems.

When to Escalate to Siemens Support

If all three resolutions above do not clear the error, escalate with the following bundle:

1. The TIA Portal project (with the password if protected).
2. The exact text of the diagnostic buffer entries (TXT export).
3. The CPU order number (e.g., 6ES7516-3AN02-0AB0) and firmware version (read from the online diagnostic).
4. The TIA Portal version and installed Support Packages / SINAMICS S200 SSP version.
5. A list of the most recent edits and the corresponding TIA Portal change log.

Siemens Technical Support can compare the project against the internal consistency model of the motion kernel and identify the exact TO attribute that is changing during a download.

FAQ