TIA Portal V14 to V15.1 Migration S7-1500 CPU 1512 Transfer

Overview

Migrating a STEP 7 (TIA Portal) V14 project to V15.1 on a SIMATIC S7-1500 CPU 1512 (especially an F-variant such as 6ES7512-1SK02-0AB0 or 6ES7512-1FM02-0AB0) is not a transparent recompile. V14 and V15.1 generate different MC7 / STL program code, different safety signatures, and different block consistency hashes. The TIA Portal must therefore retranslate, re-link, and re-sign every F-block, FB, FC, DB, and OB before the resulting load image can be written to the target. On a typical mid-size F-CPU project, that re-build can take 30 minutes to several hours, and it is performed during the download itself, not as a separate compile step. The most common operator-visible failure modes are:

• The download dialog appears to "hang" for one to five hours while TIA Portal rebuilds the load image in the background.
• If the user aborts the transfer, the CPU is left with an empty or partially written load memory and reports "CPU memory is empty" on the next connect.
• After a successful load, the F-CPU refuses to enter RUN with a safety signature/consistency diagnostic because the F-source container cannot be re-uploaded for diagnostics.

All three symptoms are recoverable without re-flashing the CPU, but they require a controlled sequence: backup retained DBs, perform a factory reset, reload the V15.1 project, and re-enable the consistent F-upload option.

Why V14 → V15.1 Is a Hard Upgrade, Not a Re-Compile

TIA Portal V15.1 introduced several internal format changes that make a binary-compatible upgrade impossible. The most relevant changes for an S7-1500 CPU 1512 are:

Because of the F-container change, the PLC refuses a V14 program download into a V15.1-configured CPU and vice versa. TIA Portal performs the conversion automatically the first time the project is opened in V15.1, but the resulting load image is only built when you click Download to device. The long blocking time the user observed (2–5 h) is the F-signature, the UDT regeneration, and the load-image build running synchronously on the engineering station.

Prerequisites Before You Start

Do not open the V14 project in V15.1 until the following items are confirmed. Skipping any of them risks losing the safety program signature, retained process data, or the F-source for online diagnostics.

1. Back up the V14 project as .zap14 (TIA V14 archive) and as a TIA Portal project folder copy. The .zap archive cannot be opened in V15.1 without conversion; keep the V14 archive to roll back.
2. Back up retained current values of all DBs that the application needs to survive the upgrade. See Backup of Retained DB Values below for the supported method.
3. Export the F-source as an external source file (.scl / .fbt). The F-signature and the F-source are required to perform F-CPU online diagnostics later. Without a backed-up source, the only option is the F-source shipped with the project inside TIA Portal.
4. Update the CPU firmware to a V15.1-compatible version. For CPU 1512-1 PN, the minimum is firmware V2.0; for 1512SP-1 PN, firmware V2.0; for F-variants (1512F-1 PN / 1512C-1 PN F), firmware V2.1 or later is required for F-runtime V2.6 features. Confirm the firmware compatibility list in the TIA Portal V15.1 readme.
5. Record the CPU's serial number and program password (if Know-How-Protect is enabled). After a factory reset, the password hash on the CPU is invalidated and must be re-entered.

Backup of Retained DB Values

Retain memory on S7-1500 is divided into retain (backed up by the CPU's battery / capacitor) and non-retain (cleared on RUN→STOP→RUN or power-cycle). After a factory reset, retain memory is cleared. The supported Siemens procedure to preserve DB content across a TIA upgrade is:

1. Online → Backup of S7 CPU data → select the DBs to back up → choose a path on the PG/PC. The file is created in .psd format.
2. Read the active F-signature via Online → Online & diagnostics → Safety → Print F-signature and save the printout as PDF.
3. After the V15.1 project has been reloaded and the CPU is back in RUN, restore the data with Online → Restore from backup file and select the .psd file from step 1.

The official Siemens FAQ How do you back up the current values of DBs of the S7-1200/S7-1500 when upgrading from STEP 7 (TIA Portal) V13 SP1 and restore them in V14? describes the same procedure and applies to the V14→V15.1 transition as well, since the .psd format is forward-compatible across V14 SP1 and V15.1.

Step-by-Step Migration Procedure

The following procedure is the field-validated sequence for an S7-1500 CPU 1512 F-CPU on STEP 7 V15.1 with an existing V14 project. Total downtime: 1 h to several hours depending on project size.

1. Copy the V14 project folder to a working directory. Open the copy in TIA Portal V15.1. Accept the conversion dialog and the library conversion dialog. Save the project as a V15.1 project.
2. Open the device view of the CPU. Confirm that the firmware version in the device configuration is set to a V15.1-supported value. If the on-line CPU is older, update firmware first via Online → Update firmware (the CPU will STOP during the update).
3. Compile the project. Resolve any warnings about renamed PLC data types or migrated F-blocks. The compiler will flag every F-block that needs to be re-signed.
4. Set the PG/PC interface to the CPU's PROFINET interface and the correct access point. Go online. The CPU is expected to be in STOP.
5. Select the CPU in the project tree → Download to device → Hardware and software. Acknowledge the warning that the project on the PLC must be converted to the same version. The download begins.
6. Do not abort. The download is the migration step. TIA Portal converts the V14.0 load image to a V15.1 load image, re-signs all F-blocks, and writes the result. On a typical F-CPU project with 200–400 blocks, expect 45 min to 2 h. Larger projects with extensive WinCC tag exchange can exceed 4 h.
7. When the download finishes, restart the CPU. The CPU will start in STOP because the F-signature has changed.
8. Open Online & diagnostics → Safety → Confirm F-signature. Compare the printed signature with the one recorded in step 2 of the backup procedure. If the signatures match, the safety program is byte-identical to the pre-upgrade version.
9. Switch the CPU to RUN.

What To Do If You Already Aborted the Download

If the download was aborted (or TIA Portal crashed mid-write), the CPU's load memory is empty or partially written. The next attempt to go online will report "The CPU memory is empty". The recovery is straightforward but requires a factory reset:

1. Disconnect the TIA Portal download. Close TIA Portal if necessary to release the online connection.
2. In TIA Portal: Online → Online & diagnostics → Functions → Reset to factory settings. Confirm with the CPU's password (or remove the password first if it is not known). The CPU retains its IP address and PROFINET device name; the operating mode selector position is ignored during a software reset.
3. After the factory reset, the CPU is in STOP with empty load memory. Re-download the V15.1 project (Hardware and software). The download is now fast because the migration has already been done in the prior aborted attempt — TIA Portal reuses the compiled load image.
4. Restore the retained DBs from the .psd backup (if one exists). Switch the CPU to RUN.

The "Enable Consistent Upload From the F-CPU" Option

The second symptom reported in the original incident — "impossible to switch the CPU to RUN with an error on the safety" after a successful migration — is a configuration issue, not a corruption. The F-CPU's protection and security settings control whether the F-source container is stored in load memory in a form that allows TIA Portal to upload it for online diagnostics. If the F-CPU refuses to go to RUN, the diagnostic buffer contains a Safety signature mismatch or F-container missing entry. The fix is in the CPU's device configuration:

1. In the project tree, right-click the CPU 1512 F-CPU → Properties.
2. Navigate to Protection & Security (or Protection in older V15.1 builds).
3. Under the Consistent upload from F-CPU group, enable the checkbox "Enable consistent upload from the F-CPU". This option is the equivalent of the older Support F-source in the device checkbox in V14.
4. Recompile the project. Download the hardware configuration to the CPU. The safety program will report a signature change; re-confirm the F-signature, then switch the CPU to RUN.

The setting is part of the hardware configuration and is therefore not affected by re-downloading software blocks. If the F-CPU is in RUN and the operator then un-checks the option, the CPU will go to STOP on the next configuration download, because the F-runtime detects a configuration drift on the F-container. The exact behavior is documented in the S7-1500 F-CPU manual, function manual SIMATIC S7-1500, ET 200MP, ET 200SP, ET 200AL, ET 200pro, ET 200eco PN F-CPU, section 5.5 "Upload of F-source to PG/PC".

Expected Transfer Times (Field Data)

The blocking time the user observed is not a bug. The following table lists typical download times for a V14 → V15.1 upgrade of an S7-1500 CPU 1512 F-CPU on a PROFINET connection at 100 Mbit/s. Times include the on-the-fly migration of the load image.

If the download takes longer than the upper bound for the project size, the most likely cause is that TIA Portal is also rebuilding HMI tag exchange or compiling a WinCC Professional panel simultaneously. Disconnect any HMI panels from the project tree before the download to isolate the time to the PLC compilation.

Diagnostic Buffer Entries To Watch

The CPU's diagnostic buffer tells you exactly which step of the migration is failing. The following entries are the ones most often encountered on a V14 → V15.1 upgrade of a CPU 1512 F-CPU.

Troubleshooting Matrix

Verification

After the upgrade, perform the following checks in order. Each step must pass before the next is started. If a step fails, return to the troubleshooting matrix above.

1. Online comparison: Online → Compare offline / online on the CPU. The hardware configuration should show identical; the software may show different for the safety signature column, which is expected.
2. F-signature check: Online & diagnostics → Safety → Print F-signature. The signature must match the one saved during the V14→V15.1 conversion. The timestamp in the signature should be the date of the upgrade.
3. Retain data check: Online → Watch table on a DB that was in the .psd backup. The current values must equal the values saved before the upgrade.
4. Safety I/O check: Force each F-input and F-output in the safety program one at a time with the plant in a safe state. Confirm the F-CPU logs the expected passivation / integration event for each.
5. Diagnostic buffer check: Online & diagnostics → Diagnostic buffer. The most recent entries should be the CPU transitions STOP → RUN, F-signature confirmation, and any safety I/O passivation. No "Load image is invalid" or "F-container missing" entries should appear.
6. Process run-time: Run the process for at least one full recipe / cycle and verify that no intermittent F-stop events occur. F-runtime V2.6 introduces tighter timing checks than V2.4; some legacy programs that ran fine on V2.4 trigger "F-cycle time exceeded" diagnostics on V2.6.

Rollback Procedure (If The Upgrade Fails Catastrophically)

If the V15.1 project cannot be made to run on the CPU and the V14 archive is still available, the following rollback restores service with the V14 firmware on the V15.1 CPU. This is supported only if the V15.1 project did not require a newer F-runtime than the V14 firmware supports.

1. Open the .zap14 archive in a PC that still has STEP 7 V14 SP1 installed.
2. Reset the CPU to factory settings via TIA Portal (V15.1, since the V15.1 project is currently on the CPU).
3. Update the CPU firmware back to the V14-supported version. The downgrade is allowed by the CPU's firmware loader; however, it wipes the load memory and resets the PROFINET device name to default.
4. Re-assign the PROFINET device name from the V14 project.
5. Download the V14 project to the CPU. Switch to RUN. Restore retained DBs from the .psd backup made before the upgrade attempt.

Edge Cases and Field Notes

The following items are not covered in the Siemens online help for the V14 → V15.1 upgrade and have been observed in the field on CPU 1512 F-CPU installations.

• HMI panels tied to the PLC project: A WinCC Comfort / Advanced panel that has its tag interface linked to the PLC project will also re-compile during the download. The total transfer time is then the sum of the PLC build plus the HMI build. To check whether the HMI is the bottleneck, look at the TIA Portal log for HmiLoad events.
• PROFINET IRT vs RT: IRT devices on the same PROFINET subnet are also re-assigned by the device configuration compile. The download may pause with a message "Waiting for PROFINET topology to settle"; this is normal and can take up to 10 minutes.
• Multiple CPUs in one project: TIA Portal builds the load images for all CPUs in sequence, not in parallel. A project with four S7-1500 CPUs will take approximately four times the time of a single-CPU project.
• F-CPU with password but no F-source backup: If the original V14 F-source was not exported, the only way to upload the F-source to the PG/PC after the upgrade is to have had the Enable consistent upload from F-CPU option set on the V14 project. If the option was off in V14 and the original F-source is lost, the safety program is effectively write-only — the CPU will run, but TIA Portal cannot download a modified safety program because it has no F-source to sign against. Recovery requires a project archive or a service request to Siemens for the F-source from the original project backup.

FAQ