Migrating TIA Portal Programs to PLCnext via PLCopen XML

Migrating TIA Portal Programs to PLCnext via PLCopen XML

Industrial automation projects rarely live within a single vendor ecosystem for their entire lifecycle. Hardware refreshes, end-of-life controller replacement, corporate standardization programs, and the need for an open, Linux-capable control platform routinely force engineering teams to port validated PLC code from one platform to another. This article covers the practical workflow for moving IEC 61131-3 program logic out of Siemens TIA Portal — the engineering framework for the SIMATIC S7-1200 and S7-1500 controller families — and into Phoenix Contact PLCnext Control devices (AXC F 1152, AXC F 2152, AXC F 3152, and EPC 1522) configured with PC Worx Engineer / PLCnext Engineer. The same workflow also applies when MATLAB Simulink models are part of the source project.

Why a 1:1 Project Converter Does Not Exist

TIA Portal is a tightly integrated engineering suite that bundles five distinct work domains under a single binary project database (.ap14, .ap15, .ap16, .ap17, or .ap18 archive, depending on TIA version):

Only the PLC program domain has a vendor-neutral exchange path. SCL sources, ladder logic diagrams, and FBD networks are not stored in an open schema inside TIA Portal's archive — they live in a proprietary binary database — so a direct import is structurally impossible. PLCopen XML is the workaround: TIA Portal exposes an export filter that emits the language elements of the active CPU in the standardized XML schema, and PC Worx / PLCnext Engineer exposes a complementary import that reads that XML back into POUs.

PLCopen XML Interchange Path

PLCopen XML is the standardized XML representation of IEC 61131-3 elements defined in IEC 61131-10. Its schema covers:

• Program organization units (POUs): programs, function blocks, functions
• Data types: elementary types, derived types, user-defined structs, arrays, enumerations
• Global variable lists (GVLs) and tag tables
• Tasks and their associated POUs plus interval and priority metadata
• Comments, documentation strings, and namespace identifiers

TIA Portal's "Export to PLCopen XML" function (located under Project > Export > PLCopen XML) generates a single .xml file containing the language elements of the active S7-1200 / S7-1500 CPU. PC Worx Engineer and PLCnext Engineer support the inverse Import > PLCopen XML operation. Export and import are one-way and one-shot — there is no live synchronization between the two tools.

Limitations of PLCopen XML Round-Trip

Not every IEC 61131-3 element survives a TIA → PC Worx round-trip cleanly. The mapping table below summarizes the practical outcomes observed in real migrations:

Prerequisites

Before starting a migration, gather the following:

1. TIA Portal source project — preferably the latest revision, saved with the TIA Portal version that will perform the export. If a version upgrade is required (for example, TIA V14 → V15 → V16), follow the Siemens upgrade recipe: make a working copy of the project, delete the global library in Copy #1 and attempt the upgrade, and keep the global library in Copy #2 — if vendor-specific blocks block the upgrade, replace them with IEC 61131-3 standard equivalents before retrying.
2. PC Worx Engineer / PLCnext Engineer — current release on the engineering workstation. A 2023.x or later LTS build is recommended for the most complete IEC 61131-3 round-trip support.
3. PLCnext Control firmware — current LTS image for the target AXC F 1152 / 2152 / 3152 or EPC 1522 controller. Pull the firmware image from the Phoenix Contact support portal and write it to the controller before commissioning.
4. MATLAB Simulink + Simulink Coder + PLCnext Target add-on — required only if Simulink models are part of the source project. The PLCnext Target for Simulink is a separately licensed Phoenix Contact product and is installed into MATLAB as an add-on.
5. Type mapping spreadsheet — list of every TIA-side DB tag, IEC timer instance, and SFC step. This document becomes your acceptance checklist.
6. Offline / sandbox controller — never perform a first-time migration directly on a production controller. The migration must be validated on a bench unit before cutover.

Step-by-Step Migration Procedure

Step 1 — Clean Up the TIA Portal Project

Before exporting, the source project must compile without errors and must not reference any vendor blocks outside the IEC 61131-3 standard namespace.

1. Resolve all compile errors in the active CPU.
2. Identify every SFB / SFC call by searching the project tree for the SFB and SFC prefixes.
3. Replace Siemens-specific blocks with IEC 61131-3 equivalents where possible:
   • SFB0 / SFB1 (CTU / CTD) → IEC standard CTU / CTD
   • SFB3 / SFB4 / SFB5 (TP / TON / TOF) → IEC standard TP / TON / TOF
   • SFB41 / SFB42 / SFB43 (CONT_C, CONT_S, PULSEGEN) → PLCnext PID function block from the PLCnext Technology library
4. Search the project for any case-insensitive match on "SFB", "SFC", or vendor library namespace prefixes and resolve each occurrence.

Step 2 — Export PLCopen XML from TIA Portal

1. Open the cleaned project in TIA Portal.
2. Right-click the S7-1200 / S7-1500 CPU in the project tree.
3. Choose Export > PLCopen XML....
4. Select the language elements to include: POUs, data types, GVLs, tasks.
5. Save the resulting .xml file to a working directory.
6. Validate the XML against the IEC 61131-10 schema using any XML validator — TIA Portal does not always flag schema violations before export.

Step 3 — Prepare the PLCnext Project Skeleton

In PC Worx Engineer / PLCnext Engineer:

1. Create a new project targeted at the PLCnext Control hardware (for example, AXC F 2152 running the current LTS firmware).
2. Define the PROFINET device catalog entries for any I/O stations that will replace the TIA-side ET 200SP / ET 200MP stations. PROFINET device GSDML files are portable, but the device configuration itself must be rebuilt.
3. Create empty POUs, data types, and GVLs that match the names exported in the PLCopen XML.

Step 4 — Import PLCopen XML into PC Worx

1. In PC Worx Engineer, right-click the project node.
2. Choose Import > PLCopen XML.
3. Select the exported .xml.
4. Review the import log for warnings — most commonly:
   • "Unknown data type X, mapped to DINT"
   • "Comment truncated to 255 characters"
   • "Instance variable renamed from X to X_1 (duplicate name)"
5. Manually re-bind any AT-overlapping variables that lost their % address attributes.
6. Compile the project.

Step 5 — Port HMI, Drives, and Safety Separately

PLCnext Engineer does not consume WinCC Comfort or WinCC Unified projects. Plan separate engineering tasks for:

• HMI — rebuild in Visu+ or migrate to a web-based HTML5 visualization served by the PLCnext web server.
• Drives — re-commission using the PLCnext Technology drives library (Axioline F I/O drives) or via the device's native tool connected through the controller's OPC UA server.
• Safety — Safety PLC projects (S7-1500F + Safety Advanced / Distributed Safety) cannot be exported as PLCopen XML. They require a complete re-engineering in PLCnext Safety using SafetyDesigner-equivalent tools.

Step 6 — Integrate MATLAB Simulink Models

If the source TIA project contains MATLAB Simulink models compiled to TIA blocks (Simulink PLC Coder + the S7-1500 / S7-1200 target), the equivalent workflow on PLCnext is:

1. Open the source .slx model in MATLAB Simulink.
2. Identify the GDS (Global Data Set) in / out ports that act as the model's data interface.
3. Install the PLCnext Target for Simulink add-on.
4. Re-target the model to PLCnext, keeping GDS ports intact.
5. Configure the build settings in MATLAB:

set_param(gcs, 'TargetHardware', 'PLCnext');
set_param(gcs, 'PLCnextLibraryName', 'MyModelLibrary');
set_param(gcs, 'GeneratePCWlxFile', 'on');

6. Build the model — Simulink Coder emits a .pcwlx file (PC Worx Engineer library) containing the shared object and metadata.
7. In PC Worx Engineer, choose Libraries > Add Library and import the .pcwlx file.
8. Instantiate the library function block in your project and wire GDS inputs/outputs to your program's variables.

The .pcwlx file behaves like a normal program block: you call it from a task and the shared object runs in the PLCnext real-time context.

Step 7 — Wire, Compile, and Validate

1. Map every PLCnext variable to a physical or PROFINET I/O address — the export stripped the addresses.
2. Compile the project and resolve any "implicit conversion" warnings by inserting explicit CONVERT or type-cast blocks.
3. Generate the PLCnext Engineer build artifact (PC Worx archive .pcwx / .pcwex).
4. Download to the offline controller.
5. Run the IEC checklist against your type-mapping spreadsheet:

Migration Workflow Diagram

Verification and Acceptance

A migration is not accepted until runtime behavior matches the source within documented tolerance. The following verification sequence is the minimum:

1. Static comparison — diff the POUs line-by-line. IEC 61131-3 textual languages (SCL, IL, ST) should be character-identical after import.
2. I/O loopback test — wire a known input pattern to the controller, capture the outputs, and compare against the same pattern run on the TIA simulator (S7-PLCSIM).
3. Functional test against the source FAT/SAT documentation — replay every test case in the original validation plan on the new PLCnext controller.
4. Long-duration soak test — at least 24 hours of uninterrupted run with a representative load profile, monitoring watchdog trips and task jitter in the PC Worx diagnostic view.
5. OPC UA namespace check — export the OPC UA address space from both controllers and confirm that every variable exposed to SCADA has the same name, datatype, and access level.

Common Import Converter vs PLCopen XML

It is worth distinguishing PLCopen XML (IEC 61131-10 source-code exchange) from the Common Import Converter, which is a Siemens tool for converting TIA Portal datapoint configurations into the Siemens Common Configurator (used in building-automation and Desigo CC integrations). They are unrelated. See the Siemens Common Import Converter product page for the building-automation use case.

Troubleshooting Matrix

Cross-Vendor Considerations

If the source project is not TIA Portal but rather another IEC 61131-3 platform — Allen-Bradley Studio 5000 / RSLogix 5000, Schneider EcoStruxure Control Expert, Codesys 3.5, Beckhoff TwinCAT 3 — the PLCopen XML path still applies with the same caveats. TIA Portal itself does not consume PLCopen XML for import (only export), so a Codesys → PLCnext migration goes via the source tool's PLCopen XML export, not via TIA.

For Allen-Bradley → S7 (TIA) → PLCnext chains, expect two separate conversion efforts rather than one combined workflow. There is no Siemens-published "Allen-Bradley to S7" converter that survives more than tag-name mapping.

Summary of Hard Migration Limits

The following items cannot cross from TIA Portal to PLCnext under any currently documented workflow:

• WinCC Comfort / WinCC Unified HMI screens and tag connections
• SINAMICS drive parameter sets (Startdrive commissioning)
• Safety logic (S7-1500F / F-CPU / Distributed Safety)
• S7-specific technology objects (TO_PositioningAxis, TO_SynchronousAxis, TO_OutputCam, TO_MeasuringInput, TO_ControllerPID)
• GRAPH sequencers
• ProDiag fault definitions
• TIA Portal Openness API customization scripts
• Reusable global library elements that wrap SFBs / SFCs

Each of these requires a dedicated re-engineering effort and a new validation test plan.

FAQ