Fixing TIA Portal V13 to V14 Motion Control FB Upgrade Issues

Upgrading a Siemens TIA Portal project from V13 (or V13 SP1) to V14 / V14 SP1 often surfaces a cluster of problems localized to the Motion Control technology objects and the MC_xxx function blocks shipped with S7-1500 Motion Control. The most common symptoms reported in the field are: MC_xxx instances duplicated in the program resources, version mismatch warnings on the TO_Axis and TO_Speed_Axis PLC data types, line comments silently stripped during the upgrade, and compile errors that point at undefined instances in the block interface.

This reference documents the root cause, an exact step-by-step recovery procedure, an alternative path through the TIA Portal Openness API for library-driven projects, and a verification checklist that should be run after every MC_xxx upgrade.

1. Problem Summary

You have a working S7-1500 / S7-1500T positioning project authored in TIA Portal V13 SP1 that uses:

• S7-1500 Motion Control library, technology version V4.0 (TIA V13 SP1 baseline).
• User-defined positioning FBs that call MC_Power, MC_Home, MC_MoveAbsolute, MC_MoveRelative, MC_MoveVelocity, MC_Stop, MC_ReadParam, MC_WriteParam, MC_Reset.
• PLC data types TO_Axis, TO_Speed_Axis, TO_ExternalEncoder, TO_Cam and TO_CamTrack declared in the project.
• Extensive network and line comments inside the FBs.

You open the project in TIA Portal V14 (or V14 SP1). The project upgrade runs. The technology is now V6.0. The first compile either fails or produces a build that no longer matches the original semantics. Inspecting the FB reveals one or more of the following:

2. Root Cause Analysis

The underlying issue is a technology version jump layered on top of an engineering tool version jump. Siemens ships the S7-1500 Motion Control library in a versioned form that is tightly bound to a TIA Portal major version. Between V13 SP1 and V14 SP1 the following changes took effect:

When the project upgrade runs, three things happen in sequence and each of them can fail or partially fail:

1. Block container upgrade. Siemens-supplied MC_xxx FBs and their associated types are pulled forward by the installer to the V14 / V14 SP1 versions. If the project contains a user-defined FB that embeds a copy of the MC_xxx source (a common pattern in V13 days, before typed library master copies were widespread), the embedded copies survive the upgrade and sit next to the new globally-installed versions. This is the source of the duplicate MC_xxx instances.
2. PLC data type regeneration. The TO_Axis and TO_Speed_Axis types are tied to the technology version through a hidden version tag. The upgrade wizard regenerates the global type, but any local TO_Axis declared inside a project-owned data type block is not regenerated and falls out of sync. The compiler flags these as "Version of the data type differs".
3. Comment retention. Comments are stored per block version. When the project upgrade replaces the FB with a V6.0 image (or, in the duplicate-block case, leaves both V4.0 and V6.0 instances in the tree), the comment database that belongs to the old version is orphaned. The new version opens with blank comments because the editor binds to the new comment slot, not the old one.

3. Prerequisites

Before touching the project, confirm the following:

• You have an offline archive of the V13 SP1 project (.zap13 archive or unpacked project directory). Never operate on the only copy.
• The target TIA Portal installation matches the target technology version you want to land on. For MC V6.0 you need TIA Portal V14 SP1 (or later, with the project upgraded step by step).
• The S7-1500 CPU firmware on the hardware supports MC V6.0. For S7-1500 CPUs this is firmware V2.0 or later (refer to the S7-1500 CPU product manual, Siemens Industry Online Support, article ID 109478802).
• You have a working reference of the original comments. Pull them out of the V13 archive first: open the project in a side-by-side V13 SP1 installation, print the affected FBs to PDF, or export the comment strips to a CSV through a script if you have one.
• No online connection to a running CPU during the upgrade step. Disconnect online sessions.

4. Step-by-Step Upgrade Procedure

The procedure below is the order that minimizes the risk of losing the comment history and the cleanest path to a single, V6.0-consistent set of MC_xxx blocks.

4.1 Run the project upgrade first, before touching any block

1. Open the V13 SP1 project in TIA Portal V14 SP1.
2. Accept the upgrade wizard prompt. Do not tick "Compile after upgrade" — you want to inspect the result first.
3. Let the upgrade complete. Expect warnings on technology objects. Note them in the upgrade log; do not fix them yet.
4. Save the project under a new name to preserve the original. From this point on, you are working on a copy.

4.2 Force the technology version forward on all MC_xxx

1. Open the positioning FB that wraps the MC_xxx calls.
2. In the FB editor, click into the body where an MC_xxx call sits.
3. Delete the old MC_xxx instance. The block reference is removed from the program resources, but the call site keeps its wiring.
4. From the right-hand Instructions task card, navigate to Technology → Motion Control. The list now shows the V6.0 versions of every MC_xxx block.
5. Drag the new V6.0 version of the same MC_xxx into the same network. Re-wire the call to match the old pinout. Where the V6.0 interface has new inputs (for example StartMode on MC_MoveAbsolute), leave them at the default 0 for first pass — you will validate them later.
6. Repeat for every MC_xxx call site in the project. Do not use a wildcard replace; the V4.0 and V6.0 versions sit in the same Instructions task card, and a global replace can re-introduce duplicates.

4.3 Resolve the TO_Axis / TO_Speed_Axis type conflict

Some project-owned TO_Axis and TO_Speed_Axis declarations will refuse to update through the standard "Update type" context menu. The reliable recovery is to flatten the type and rebuild it from the new library:

1. Open the project-owned data type that contains the stuck TO_Axis field. The type is typically named typeAxis or axisUDT.
2. Right-click the TO_Axis field and select Reset to default PLC data type. This converts the field to a Struct placeholder of the same name.
3. Recompile. The compile log now reports "undefined data type ‘TO_Axis’" on the Struct placeholder. That is expected.
4. Open the global TO_Axis under PLC data types → Motion Control. Drag the V6.0 TO_Axis onto the placeholder Struct field in your project-owned type. The field is re-typed to the new version.
5. Repeat for TO_Speed_Axis, TO_ExternalEncoder, TO_Cam and TO_CamTrack if they appear in your project types.

4.4 Clear duplicate MC_xxx instance DBs from the program resources

After step 4.2, the program resources tree may still contain instance DBs of the old MC_xxx FBs that are no longer referenced. Remove them:

1. Switch to the Program blocks view.
2. Filter by System blocks → Motion Control.
3. For each MC_xxx instance DB, right-click and select Delete. If the delete is rejected, the block is still referenced — go back to step 4.2 and find the missed call site.
4. Run Project → Compile → Software (rebuild all blocks). Confirm that the resulting instance count equals the number of MC_xxx call sites in your user code.

The duplicate-block name issue resolves on its own once the orphaned DBs are deleted, because the remaining instance DBs are the V6.0 versions the upgrade wizard created.

4.5 Restore the lost line comments

The TIA Portal editor does not provide a built-in "restore comments" action. The reliable recovery is to rebuild the comment strip from the V13 SP1 archive:

1. Open the V13 SP1 archive in a side-by-side V13 SP1 installation. Locate the original FB.
2. Print or export the network comments and line comments (TIA Portal → Options → Print preview, or use the "Export comments" route if your V13 installation has it).
3. In the V14 SP1 project, open the same FB and re-enter the comments at the network title, network comment, and per-line positions.

For larger FBs, automate the re-entry with the TIA Portal Openness API (see section 6). The CommentRangeStart / CommentRangeEnd properties on the PlcBlock graph are writeable.

5. Compatibility Matrix: V4.0 vs V6.0 MC_xxx

The following table lists the most-used MC_xxx blocks and the interface changes that matter for a V13 SP1 → V14 SP1 transition. Use it as a checklist when re-wiring step 4.2.

6. Alternative: TIA Portal Openness API for Library Master Copies

If the positioning FB is stored in a project library as a master copy and the recovery affects more than one project, automate it with the TIA Portal Openness API. The CreateFrom action on MasterCopy lets you copy a master copy within a library or between libraries. The official documentation is the TIA Portal Openness API — Copying master copies reference.

A typical C# recovery script that replaces an old V4.0 MC_xxx master copy with a V6.0 one follows the same shape as the manual procedure in section 4.2 but executed against the library DOM. The key sequence is:

1. Resolve the library: Library lib = project.Libraries.Find("GlobalLib");
2. Resolve the source master copy: MasterCopy src = lib.MasterCopyFolder.MasterCopies.Find("MC_Blocks_V4");
3. Create the target in the destination master copy folder: MasterCopy dst = destFolder.MasterCopies.CreateFrom(src.Name, src);
4. Refresh dependent type references on dst.Type to the V6.0 PLC data types.

7. Verification and Commissioning Checklist

After the upgrade, run the following checks before attempting a download to the CPU:

1. Project compile — clean. No warnings about block interface version, no “undefined data type” entries.
2. Cross-reference sweep. Use Project tree → right-click PLC → Cross-references on every MC_xxx instance DB. Each must show exactly one call site. Orphaned DBs indicate a missed call site in step 4.2.
3. Technology object version. In the project tree, every TO_Axis, TO_Speed_Axis, TO_ExternalEncoder must show the version tag matching the library version (V6.0 for V14 SP1). If a TO is still tagged V4.0, the upgrade wizard skipped it. Right-click the TO → Technology version → Change to latest.
4. HMI tag re-binding. For every HMI tag that points at a subfield of TO_Axis, validate that the subfield path resolves. The V6.0 axis exposes additional status subfields that did not exist in V4.0; if a HMI faceplate is bound to an old subfield name, the faceplate will show "invalid value" at runtime.
5. Axis online test (with safety permits in place). On a test rig, run MC_Power with a small StartMode value, then MC_Home, then MC_MoveRelative over a short distance. Verify the status transitions match the V6.0 state diagram (Done, Busy, CommandAborted, Error).
6. Comment strip diff. Compare the V14 SP1 FB comment strip against the V13 SP1 PDF export from step 4.5. Patch any blanked comments.

8. Troubleshooting Matrix

9. Edge Cases and Field Notes

• Skip-upgrade projects: A V13 SP1 project opened directly in V16 will run a chained upgrade V13 → V14 → V15 → V16. The duplicate-block and TO_Axis issues multiply at every step. Always go through the closest available intermediate version (V14 SP1 for a V13 SP1 source) and then upgrade again from the intermediate.
• S7-1500T kinematics projects: If the source uses MC_GroupRun, MC_GroupInterrupt or MC_GroupStop, those blocks did not exist in V4.0. They are first introduced in V6.0. A V4.0 project that emulated a group with parallel single-axis moves will need a manual redesign on V6.0 to use the new group blocks.
• Active project on a running CPU: Never run the upgrade wizard against the only online copy. Always download a fresh offline archive first, then upgrade, then re-download to the CPU. TIA Portal will not roll back an interrupted upgrade.
• Vendor-specific MC_xxx clones: Some third-party motion libraries (for example, central motion libraries packaged with servo drive add-ons) ship MC_xxx-shaped blocks with the same name. The duplicate-block detection does not distinguish them. If the project uses a vendor motion library, treat the vendor's master copy as the "source of truth" and re-import it after the upgrade, rather than touching the global MC_xxx set.

10. FAQ