TIA Portal S7-1200 Block Monitoring Fails After Upload: Fix

Problem Overview

After performing Compare online/offline followed by Upload from device (CPU) in TIA Portal on a SIMATIC S7-1200 station, the project tree initially displays every object with a green comparison ball. As soon as the engineer opens any block (OB, FB, FC, or DB) to view or monitor its contents, the comparison state instantly changes from green to blue or orange, the Monitor on / Monitor off toggle becomes disabled, and live tag values can no longer be observed. The only practical recovery is a full download of the program back to the CPU, which forces a CPU STOP-to-RUN transition. On commissioning benches this is acceptable; on running production lines it is not.

This article documents the synchronization logic that causes the failure, the ball-color state machine an engineer must read, the official workflow to restore monitoring without losing the upload, and the strategies to deploy the same fix on a hot production CPU with the shortest possible stop window.

Symptoms and Visual Indicators

TIA Portal signals the integrity of the offline project against the online CPU through colored comparison balls at every node of the project tree (program blocks, tags, PLC data types, hardware configuration, watch tables, etc.). After an upload from a S7-1200 CPU, the engineer typically observes the following sequence:

1. Immediately after upload completes, every object shows a green ball. The portal reports the offline project and the online CPU are identical.
2. The user opens a block (double-click an OB, FB, FC, or DB). The portal performs an internal consistency check against the block container in the CPU.
3. The comparison ball on the opened block (and frequently on its parent folders) switches from green to blue if the offline copy is judged newer, or to orange if the online copy is judged newer. Monitoring becomes disabled because the offline container no longer matches the CPU's online container.
4. Clicking Go online shows the status bar message: "The offline project differs from the online CPU. Monitoring is not possible."
5. Repeating upload does not resolve the condition. Only a full project download clears the mismatch and re-enables monitoring.

Comparison Ball Color Reference

Root Cause: Online/Offline Synchronization Logic

SIMATIC S7-1200 CPUs and TIA Portal maintain two block containers: the offline container in the project on the engineering station, and the online container in the CPU's load memory. Each block carries a timestamp (load stamp) and a content checksum that TIA Portal uses for the comparison. According to the SIMATIC S7-1200 programming manual, when a project is downloaded to the CPU the engineering software records the synchronization state and can subsequently detect whether blocks or tags have changed in the online CPU since the last download. (See: Synchronizing the online CPU and offline project.)

The defect observed in the field arises from the following chain:

1. An earlier engineering session compiled a program and downloaded it to the CPU. The offline project was saved with the post-download timestamps.
2. Between sessions, the CPU retained the loaded blocks (in some firmware versions, plus remanent tags, plus any online-only objects such as data logs or recipes).
3. The engineer reconnects, runs Compare online/offline, and uses Upload from device. Upload replaces the offline blocks with the CPU's blocks and rewrites the offline timestamps to match the online ones. The comparison editor momentarily shows green because the binary content is the same.
4. The CPU's runtime system, however, has appended internal attributes to the loaded blocks that are not visible in the offline view: block run-time signatures, optimized-block access maps, and a re-numbered block interface generated when the block was last compiled on the engineering station. The upload did not refresh those hidden attributes in the offline database.
5. Opening the block triggers an internal re-compile / signature check. The offline container is then judged inconsistent with the online CPU, the ball flips to blue/orange, and monitoring is suspended by the portal's consistency guard.

State Machine of the Failure

Why Monitoring Fails After Upload

Monitoring in TIA Portal requires that the offline container's compiled view (the MC7 code, the interface description, the symbol table that the editor is showing) matches what the CPU is executing. When the comparison editor reports a mismatch, the portal refuses to project live values onto an offline view that may not correspond to the running program. The user-visible effect:

• Watch table: cells show "Invalid value" or "Status: not available".
• Block open in editor: the Monitor on button is grayed out; right-click → Monitor/modify is disabled.
• Force table: same effect as watch table.
• Trace: configuration shows the recording but the Start button refuses to arm.

The engineering-grade cure is to reconcile the containers, which in practice means a download. The objective of the workflows below is to do that reconciliation with the smallest possible footprint and, on a hot CPU, in the shortest possible STOP window.

Diagnostic Workflow

Before applying any fix, confirm the diagnosis:

1. Connect the engineering station to the S7-1200 CPU via the configured PROFINET or PROFIBUS interface. From the project tree, right-click the CPU → Go online.
2. Right-click the CPU → Compare online/offline → Start. The detailed comparison opens.
3. Note the ball color of Program blocks before opening anything. If all blocks are green, the symptom matches this article's scope.
4. Open any OB1 (or the first cyclic OB). Observe the ball color flip from green to blue/orange. The diagnosis is confirmed.
5. Open Online & diagnostics → Diagnostic buffer and record any stop/start events that occurred during the upload. This is useful for the customer-facing incident report.
6. Capture the CPU's firmware version from Online & diagnostics → General. Record it; it influences the workaround selection.

Solution: The Download-All Workflow

The reliable, repeatable fix that engineering teams have converged on is to perform the upload, then immediately compile and download-all while still online, before attempting to monitor any block. The portal then restores a clean offline-to-online alignment and monitoring is immediately functional.

Step-by-Step

1. Go online with the CPU. Verify the connection icon in the status bar is green.
2. Right-click the CPU → Compile → Hardware and software (rebuild all). Wait for the compile to complete with zero errors.
3. Right-click the CPU → Download to device → All. The portal prompts to overwrite. Confirm.
4. If the CPU is in RUN, TIA Portal offers the choice Stop and download or, where supported, Download in RUN mode. For S7-1200 the standard behavior is a STOP/RUN transition. Acknowledge and proceed.
5. After the download completes, the portal automatically reconnects online. The ball colors return to green.
6. Open any block. Confirm the ball stays green and Monitor on/off is enabled.
7. Open a watch table, click Monitor all, and verify live tag values are updating.

Why This Works

Compiling rebuilds the offline block container with current timestamps, fresh interface maps, and refreshed MC7 code that exactly matches the project's current configuration. Downloading pushes the freshly compiled container to the CPU, replacing both the previously uploaded copy and the residual internal attributes that caused the inconsistency. After the download, the offline and online containers are once again produced from the same compiled artifact, so the comparison engine judges them identical and enables monitoring.

Alternative Workarounds

Three additional approaches have been validated on S7-1200 stations. Choose by site conditions.

Workaround A: Targeted Block Re-compile

1. Right-click the individual block that flipped color → Compile → Software (only changes).
2. Right-click the same block → Download to device.
3. Repeat for each affected block. Faster than full download, but only effective when the comparison error is contained to a single block.

Workaround B: Detach Project, Re-attach Online Snapshot

1. Before uploading, snapshot the online CPU using Online & diagnostics → Save as to a separate project file.
2. Perform the upload into a clean copy of the project (do not reuse the original offline file).
3. Compile and download from the clean copy. The original offline archive remains untouched.

Workaround C: Close Project, Reopen Without Recent Cache

1. In TIA Portal, close the project.
2. Delete the project's .em_* cache files in the working directory if present (do not delete the .ap* project file).
3. Reopen the project and reconnect online. The portal rebuilds internal cache from the project file.

Production Site Strategies to Avoid PLC Stop

On a running production line, the customer's primary concern is the PLC STOP window caused by the download. Two structured approaches minimize that window.

Strategy 1: Pre-Sync on a Test Bench

1. Build an identical S7-1200 test bench (CPU type, firmware, signal modules, program size) and connect it to the engineering station.
2. Replicate the upload, compile, download sequence on the bench until monitoring is functional.
3. Save the resulting project as the production-source baseline. On site, only a download (not an upload-then-download) is needed, so monitoring will work on the first attempt.

Strategy 2: Live Download with Minimum STOP Window

1. During a planned short stop window, perform the upload.
2. Compile Hardware and software (rebuild all) while the line is still running. This step does not require STOP.
3. Coordinate a STOP — Download — RUN transition with the operator, ideally aligning with an existing machine pause to keep the stop window under 5 seconds.
4. Verify monitoring immediately after the transition. The diagnostic buffer will show one STOP/RUN entry attributable to the download.

Strategy 3: Hot Standby CPU

For critical process lines, deploy a backup S7-1200 CPU loaded with the matching project. Perform the upload and the test compile against the backup CPU. Then swap the backup into the live rack during the maintenance window, eliminating the compile-time risk from the production CPU's stop window.

TIA Portal Version Considerations

The defect has been reported across TIA Portal versions from V11 SP2 through V17. The probability of occurrence and the time to clear the inconsistent state have both improved with each major release:

If the site is running V11 or V12, plan a portal upgrade as part of the corrective action; the engineering time saved on every future upload pays back the upgrade within a few site visits. Always verify the upgrade target version supports the deployed S7-1200 firmware via the TIA Portal release notes before committing.

Best Practices for a Clean Online/Offline State

1. Establish a single source of truth. Maintain the canonical project on a version-controlled engineering server. Field laptops work from a checked-out copy and check in changes.
2. Avoid uploads into the master project. Upload to a dedicated snapshot project, compare, and only then promote changes to the master.
3. Compile after every structural change (new block, renamed tag, new data type) before going online.
4. Never edit online unless on a V15+ portal with documented online editing workflow. Online edits bypass the offline container integrity check and contribute to the kind of mismatch discussed here.
5. Lock the project file during commissioning windows to prevent parallel offline edits from corrupting the container.
6. Capture comparison reports weekly and store in the project archive; they are the diagnostic record if the defect reappears.

Verification Checklist

After applying any of the workflows above, verify each item before signing off the ticket:

• Comparison balls on all program blocks, tags, and PLC data types are green.
• Opening OB1, the first FB, the first FC, and the first DB does not flip any ball.
• Watch table shows live values for at least three process tags known to be changing.
• Force table accepts and applies a test force on a non-safety tag.
• Trace configuration arms and records (if trace is configured on this CPU).
• Diagnostic buffer shows no unplanned STOPs other than the one download cycle.
• CPU run-time remains in RUN with no fault LED.

Troubleshooting Matrix

Inline SVG: Recommended Workflow Topology

FAQ