Resolving TIA Portal V13 SP1 Upload from V10.5 PLC Projects

Engineers maintaining legacy SIMATIC systems frequently encounter a hard limitation when they try to upload a station created in TIA Portal V10.5 using the newer TIA Portal V13 SP1 (or any V13 variant) — the upload fails or the CPU is reported as "not accessible for the current project version". This reference documents the root cause, the supported workaround path through TIA Portal V11 SP2, and the firmware constraints that apply to S7-300, S7-400, S7-1200, and S7-1500 stations during the migration.

1. TIA Portal Version and Project Compatibility Rules

Siemens defines a one-way upgrade path for TIA Portal projects. The relationship between engineering versions, firmware versions, and CPU families is governed by the "TIA Portal Project Compatibility" matrix published in the TIA Portal help and on the Siemens Industry Online Support portal. The salient rules for the V10.5 → V13 SP1 migration scenario are:

The matrix above is the basis of the SIMATIC TIA Portal project compatibility and migration entry. When the source project is older than two major versions, the recommended workflow is to upload with the bridge version, save the migrated project, and then continue editing in the newer version.

2. Problem Analysis: Why V13 SP1 Cannot Upload a V10.5 Station

Uploading is not a generic "read the binary" operation. TIA Portal performs the following sequence when the user issues an "Upload station to PG/PC" command:

1. Reads the online project identifier stored in the CPU's system data blocks (SDB) — this identifier contains the TIA Portal version that last compiled the project.
2. Compares the online identifier against the local project's identifier.
3. If the online identifier is older than the lowest version the local TIA Portal installation can decode, the upload is rejected with a dialog such as "The PLC contains data of an older TIA Portal version that cannot be uploaded with the current version."
4. If the local TIA Portal can decode the online identifier, the SDBs, blocks, tags, and HW configuration are reconstructed into the local project tree.

For a V10.5 station, the online identifier carries the V10.5 block signature and the SDBs are formatted in the V10.5 schema. V13 SP1 knows the V11, V12, and V13 schemas — it has no decoder for V10.5. The result is an immediate rejection, regardless of CPU model or firmware.

3. S7-1500 Firmware Considerations During the Bridge Upload

The V13 SP1 era introduced a parallel constraint for S7-1500 CPUs: the CPU firmware must be supported by the GSD/HSP catalog of the engineering version used for the upload. Field cases have been reported with the S7-1511 (6ES7 511-1AK01-0AB0) shipped with firmware V2.0 as the default load — this firmware is fully supported in V13 SP1 Update 9 via the shipped HSPs.

Reference: S7-1500 CPU 1511-1 PN manual (6ES7511-1AK01-0AB0). If the bridge version (V11 SP2) does not list the exact CPU MLFB in its hardware catalog, install the matching HSP before attempting the upload — otherwise V11 SP2 will report "Unknown module type" during online scan.

4. Prerequisites for the Workaround

To execute the V10.5 → V13 SP1 migration, the following engineering environment must be assembled:

1. TIA Portal V11 SP2 installed on a separate engineering station (or as a parallel installation in a separate directory). V11 SP2 is the last V11 release that contained a full S7-300/S7-400/S7-1200 upload path and is the recommended bridge per Siemens support.
2. TIA Portal V13 SP1 (or V13 SP1 Update 9) installed on the target engineering station with all HSPs for the deployed S7-1500 / S7-1200 CPUs.
3. Ethernet / PROFIBUS connectivity to the target PLC, with the PG/PC interface configured and reachable. Verify with a ping to the CPU's IP address.
4. The original V10.5 project file (optional but recommended) so the offline-to-online comparison is cleaner.
5. PG/PC administrator rights to install HSPs and to bind the Siemens S7DOS / ISO protocols.

5. Step-by-Step Workaround: V11 SP2 Bridge Upload

The following procedure uses V11 SP2 to extract the program from a V10.5-programmed CPU, then migrates the recovered project into V13 SP1 for ongoing engineering.

Step 1 — Install the V11 SP2 Bridge

1. Insert the TIA Portal V11 SP2 installation media, or extract the downloaded ISO to a working directory.
2. Launch Start.exe and select "Install TIA Portal V11 SP2".
3. Choose a directory that does not collide with the V13 SP1 install (e.g., C:\Siemens\Automation\TIA_V11_SP2).
4. Restart the engineering station when prompted.

Step 2 — Create an Empty V11 SP2 Project

1. Start TIA Portal V11 SP2.
2. Project → New, give the project a name, and click Create.
3. Insert a new device: Devices & Networks → Add new device → SIMATIC PLC → match the CPU model exactly (e.g., CPU 1511-1 PN / 6ES7 511-1AK01-0AB0). If the exact MLFB is not in the catalog, install the matching HSP first.

Step 3 — Match the Hardware Configuration Exactly

1. Open the device view of the newly added CPU.
2. Add the signal modules (SM), communication modules (CM/CP), and any F-modules that are physically present in the rack. The slot order must match the installed order or the online compare will report mismatches that block the upload.
3. Configure the IP address, PROFINET device name, and subnet mask to match the physical CPU. If the IP is unknown, browse the network first: Online → Accessible nodes.
4. Configure the modules' channel settings (input filter, diagnostics, interrupt enables) — these are part of the SDBs the CPU will compare against.

Step 4 — Go Online with "Online Access"

1. In the project tree, expand Online access → select the network adapter bound to the target subnet.
2. Double-click Online & diagnostics. V11 SP2 will scan the subnet and list the detected S7 stations.
3. Right-click the detected CPU and choose "Go online". The "Go online" dialog will report whether the project and the online CPU are compatible. With a freshly created V11 SP2 project and a V10.5 CPU, you will see a warning that the offline project does not match the online configuration — accept the warning.

Step 5 — Drag and Drop Blocks and Tags from Online to Offline

1. With the online connection established, the project tree now contains an "Online" node parallel to the device view.
2. Expand the online tree: Online → CPU_xx → Program blocks.
3. Click and hold on the first block (e.g., OB1). Drag the block onto the matching block icon in the offline Program blocks folder of the device.
4. Repeat for all OBs, FBs, FCs, DBs, and UDTs. The block attributes (author, version, last modified) are preserved.
5. For tags: expand Online → CPU_xx → PLC tags. Drag the default tag table and any user-defined tag tables to the offline tree. Note: tags stored in the PLC's retentive area are also uploaded into the project as the PLC tags table.
6. For technology objects (S7-1500 motion, PID_Compact, etc.): expand Online → CPU_xx → Technology objects and drag the TO into the offline tree. The TO's configuration is reconstructed but any comments are lost.

Step 6 — Save the V11 SP2 Project

1. Project → Save As. Use a directory dedicated to the migration (e.g., D:\Migration\PlantA_V10p5\V11).
2. Project → Archive (optional) to produce a single-file backup before the V13 SP1 migration.

6. Migrating the Recovered Project from V11 SP2 to V13 SP1

Once the V10.5 program is recovered as a V11 SP2 project, open it in V13 SP1 and let TIA Portal execute its built-in migration:

1. Copy the V11 SP2 project directory (or use the .zap11 archive) to the V13 SP1 engineering station.
2. Start TIA Portal V13 SP1. Project → Open → navigate to the V11 SP2 .zap11 or unpacked project directory.
3. V13 SP1 displays the migration dialog. Confirm the target version (V13 SP1) and click "Migrate".
4. Review the migration log (Project → Migration log) for warnings. Common warnings include: library references that no longer exist, renamed system blocks, and unsupported OB types from older firmware.
5. Compile the project: right-click the CPU in the project tree → Compile → Software (rebuild all blocks).
6. Download to verify: Online → Download to device. If the CPU is in RUN, set it to STOP first or accept the dialog that asks to start the download in RUN-compatible mode.

Reference: Migrating projects to TIA Portal V13 SP1 for the official migration checklist.

7. S7-300 and S7-400 Specific Notes

For S7-300 (e.g., CPU 315-2 PN/DP, 6ES7 315-2EH14-0AB0) and S7-400 (CPU 414-3 PN/DP, 6ES7 414-3EM06-0AB0) stations, the V10.5 → V11 SP2 bridge still applies. Additional considerations:

• STEP 7 V5.5 SPx is the legacy engineering tool and is not compatible with TIA Portal V10.5. If a STEP 7 V5.x project must be uploaded into TIA Portal V13 SP1, the path is: STEP 7 V5.5 SP4 → migrate to TIA Portal V11 SP2 → save → open in V13 SP1.
• For S7-300, the F-modules (F-CPU, F-SMs) require the F-Configuration Pack to be installed in V11 SP2, which is the same F-pack used in V13 SP1.
• For S7-400H (redundant) stations, the V11 SP2 upload captures both CPUs' blocks separately. Verify the redundant configuration is intact after the V13 SP1 migration by going online to the H-system and comparing both racks.

8. S7-1200 Specific Notes

The S7-1200 (CPU 1211C, 1212C, 1214C, 1215C, 1217C) with firmware V1.x through V4.x has a parallel migration caveat:

• Firmware V1.x was engineered with TIA Portal V10.5 only. V11 SP2 cannot upload a V1.x program if the engineering version mismatches; in that case use V10.5 itself as the bridge, then migrate to V11, then to V13 SP1.
• Firmware V2.x → V4.x was engineered with TIA Portal V11 SP2 through V15.1. The V10.5 → V11 SP2 bridge upload works without firmware update.
• When migrating an S7-1200 program, the technology objects (PID_Compact, TO_Positioning, TO_Speed) are migrated but the axis configuration must be re-commissioned on the physical axis — mechanical limits, homing, and encoder settings are not always preserved.

Reference: S7-1200 system manual.

9. Alternative Procedure: When the Bridge Version Is Not Available

If TIA Portal V11 SP2 cannot be sourced, two field-proven alternatives exist:

1. Service request to Siemens: Open a support case at Siemens Industry Online Support and request a "project recovery service". Siemens can use the V10.5 engineering tool to read the CPU, generate a V10.5 project, and return a migratable archive. Typical turnaround is 5–10 business days.
2. Source-archive in the CPU: Some S7-1500 firmware versions (V2.0 and later) keep a compressed source archive in the CPU's system memory. From the V13 SP1 "Online & diagnostics" view, the "Read service data" function can extract this archive if the CPU was loaded with V13 SP1 or later. This is not a V10.5-to-V13 SP1 path, but it is useful when the V10.5 project is lost and the CPU was later re-loaded with a newer version.

10. Firmware Update Considerations Before the Upload

If the V10.5-programmed CPU has firmware that is also unsupported by V11 SP2 (rare but possible with very old S7-300 CPUs at firmware V2.x), a firmware update is required. Procedure:

1. Identify the current firmware in the CPU: Online → Accessible nodes → select CPU → "Read PLC identification".
2. Locate the matching firmware file in the Siemens Service & Support portal — search by MLFB.
3. Use SIMATIC Automation Tool, or TIA Portal's "Online → Update firmware" function, to flash the new firmware. The CPU will be in STOP and will reset to factory defaults at the end of the update.
4. Reload the user program from the backup archive.

11. Troubleshooting Matrix

12. Verification Steps

After the V10.5 → V11 SP2 → V13 SP1 migration is complete, perform the following verification to confirm functional equivalence:

1. Block count parity: Compare the number of OBs, FBs, FCs, DBs in the offline V13 SP1 project against the source documentation. Use the project's "Project overview" tab.
2. Online compare: Online → Compare offline/online. The report should show zero structural differences for the SDBs and zero program-code differences after a recompile.
3. Cross-reference: Right-click a known tag (e.g., a critical motor start input) → Cross-reference. Verify the cross-reference list matches the original program logic.
4. Watch table test: Create a watch table with the IO tags and force the physical inputs through a controlled sequence. Confirm the outputs respond as expected.
5. Trace recording: For motion or fast loops, record a trace on the migrated project and compare against a trace recorded with the original V10.5 project. Tolerances depend on the application, but sample timing should match within 1 ms.
6. Backup of migrated project: Project → Archive. Store the archive in the plant's controlled-document repository with a version tag (e.g., PlantA_Cell3_MigratedV10p5toV13SP1_v01.zip).

13. Best-Practice Summary

• Always keep a V10.5 project archive on file for as long as a V10.5-programmed CPU is in service.
• Maintain a TIA Portal V11 SP2 license or at least access to a V11 SP2 installation media for migration windows. The V11 SP2 SP-level is the last fully supported upload path from V10.5.
• When commissioning a new S7-1500, set the CPU firmware to the V2.x line that V13 SP1 Update 9 supports out-of-the-box, and avoid custom HSP chains that break on the next engineering upgrade.
• Document the engineering version of every deployed program on the panel layout or the plant's asset database. The version identifier in the CPU's SDBs is the only authoritative source of the last-compiled TIA Portal version.
• When upgrading a plant from V10.5 to V13 SP1, plan a shutdown window large enough for: V10.5 → V11 SP2 upload (≈ 30 min for a 1 MB project), V11 SP2 → V13 SP1 migration (≈ 20 min), and the functional verification (≈ 2 h).

14. Frequently Asked Questions