S7-1500 TIA Portal Auto-Restart on Online Download Fix

S7-1500 TIA Portal Auto-Restart on Online Download Fix

When TIA Portal performs an online download of program changes to a running SIMATIC S7-1500 (or S7-1200) CPU, the controller can perform an unprompted warm restart. The most frequently confirmed root cause on production machines is that the additional CPU load generated by the online delta-load exceeds the configured maximum cycle time (OB1 watchdog) and crosses the hardware-level STOP threshold. This reference describes the mechanism, the diagnostic procedure, the firmware matrix, and the engineering workarounds used to keep a process online while editing.

1. Problem Description

Two distinct behaviors are reported by engineers:

1. Historical behavior (TIA Portal V13-V16, default): The "Download to device" wizard displays a preview dialog with a checkbox labeled "Stop and restart target modules." The user can uncheck the box or cancel the download to defer changes.
2. Current behavior (TIA Portal V17-V19, default): The download completes without prompting. The CPU momentarily transitions to STOP, performs an internal re-initialization (RUN-to-STOP-to-RUN), and resumes operation. The "Load preview" dialog reports no module stop, yet the plant was in fact restarted.

The second behavior is what field engineers notice: an unexpected plant stop with no human action. Operators see the S7-1500 status LEDs transition RUN (green) → STOP (yellow) → RUN (green) within 2-4 seconds, and the SCADA alarm buffer fills with "PLC communication lost / restored" entries.

2. Affected Hardware and Firmware

Engineering software: TIA Portal V15.1, V16, V17, V18, V19. The behavior is reproducible across versions; it is driven by the firmware-side download handler rather than the TIA Portal wizard.

3. Root Cause: OB1 Cycle Time Exceeded During Delta-Load

The S7-1500 firmware uses a two-tier watchdog on OB1 (the cyclic main program):

The TIA Portal online delta-load process performs the following CPU-side operations during a typical program change to a single FB or DB:

1. Suspend cyclic OB1 execution.
2. Re-route references in the active program image (this consumes CPU time proportional to the number of tag references to the modified FB/DB).
3. Re-initialize instance DBs and the modified code blocks.
4. Resume OB1 execution.

Steps 2 and 3 are not instantaneous. For an S7-1500 CPU 1515-2 PN with a heavily referenced global DB (for example, a recipe DB read by 40-60 FBs and 10 HMI tag connections), the firmware can spend 250-600 ms in the re-route step. If the configured maximum cycle time is 150 ms, the "2 ×" hard-stop threshold is 300 ms — easily crossed. The CPU drops to STOP with diagnostic buffer event "Time error (OB not executed within the maximum cycle time)" and re-enters RUN automatically if the restart-on-error bit is enabled in the CPU properties.

4. How Online Download Affects CPU Cycle Time

The cycle-time penalty of an online download scales with three variables:

1. Number of tag references to the modified block. Renaming a tag in a DB that is read by 80 blocks multiplies the re-route work by 80.
2. Type of change. Adding a new tag has higher cost than changing a constant. Changing a tag's data type (e.g., INT to DINT) forces re-compilation of every block that references it.
3. HMI / OPC UA / Web server subscription footprint. Each subscribed tag forces a publisher update. S7-1500 OPC UA server and integrated Web server both re-publish on delta-load, which costs additional OB1 time.

Realistic field-measured penalty on a CPU 1515-2 PN (firmware V3.0):

5. Diagnostic Procedure

Follow this sequence on the affected CPU. All steps require TIA Portal with the project open and a live online connection to the CPU.

5.1 Read the diagnostic buffer

1. In the project tree, right-click the CPU → Online & diagnostics.
2. Open Diagnostics > Diagnostic buffer.
3. Sort by time (newest first). Look for events that occur immediately before the CPU STOP event.

The diagnostic buffer will contain entries similar to:

If you see 16#3501 immediately preceding a STOP/RUN pair, the cycle-time theory is confirmed.

5.2 Read the actual cycle time

1. Right-click CPU → Online & diagnostics > Diagnostics > Cycle time.
2. Note Current cycle time, Minimum cycle time, and Maximum cycle time.
3. Compare current and maximum against the configured OB1 maximum from the CPU properties → Cycle time tab.

If the maximum cycle time approaches or exceeds 2 × the configured OB1 maximum, you have confirmed the cause.

5.3 Capture the OB1 re-route trace

1. Open Online & diagnostics > Trace.
2. Create a trace recording OB1.MeasuredCycleTime, OB1.MaximumCycleTime, and OB1.MinimumCycleTime at a 10 ms sampling rate.
3. Trigger the trace on a rising edge of OB1.MinimumCycleTime or record continuously while you perform a small online download.
4. Observe the cycle-time spike at the moment of download. A 200-500 ms step on a 150 ms baseline is the signature of the problem.

6. Solution A: Raise the OB1 Maximum Cycle Time

The most direct fix. Open the CPU device configuration in TIA Portal and adjust the maximum cycle time on the S7-1500:

1. Open Devices & Networks, double-click the CPU.
2. Select Properties > Cycle time.
3. Change Maximum cycle time from 150 ms to a value that is at least 2 × your measured peak cycle time plus the delta-load penalty. Typical production values: 400 ms, 600 ms, or 1000 ms.
4. Compile and download (with STOP if necessary).

Recommended formula for headroom:

Configured OB1 max ≥ (Measured steady-state cycle time) + (Measured delta-load penalty) + 50 ms safety margin

For a process with a 50 ms steady-state cycle and a 220 ms delta-load spike, set the OB1 max to at least 50 + 220 + 50 = 320 ms. Round up to the nearest standard value: 400 ms.

7. Solution B: Reduce the Online Change Surface

The delta-load penalty scales with the number of references to the changed block. Reducing that surface is the most sustainable long-term fix.

7.1 Isolate heavily referenced DBs

Identify global DBs with more than 20 read references. Move them out of the "common parameters" pattern by splitting:

• Static parameter DB: configuration tags, changed rarely.
• Dynamic recipe DB: runtime values, changed frequently but isolated to a small block of consumers.
• HMI mirror DB: tags specifically published to HMI/OPC UA, referenced only by the publisher block.

This reduces the fan-out of any single edit.

7.2 Avoid data-type changes to existing tags

Changing the data type of an INT to a DINT forces re-compilation of every block that references it. Add a new tag with the new type and migrate consumers block by block.

7.3 Use the spare-tag strategy

Pre-allocate a pool of unused tags in each heavily referenced DB:

// Spare tag pool (allocate once, never rename until safe window)
SpBool01 : Bool;    // spare
SpBool02 : Bool;
SpInt01  : Int;
SpInt02  : Int;
SpDInt01 : DInt;
SpReal01 : Real;
SpString01 : String[32];

When a new tag is needed at runtime, edit the consumer to reference a spare (e.g., MyDB.SpInt01). During a planned maintenance window, rename the spare to its final semantic name and download — the rename then has zero reference churn because all consumers already point to it.

7.4 Use the dual-DB pattern for cold-swap migrations

For larger refactors:

1. Create a new DB (e.g., DataLog_v2) with the new structure.
2. Add synchronization logic between DataLog_v1 and DataLog_v2 in OB1.
3. Migrate consumer blocks one at a time to read from v2.
4. Once fully migrated, delete v1 during a planned shutdown.

This pattern is painful but keeps the running process safe.

8. Solution C: Move Edits to a Test CPU

For changes that affect many blocks, never edit the production CPU online:

1. Maintain a bench CPU of the same article number and firmware version.
2. Replicate the production project to the bench CPU.
3. Build, compile, and download to the bench CPU first.
4. Validate the cycle-time penalty via Trace on the bench CPU before staging the change to production.
5. On production, perform the download only during a planned maintenance window.

For very large projects, use S7-PLCSIM Advanced to simulate the cycle-time penalty without hardware.

9. Verification Procedure

After applying Solution A (raised OB1 maximum) or Solution B (reduced references), verify the fix:

1. Open the online diagnostic buffer and clear it (mark all entries as read).
2. Open the cycle-time Trace configured in Section 5.3.
3. Perform a representative online download — ideally the change that previously caused the stop.
4. Confirm:
• No new 16#3501 (time error STOP) entry appears.
• OB80 may fire (warning), but no STOP follows.
• Cycle-time trace shows a spike that stays below 2 × the configured OB1 maximum.
• Plant did not transition STOP ↔ RUN.
5. If the cycle-time spike still approaches 2 × the OB1 maximum, increase the OB1 maximum further or apply Solution B.

10. TIA Portal Download Settings Reference

Engineers often miss the project-level settings that influence this behavior. Open Project > Properties > Protection > Download to device and verify:

11. Related Organization Blocks and Diagnostic Events

The S7-1500 firmware uses several OBs to react to cycle anomalies. Knowing these prevents misdiagnosis.

OB80 is your early-warning. If OB80 fires repeatedly without an OB80-empty program in the CPU, the cycle-time budget is too tight. Add OB80 to the project and instrument it (set a flag, increment a counter) so the diagnostic buffer plus a custom UDT tag tells you when warnings accumulate.

12. Process Safety and Interlock Considerations

Even with the fix applied, every online download carries residual risk. Best practice for production lines:

1. Disable all safety outputs via the safety program before downloading if the change affects FB/FC code in the safety-related part of the project. S7-1500F CPUs (e.g., 6ES7516-3FN02-0AB0) will reject a delta-load to the safety program while the F-runtime is active; you must STOP the CPU.
2. Place the line in a controlled, non-running state before any change that touches the OB1 watch or any DB referenced by motion control (TO, MC_Power, MC_MoveJog, etc.). Motion OB91 (servo) isochrony cannot survive a STOP transition.
3. Maintain a written MOC (Management of Change) record including the firmware version, TIA Portal version, OB1 max before/after, and the diagnostic buffer snapshot.
4. Validate with a controlled dry-run on a test CPU of identical article and firmware to verify the cycle-time penalty before production download.

13. Firmware-Specific Notes

Always check the firmware release notes before applying the change. Siemens publishes firmware release notes in the Siemens Industry Online Support portal under the article number of the specific CPU.

14. FAQ