Resolving S7-400 CPU 416-2DP Offline/Online Block Differences

1. Problem Summary

An installation with four SIMATIC S7-400 CPU 416-2DP controllers networked via fiber-optic PROFIBUS reports an offline/online block comparison mismatch. Several FB and one FC — all originally written in SCL — are flagged as different, even though the engineer never intentionally edited them. The comparison dialog shows the message: "The comparison was performed in STL because of the different programming languages!". Visual inspection reveals only that the label names on jump instructions differ while the surrounding STL instructions appear byte-for-byte identical.

A 10-minute UPS outage one month earlier raises the question of battery-backed RAM corruption. This article walks through the diagnostic procedure that separates a harmless SCL-to-STL compilation artifact from a genuine missed download, and shows how to confirm the last successful download timestamp from the CPU diagnostic buffer.

2. Root Cause: SCL Compiler Generates Internal Labels

SCL is a Pascal-like high-level language. When you save an SCL block, the SCL compiler translates the source into STL/MCW (machine code word) instructions that the CPU executes directly. The compiler inserts internal symbolic labels — conventionally named _001, _002, _003 and so on — together with conditional (JC) and unconditional (JU) jumps to implement IF, CASE, FOR, and WHILE constructs.

These labels are regenerated every time the SCL source is recompiled. The label sequence depends on:

• The exact SCL source text — even whitespace changes inside a structured statement can shift the next label index.
• The SCL compiler version — STEP 7 / SCL service packs can assign different label prefixes or re-order branches.
• The order of variable declarations — temp-stack offsets can change how the compiler inlines range checks.

When STEP 7's offline/online comparator opens an SCL block, it cannot compare the original SCL source if the online image is stored as compiled STL/MCW (which it always is). It re-opens both sides in STL view, where the symbolic jump targets appear as numeric or generic labels. The comparator then flags every label name difference even though the program logic is functionally identical.

3. Distinguishing Real Drift from Cosmetic Differences

Open the comparison window (Options > Compare Blocks Online/Offline in SIMATIC Manager, or right-click the S7 program > Object Properties). Use the Details tab to inspect four independent properties of every block:

Decision rule:

1. Code timestamp newer offline than online + any block differs → the block was edited offline but never downloaded. This is genuine drift, and the most likely explanation when remote-assistance vendors touched the project.
2. Code timestamp identical + only jump labels flagged → cosmetic. No action required unless you want to silence the warning.
3. Code timestamp older online + SCL source recompiled on the ES → an external tool re-saved the SCL source without downloading, regenerating labels. Decide case-by-case whether the new labels correspond to identical logic.

4. Step-by-Step Diagnostic Procedure

Perform the following sequence on each of the four CPUs in the fiber-optic ring. Do not skip steps: a clean diagnostic is the only way to avoid a process interruption triggered by an unnecessary download.

4.1 Open Online View

1. In SIMATIC Manager, expand your S7 project and right-click the first CPU 416-2DP.
2. Select Online > Accessible Nodes (or "Open Online" if the PG already has the online connection profile for this CPU).
3. Confirm the PG is connected to the correct CPU via MPI/PROFIBUS or Ethernet. Use PLC > Operating Mode to verify the CPU is in RUN or RUN-P. Record the mode-switch position.

4.2 Launch Block Comparison

1. Select the Blocks container in offline view.
2. Choose Options > Compare Blocks.
3. In the comparison dialog, tick both Offline and Online paths and click Compare.
4. The result window lists every block with status "Identical" or "Different". For a first pass, count the differing blocks; a count above ~5 should always trigger the full procedure below.

4.3 Drill into "Different" Blocks

1. Double-click any block flagged "Different" to open the side-by-side editor.
2. STEP 7 will display the block in STL on both sides and emit the warning: "The comparison was performed in STL because of the different programming languages!". This message is expected for SCL blocks and is not by itself an error.
3. Switch to the Details tab. Record for each flagged block:
   • Offline timestamp (Code / Interface)
   • Online timestamp (Code / Interface)
   • Offline length in bytes
   • Online length in bytes

4.4 Read Block Header Checksum

1. Close the comparison editor.
2. Right-click the flagged block offline > Object Properties.
3. Open the "Compile / Download" tab. The CRC of the compiled MCW is shown. If your project was compiled with SCL Generate Reference Data, you can also read the online CRC via PLC > Download User Program to Memory Card dialog — in read mode, do not write.
4. Equal CRC + equal length + only label-line differences = cosmetic. Different CRC = genuine code change.

5. Reading the Last Download Timestamp from the CPU

SIMATIC S7-400 CPUs do not expose a single "last download" field directly, but the diagnostic buffer records every download event with its timestamp.

1. With the PG online to the CPU, select PLC > Diagnostic Buffer (or press Ctrl+D).
2. Locate the event list. In most firmware versions the most recent entries are at the top. Search for:
   • Event ID W#16#4301 — informational, "Download of user program to CPU completed"
   • Event ID W#16#4302 — "Download of system data completed"
3. The entry's timestamp shows the most recent successful download. Compare it with the file modification date of your offline project to confirm whether a download actually happened since the suspected remote-assistance session.
4. For a complete record, also capture PLC > Save Service Data. The resulting *.zip archive contains the full diagnostic buffer, the diagnostic status, the memory configuration, and the OB/PII/PIQ snapshot — invaluable if a memory reset is ever required.

6. Resolution

6.1 If differences are cosmetic (label-only)

1. Do not download. Doing so unnecessarily stops the CPU and erases non-retentive process state.
2. Document the finding in the change log: "SCL recompile produced new internal labels; program logic unchanged."
3. Optionally re-archive the offline project so the next engineer sees consistent timestamps.
4. Disable STEP 7's auto-recompile (Options > Customize > Compile = "Always ask") so future opens do not silently mutate the compiled code.

6.2 If differences are real code changes

1. Identify the source of the change. In the scenario described, remote-assistance engineers often edit SCL on a service laptop, save offline, but never click PLC > Download because they assume the change is non-functional.
2. Decide whether the change should be deployed. If yes:
   • Save current process values (or trigger a clean stoppage window).
   • Place CPU in STOP via PLC > Stop or the mode switch.
   • Select the changed blocks in offline view, right-click > Download to Target System. STEP 7 will prompt to overwrite existing blocks; confirm.
   • Switch CPU to RUN and monitor diagnostic buffer for OB100 / OB101 / OB102 warm restart events.
3. If no, revert the offline SCL source from the PLC by dragging the online block back to the offline project: right-click the online block > Copy, then right-click the offline container > Insert. Re-open in SCL to verify the source.

6.3 If differences involve pointer instructions

If any of the differing rungs uses pointer arithmetic (P#, LAR1, TAR1, LAR2, ANY, POINTER, or VARIANT), the SCL compiler may generate different MCW depending on how it traces pointer liveness. In this case the comparison genuinely reflects different code paths and the safest action is to copy the online version back into the offline project and not download from offline, preserving the version actually running.

6.4 Forced recompile workaround

If the engineering station must remain synchronized with the running CPU without a download, force the SCL compiler to regenerate the labels so they match online:

1. Open the SCL source offline.
2. Make any cosmetic edit (e.g., insert a space) and save — this triggers a fresh compile.
3. If the labels still differ, the online version was compiled with a different SCL version. Match the SCL add-on package on both engineering stations.

7. Multi-CPU Fiber-Optic Ring Considerations

The reported installation uses four CPU 416-2DP interconnected via fiber-optic PROFIBUS DP (typically with OLM/ELM fiber modules or, more commonly today, SCALANCE XC/XB/XR switches with fiber ports). When comparing blocks across multiple CPUs, remember:

• Each CPU has its own online image. A download to CPU 1 does not propagate to CPUs 2–4. Repeat the comparison on every CPU before declaring the system consistent.
• Fiber-optic ring self-healing: A break in one segment causes the ring to reconfigure (~30 ms for SCALANCE X redundancy mode). CPU diagnostic buffers on the master may show DP slave failure / return events during this window. These events do not indicate a program change.
• Time synchronization: If the four CPUs synchronize via PROFIBUS master-master or via SIMATIC time-of-day frames, ensure one CPU is the time master; otherwise timestamps drift and chronological interpretation becomes unreliable.
• Diagnostic buffer interleaving: When paging through each CPU's diagnostic buffer, events appear under that CPU's local time stamp. Always record which CPU you were connected to for each event, otherwise chronological reconstruction becomes impossible.

8. Battery / UPS Failure Scenarios

The original poster mentioned a one-month-old 10-minute UPS outage. S7-400 CPUs use a lithium backup battery (typically 3.6 V, 2.3 Ah; catalog 6ES7971-0BA00) to retain:

• Retentive M, T, C, and DB areas
• Real-time clock
• Diagnostic buffer entries that are not power-loss markers
• Counters and operating-hours values

The user-program block work memory, however, sits on the integrated RAM (or RAM card for early CPU 416 variants). A battery failure during a power loss would normally erase the loaded user program; the CPU would fault (SF LED on, STOP with diagnostic buffer entry "Battery exhausted / Back-up battery discharged"). The CPU would then fail to return to RUN with the original logic unless an MMC or RAM card with the project was inserted, or a new download was performed.

Because the user's CPUs came back up and are executing the program — and only label names appear different, not entire logic — battery exhaustion is not a credible cause. Confirm this by reading PLC > Module Information > Diagnostics and verifying that no BATTF / BAFF1 / Battery Fault event is logged within the relevant timeframe. The diagnostic buffer event ID for a battery fault is W#16#4307.

9. Prevention and Engineering Workflow

1. Use STEP 7 version control or a shared archive. Even a directory-based timestamped ZIP archive (one per change-set) prevents divergence between engineering stations.
2. Disable auto-recompile. STEP 7's automatic recompile on open silently regenerates labels. Set Options > Customize > Compile to "Always ask" so unintentional saves do not mutate compiled code.
3. Establish a download gate. Any SCL change must end with a documented PLC > Download action whose result is logged. Remote-assistance laptops should connect to the engineering workstation over a version-controlled remote session, never edit local copies.
4. Schedule quarterly comparisons. Run Options > Compare Blocks Online/Offline on every CPU as part of preventive maintenance. Document results.
5. Capture the diagnostic buffer before and after every change. File PLC > Save Service Data with the project timestamp.
6. Match SCL compiler versions across engineering stations. Different SCL add-on packages produce different label schemes. Pin the SCL version in your engineering standard.

10. Frequently Asked Questions