TIA Portal Online Compare: Why Green Dots Miss Hardware Changes on ET 200SP Modules

Problem Overview

When an automation engineer changes the output type of a SIMATIC ET 200SP analog output module from 4...20 mA to 0...10 V inside TIA Portal, compiles the project, and downloads it to the S7-1500 CPU, every diagnostic dot in the project tree turns green after the download completes. The TIA Portal offline/online comparison therefore reports no differences. The engineering station is disconnected from the controller, and a colleague subsequently edits the same output range back to 4...20 mA in the offline project. When the original engineer reconnects and runs the comparison again, the dots are still green. The PLC diagnostics buffer carries no entry indicating that the offline project and the running system are now in disagreement.

This article documents the root cause of that behavior, the precise data classes the offline/online comparison covers, the firmware constraints that govern full hardware upload on S7-1200 and S7-1500 CPUs, and the field procedures that close the gap when third-party engineers, contractors, or older controller firmware versions are in play. The article targets engineers responsible for change control of TIA Portal projects that include ET 200SP distributed I/O stations.

Hardware Context: SIMATIC ET 200SP Analog Output Module 6ES7135-6HB00-0CA1

The module referenced in the field incident is the SIMATIC ET 200SP analog output with article number 6ES7135-6HB00-0CA1. The module is a member of the ET 200SP distributed I/O family and supports per-channel output type selection inside the TIA Portal device configuration: voltage ranges (commonly 0...10 V or bipolar variants) and current ranges (commonly 0...20 mA and 4...20 mA). The selection is made in the module properties under Outputs > Output type and Output range at the channel level.

Because the operating mode is a property of the device configuration rather than a property of a code block, the parameter lives in the system data of the CPU and is treated by TIA Portal as configuration metadata, not as program code. The CPU only returns this metadata to the engineering station when the engineering station performs a deliberate Upload from device action. A passive online session (monitor mode, compare offline/online) does not transmit the active device configuration back to the PG.

Engineers familiar with STEP 7 V5.5 should note that the TIA Portal architecture inherits the same directionality rule: hardware configuration is treated as authoritative on the PG side, and the CPU acts as a runtime cache of the last downloaded system data. The online comparison therefore reports parity with the most recent download, not with whatever the CPU's configuration currently looks like if it diverges from that snapshot.

Root Cause: What the Offline/Online Comparison Actually Verifies

The TIA Portal offline/online comparison path compares the compiled project artifacts on disk with the runtime artifacts that the CPU returns during a passive online connection. The set of artifacts that participate in the comparison includes:

• OB, FB, FC, and instance DB blocks (the load memory image of the user program)
• PLC tags and tag tables
• Watch tables and force tables when uploaded back
• Hardware configuration stored as system data in the CPU
• PLC alarm text libraries and webserver pages where configured

The CPU does not automatically push its current hardware configuration back to the PG during a passive online session. The CPU responds to read requests for the active program and the active system data block, but the diagnostic status indicators (the colored dots in the project tree) are derived by comparing the most recently compiled offline configuration against the system data block that the CPU holds as a result of the last successful download. The PLC's stored configuration matches the comparison baseline because the baseline is the last download.

If the PG is then modified offline, those edits live only on disk. Until a download occurs, the CPU continues to hold the old system data. Re-entering the online view re-runs the same comparison and shows all green because the PG offline project now matches the snapshot that originally produced the comparison baseline, and the CPU still holds that snapshot.

The more dangerous case arises when hardware parameters are changed on the CPU itself, for example by a second programmer using a different TIA Portal project who downloaded a different revision, or by an SD-card image restore, or by a vendor service engineer who performed a partial download. In that case the PG cannot see those changes through a passive online comparison. Only an explicit Upload from device of the hardware configuration brings the new state into the PG, where it can be diffed against the original offline project.

The diagnostic dots in the project tree therefore represent software parity, not system parity. Treating them as the latter is the root cause of the field incident described above.

Three Comparison Paths in TIA Portal

TIA Portal exposes three distinct comparison operations. Engineers who assume the offline/online comparison covers the entire project are routinely surprised when the offline/offline path reveals data that the green dots ignored.

TIA Portal Comparison Operations and Scope

Comparison Type	Path	Scope	Direction	Use Case
Offline / Online	Project on disk vs. CPU snapshot	Compiled project + system data last downloaded	PC → PLC (read-only request)	Quick sanity check after download
Offline / Offline	Project A vs. Project B (two TIA Portal instances or project compare)	Entire project contents, including device configuration	PC internal	Detecting drift between backup and current project
Online / Offline	Uploaded snapshot vs. current offline project	Full hardware configuration + software	PLC → PC (explicit upload)	Recovering when the PG project is suspected to be stale

The TIA Portal V20 documentation: Comparing offline/online describes the first row of this table. The help text states that the comparison lets you compare objects of a device with objects of a project, and that the project tree must be open. The help does not state that the CPU returns its currently active hardware configuration in response to a passive online connection; it returns the configuration that was downloaded to the CPU as system data.

For full hardware parity verification, engineers must use either the offline/offline path (comparing two PG-resident projects) or the online/offline path (after performing an explicit upload into a new station object). Both paths are heavier than a passive online check, but they are the only paths that produce a true hardware parameter diff.

Firmware Constraints for Hardware Upload

The capability to upload the full hardware configuration, including the device parameters of distributed I/O such as ET 200SP, has evolved across S7-1200 and S7-1500 firmware generations. The table below summarizes the constraints that affect the incident.

S7-1200 and S7-1500 Hardware Configuration Upload Capabilities

CPU Family	Firmware Range	Hardware Upload Supported	Notes
S7-1200	Firmware < V3.0	No	Hardware configuration upload impossible; only program upload available
S7-1200	Firmware ≥ V3.0 (with TIA Portal V12+)	Yes	Full upload of hardware config including distributed I/O
S7-1500	Firmware V1.0 onwards (with TIA Portal V12+)	Yes	Full upload of hardware config; supports ET 200SP system data
S7-1500 Software Controller / ET 200SP CPU	Per product release notes	Yes	Same upload path as discrete S7-1500 CPUs

Engineers working with S7-1200 CPUs below firmware V3.0 have no tooling path inside TIA Portal to retrieve the active hardware configuration. The only recovery option in that situation is a service backup of the SIMATIC Memory Card or an SD-card image captured by an external tool, for example a card reader plus the SIMATIC Automation Tool or a vendor-provided image utility. Sites that still operate S7-1200 CPUs below V3.0 should treat the offline project as the sole authoritative source and enforce strict download-only access.

Step-by-Step: Reliable Online/Offline Verification

The following procedure closes the gap that the green-dot comparison leaves open. It assumes a TIA Portal V16 project (or later) and an S7-1500 CPU with an ET 200SP station containing the suspect 6ES7135-6HB00-0CA1 module.

1. Open the TIA Portal project that was used for the last download and establish an online connection to the CPU. Right-click the CPU in the project tree and select Go online.
2. Confirm the online diagnostics open without compile errors. The diagnostics buffer should not show configuration error entries or module mismatch entries. Record the current online status as the starting point.
3. Right-click the CPU and select Upload from device (software). A prompt asks whether to upload the device configuration as a new device or to overwrite the existing device. Choose Upload as new station to preserve the original project.
4. When the upload completes, a new device appears in the project tree with a unique name (for example S7-1500_CPU_1515_2_PN_20240115). Open the device view of the uploaded station and inspect the analog output module properties. Note the Output type and Output range on each channel.
5. Right-click the uploaded station and choose Compare with, then select the original station. TIA Portal opens the offline/offline comparison editor and highlights parameter differences with colored markers.
6. If the comparison shows no differences, the offline project and the CPU are in agreement. If differences appear (for example Output range 0...10 V in one station and 4...20 mA in the other), decide which revision is correct, archive the rejected revision in the project archive tool, and synchronize the surviving project to all engineering stations.
7. Compile the project, then download the corrected configuration to the CPU. After the download, perform another offline/online comparison. The dots should all be green against the corrected baseline.
8. Document the discrepancy and the resolution in the change log. File the upload snapshot in the project archive for traceability.

This procedure is heavier than a passive online check, but it is the only way to obtain a verified hardware snapshot. For sites that perform the procedure weekly, it normally adds less than fifteen minutes per controller and eliminates the silent-drift failure mode entirely.

Upload from Device vs. Online Comparison

The two operations have completely different data flows and different risks.

Upload from Device vs. Passive Online Comparison

Attribute	Online Comparison	Upload from Device
Action triggered by	Go online, or right-click → Compare offline/online	Right-click → Upload from device (software)
Data returned from CPU	Active load memory blocks and active system data block	Entire project including device configuration, blocks, tags, comments
Hardware parameters visible	Only those matching the last downloaded system data	All hardware parameters of the current CPU configuration
User program visible	Yes (active version)	Yes (active version, including non-compiled comments)
Result in PG	Diagnostic dots in project tree	New station object in project tree
Risk of overwriting accurate project	None (read-only)	High if Overwrite is selected; medium if Upload as new station is selected but the new station is then mistaken for the master
Reversible	N/A	Yes, if the original project is archived before the upload

Because the upload can overwrite the engineering project with stale data captured from a different engineering station, the operation should always be performed into a new station object and never as a replacement for the master project. Sites that allow engineers to use the Overwrite option risk destroying the as-engineered baseline on the engineering station, which is the same failure mode the offline/online comparison was supposed to detect.

Backup Tool Considerations: Asset Guardian and Octoplant

When multiple engineers and contractors modify the same controller, software-side version control alone does not protect against the issue described above. Asset Guardian (AUVESY-MDT) and Octoplant (formerly PROFINET Inspector / Indu-Sol) both automate project backups from live controllers on a schedule. The engineer must understand what each tool stores and how it compares snapshots over time.

• Asset Guardian captures a full project image at scheduled intervals and stores it in a centralized archive with change history. Each capture is a discrete revision. The tool can compare any two revisions side-by-side and can highlight parameter-level differences such as the output range of the 6ES7135 module.
• Octoplant performs scheduled backups and version diffs for Siemens and Wonderware projects. Diffing successive backups can reveal parameter changes; the tool can also push controlled updates to designated controllers.

Neither tool compensates for the limitation of TIA Portal's online comparison. They reduce the time between a contractor's edit and the engineer's awareness of that edit. If the backup captures a controller state that was already silently modified by a previous backup cycle, the tool will faithfully record the new state and propagate it forward in the archive.

The detection discipline must therefore be:

1. Schedule backups on a short interval (daily rather than weekly).
2. On every backup, diff the new image against the previous image and against a known-good master image.
3. Treat any hardware parameter diff as a controlled change and route it through the change management process.
4. Store at least one immutable golden master image per machine, signed and dated, as the fallback reference.
5. When the diff flags a change, trigger an offline/offline compare between the master and the new image to determine which parameter shifted.

A weekly backup interval is too long for most process plants because a single undetected contractor edit can be propagated forward for an entire week before the next capture surfaces it. A daily interval with mandatory diff-on-capture reduces the window to twenty-four hours.

Field-Proven Change Management Procedure

To prevent silent drift between the engineering project and the controller, adopt the following minimum change management discipline.

1. Assign a single engineering station as the project authority. All downloads originate from that station. Other stations only upload for read access and never perform downloads without authorization.
2. Maintain a signed paper or electronic change request for every download. The change request records the project version, the expected runtime delta, the expected hardware delta, and the verification method.
3. After every download, run Upload from device as a verification step and diff the upload against the just-downloaded project. The diff should report zero differences.
4. Quarterly, perform an offline/offline compare between the master project and the most recent backup image.
5. Require third-party contractors to deliver the modified TIA Portal project archive (zap16 for V16, am20 for V20) before commissioning leaves site. Verify the archive against the controller using the offline/offline compare procedure.
6. Maintain a read-only audit log of every download, including the engineering station name, the user account, and the project version timestamp.
7. For ISO 9001 or IEC 62443-2-4 compliance, retain the upload snapshot from step 3 as the verification evidence for the change request.

These steps mirror the ISO 9001 expectations for change control in operational technology environments and the IEC 62443-2-4 expectations for service provider management. Neither standard prescribes a specific verification tool, but both require evidence that the deployed configuration matches the documented configuration.

Diagnostic Workflow When Field Behavior Disagrees with Project

When a process anomaly is traced back to an analog output that is not behaving as expected, the following diagnostic tree resolves the issue quickly without requiring a full re-upload.

1. Open TIA Portal and go online with the CPU. Inspect the diagnostics buffer for entries containing Module difference or Configuration error. Note the timestamp and the slot number for any matching entry.
2. Open the device view of the ET 200SP station. Compare the slot configuration in the offline view against the diagnostic compare offline/online view. Look for slot-level differences and channel-level parameter differences.
3. Right-click the module and choose Online & diagnostics. The Channel diagnostics tab reports the active output range if the module supports runtime channel diagnostics. Cross-check the reported range against the configured range in the offline project.
4. If no parameter mismatch is reported but the field behavior is wrong, perform Upload from device into a new station object and inspect the analog output module properties in the uploaded station. The uploaded station is the only authoritative source for what the CPU is actually running.
5. Resolve the discrepancy by re-downloading the authoritative project. Document the resolution in the change log and notify any third-party contractors that have access to the project.

The error reference table below summarizes the diagnostic entries most often encountered during this workflow.

Common ET 200SP Analog Output Module Diagnostics During Mismatch Investigation

Symptom	Diagnostic Buffer Entry	Likely Cause	Remediation
Output stuck at 0 mA or 0 V	Parameter assignment error (configuration mismatch)	Channel output range mismatch between configured and actual module state	Re-download correct hardware configuration
Output reads correctly but field device misbehaves	No diagnostic entry	Online and PG project in sync, but PG project itself is wrong or stale	Upload from device, diff against master
Module reports channel temporarily not available	Module state indicates firmware update or calibration in progress	Module in special runtime state	Wait for completion, then re-check
Module completely missing from online view	Station failure / PROFINET interruption	PROFINET interruption or module physically pulled	Check wiring and PROFINET diagnostics
Field reading differs from output value by constant offset	No diagnostic entry	Output range correct but scaling wrong in program	Inspect NORM_X and SCALE_X blocks

Summary of Detection Disciplines

The green-dot diagnostic in TIA Portal is a software-parity indicator, not a system-parity indicator. To obtain true parity the engineer must:

• Treat the CPU as a non-authoritative cache of the engineering project.
• Treat the offline/online comparison as a quick verification, not as a forensic tool.
• Use Upload from device when the offline project is suspected to be stale.
• Use Offline / Offline compare between backup images to identify drift.
• Establish a change management discipline that requires project archives from every contractor.
• Schedule backups on a daily interval and diff every capture against a signed golden master.

The field incident with the 6ES7135-6HB00-0CA1 module demonstrates that a single missing step in this discipline can hide a parameter change for weeks. The remedy is procedural, not a TIA Portal feature request, because the architecture is by design: hardware configuration flows in only one direction during a passive online session, from the PG to the CPU. The only path back to the PG is an explicit upload action, and the engineer must take that action whenever the offline project is suspected to be wrong.

Frequently Asked Questions