TIA Portal V15: Resolving Download Only Changes Not Available

Problem Overview

Engineers migrating projects from TIA Portal V14 to TIA Portal V15 frequently report that the Download only changes (software) action becomes unavailable even after a trivial edit such as converting a single normally-open contact to a normally-closed contact inside a single Function (FC). The symptom is reproducible: after a successful compile, the Download to device dialog lists every organizational block (OB), function (FC), function block (FB) and instance data block (DB) in the Status column, but the Action column does not offer the Download only changes radio button. The user is forced into a full download of all program blocks.

For small standalone machines this is a minor inconvenience, but on multi-station automation lines a full download interrupts every retain tag, forces re-initialization of running equipment, and risks loss of in-process state. Understanding the precise root cause prevents lost production time on subsequent interventions.

How "Download Only Changes" Works in STEP 7 / TIA Portal

The incremental download mechanism in TIA Portal (formerly STEP 7) operates by computing a SHA-style block fingerprint for every offline block and comparing it to the fingerprint stored in the PLC's load memory. If the fingerprint of an offline block matches the loaded block, the action column shows Consistent / no download required. If the fingerprint differs but the block interface (IN/OUT/IN_OUT/STAT/TEMP declaration) is still compatible with the running program, the action column shows Download only changes. If the interface changed in a non-additive way, the action column escalates to Download all or, on S7-1500 CPUs in RUN mode, Download in RUN with re-initialization of the affected instance.

According to the official Siemens TIA Portal documentation "Basics for compiling and downloading PLC programs":

"A changed group structure is only downloaded to the controller with the next change that is relevant for the download, for example, a change to a block."

This statement is the cornerstone of the incremental download logic. The portal stores metadata about group structures (the way blocks, types, and PLC tags are organized in the project tree) separately from the executable code. When the project tree is reorganized—but no executable block changes—the group structure is updated silently. The next code change is then required to physically push the reorganized structure to the CPU. Conversely, a code change combined with a structural reorganization forces a full reconciliation, eliminating the incremental option.

Root Cause #1: TIA Portal Update Version Mismatch (Most Common)

The single most common cause of "Download only changes" disappearing in V15 is a version skew between the TIA Portal project and the runtime image on the PLC's SIMATIC Memory Card. Siemens has shipped TIA Portal V15 in multiple update revisions:

When the offline project was last saved on one update level and the on-line project is running a different update level, the firmware module on the CPU reports a different compilation timestamp than the offline build. Because the incremental download requires a 1:1 match of the build metadata, the action column degrades to Download all. This is the case the original poster described: a single NO-to-NC change in one FC should not affect any other block, yet the portal forced a full download because the project tree and the loaded image were from different update revisions.

Identifying the Mismatch

1. Right-click the PLC station in the project tree and select Online & diagnostics.
2. Open the Diagnostics folder and read the Online firmware version (e.g. V15.1.0.5 / FW 2.6.0).
3. On the offline side, open Project tree > PLC > Properties > General > Project information and note the Last compiled timestamp and TIA build.
4. If the build numbers differ, the project tree must be recompiled and downloaded in full once before incremental downloads resume.

Root Cause #2: Block Dependency and DB Tag Modifications

Even when the build versions match, modifications to a Data Block (DB) used by many FBs/FCs/OBs invalidate the incremental download for every consumer block. A common example is changing a tag's data type from INT to UINT inside a global DB. Because the symbol table generated for each consumer references the same DB and the same tag with a different bit-width, the offline fingerprint of every consumer block changes. TIA Portal responds by listing all consumers for full download.

Root Cause #3: Insufficient Load Memory Reserve

Both S7-1200 and S7-1500 CPUs reserve a configurable portion of load memory specifically for incremental block changes. When the offline changes exceed this reserve, the portal falls back to a full download. The reserve is set per CPU under Properties > Memory:

• S7-1200 (FW 4.x): Reserve is implicit and tied to the SIMATIC Memory Card free space; no user setting.
• S7-1511 / 1513 / 1515 / 1516: Up to 5 MB configurable via the Load memory reserve for online changes parameter.
• S7-1517 / 1518 / 1518F: Up to 50 MB reserve.

Comparing TIA Portal V14 vs V15 Download Behavior

Engineers often believe V15 introduced a regression, but the truth is that V15 added stricter program-identification checks that V14 performed only implicitly. The V15 dialog will refuse incremental download with a clear red exclamation mark icon when the project and PLC fingerprints do not match, whereas V14 silently performed a full download without warning.

Diagnostic Procedure

1. Verify build parity. Compare Online & diagnostics > Diagnostics > Online firmware/build string with PLC > Properties > General > Project information.
2. Check load memory reserve. Open the CPU's Properties > Memory and confirm the Load memory reserve for online changes value.
3. Inspect the compile log. Open the inspector window under Compile and look for warnings tagged BlockInterfaceChange or LoadMemoryExhausted.
4. Use the "Compare offline/online" tool. Right-click the PLC → Compare → Offline/online. The resulting table highlights every block whose interface or code differs.
5. Confirm program identifier. In the project tree open PLC > Properties > General > Identification. If the Program name or Author string differs from the running CPU, TIA Portal will mark the entire program as different.

Restoring Incremental Download Capability

Once the root cause is identified, apply the matching remediation:

If Build Versions Mismatch

1. Open the project in the same TIA Portal build that originally compiled the offline tree. If that build is unavailable, install the matching update from the Siemens Automation License Manager or the official Siemens Industry Online Support portal.
2. Perform a full Download to device (the one currently being forced) to bring the CPU into build parity with the offline project.
3. Make a small additional edit (e.g. add a comment) and recompile. The next download should now offer Download only changes.

If Load Memory Reserve is Too Small

1. Navigate to PLC > Properties > Memory.
2. Increase the Load memory reserve for online changes value. Recommended starting point is 2–5 MB for S7-1500, scaled up to 10 MB for cells with frequent commissioning.
3. Recompile and re-attempt the download. The dialog will now present the incremental option.

1. Open the Compile inspector and identify the InterfaceChange warning. Note the affected blocks.
2. If the change is in a multi-instance DB or a global DB used by many consumers, plan a maintenance window. Incremental download is not possible; the next download must be a full one.
3. After the full download, future edits within the same build remain incremental.

Working with S7-1200 and S7-1500 PLCs

The behavior differs by hardware family:

• S7-1200 (CPU 1211C ↔ 1518-4 PN/DP equivalents, FW 4.4+): "Download only changes" is supported but limited to additions and the load memory reserve is implicit. Any interface change forces a STOP-to-RUN cycle.
• S7-1500 (CPU 1511-1 PN ↔ 1518-4 PN/DP, FW 1.8–2.9): Full support for incremental download. From FW 2.5 onward, true Download in RUN is available for many interface changes, but only if the load memory reserve is sufficient.
• ET 200SP CPU: Behaves identically to S7-1500 CPUs of the same firmware tier.

Verification

After remediation, run the following verification checklist before signing off the intervention:

1. Open the Download to device dialog and confirm the Action column now shows the Download only changes radio button.
2. Trigger the download and verify that the CPU does not transition through STOP on a non-interface change.
3. Check Online & diagnostics > Diagnostics > Memory: load memory used should be ≤ (load memory total − reserve).
4. Inspect the Diagnostic buffer for entries of class FirmwareUpdate / ProgramChange confirming a partial download was logged.
5. Run a controlled simulation of the modified logic on a test station if available.

Troubleshooting Matrix

Best Practices for Future Projects

• Lock the TIA Portal version. Use a single TIA Portal update level (e.g. V15.1 Update 5) across the engineering team. Update the entire fleet in a coordinated change.
• Document the firmware string. Record the exact build and firmware on the project's first page (e.g. TIA V15.1.0.5 / CPU 1516-3 PN/DP FW V2.6.0).
• Configure the load memory reserve early. Set 5 MB reserve for typical S7-1500 cells at project creation, not after the first intervention.
• Group structure changes only. Reorganize the project tree during development, before commissioning. Avoid tree reorganisation on a live cell.
• Avoid last-minute DB interface changes. Lock the DB interfaces at design freeze; subsequent edits trigger full download cascades.
• Use the Simulation PLCSIM for dry-run. Test the download sequence in PLCSIM Advanced first, then mirror the procedure on the physical CPU.