Local PLC engineering preflight

PLCopen XML Vendor-Portability & Dependency Diff

Review what an exported PLC project depends on before moving it between engineering systems. Compare declarations, code and vendor metadata with file and line evidence.

Project exports

One baseline is required; the candidate is optional. Teaching exports are loaded initially. Each input: UTF-8 XML ≤ 4 MiB, 60,000 elements, 96 nesting levels, 2,000 definitions and 20,000 dependency occurrences. Analysis runs in a worker with a 30-second timeout.

Ready to analyze locally.

Files and pasted project code stay in this tab. No uploads, external library fetches, compiler execution or PLC connections. Clear removes the current workspace.

What can break when importing PLCopen XML?

TC6 XML describes PLC declarations, textual and graphical bodies, configuration and task information. An importer can understand the XML container while lacking a referenced function block or vendor-specific behavior. Review unresolved dependencies, hardware addresses, task settings and extension handling together. An extension marked handleUnknown="implementation" requires special attention because its contents may affect implementation. The tool inventories it and marks the audit incomplete; it never removes vendor data or generates a deployment project.

POU, datatype and library dependency evidence

POUs, named datatypes and configurations are matched by kind and case-insensitive name. Derived type declarations, graphical block type names and configured program instances form explicit edges. ST comments and strings are excluded before recognizing function-like tokens; a declared local function-block instance maps to its derived type. Unrecognized standard functions, conversion syntax, qualified methods, external libraries and missing names stay unresolved. IL, indirect calls, dynamic dispatch, SFC action execution, graphical wire evaluation, library contents and vendor dialects are outside call resolution. Direct I/O addresses and tasks remain visible review findings.

Compare old and new PLC project exports

The diff reports added, removed and changed definitions, producer identity and vendor extensions. Canonical comparison expands XML namespaces, sorts attributes and ignores formatting whitespace between elements, while preserving textual code and graphical coordinates. Interface, main-body and POU-kind changes are labeled when applicable; other metadata, action, transition, layout and extension changes remain definition changes. Reordered declarations or changed code spacing can produce a change. This is a structural content diff, not a semantic equivalence check, breaking-change proof or rename detector. Missing sections make comparisons provisional.

Supported format and local validation

Supports uncompressed UTF-8 XML 1.0 in the PLCopen TC6 2.01 namespace, with ASCII element/attribute names and Unicode values and code. The bounded namespace-aware reader refuses invalid XML framing, duplicate attributes or project sections, duplicate case-insensitive definition names, DTDs, external entities and unsupported versions. It does not load schemas or validate full TC6 grammar, parameter types, graphical connections or IEC language semantics. A completed inventory is an analysis aid. Before migration, validate with the official schema, import and compile using the target vendor and library versions, review hardware and task mappings, and test behavior in an isolated engineering environment.

Frequently asked questions

Which PLCopen XML version is supported?

The bounded reader supports XML 1.0 UTF-8 project exports in the TC6 2.01 namespace http://www.plcopen.org/xml/tc6_0201. It is an inventory and static diff, not an XSD validator. Other namespaces, compressed projects, DTDs and entity declarations are refused.

Does a clean inventory prove vendor portability?

No. Library implementations, compiler dialects, hardware mappings, scheduler behavior and extension semantics need verification in your target engineering environment. Unknown symbols stay unresolved. This tool never compiles, executes, connects to a PLC or certifies an import.

How are dependencies found?

Declared derived types, FBD/LD block type names and configured program instances provide explicit XML evidence. ST call candidates are recognized after removing comments and strings, with local function-block instance names mapped to their declared types. This is lexical analysis, not complete IEC language parsing or proof of reachable calls.

Are project files uploaded?

No. The two XML inputs are read in this tab and analyzed in a cancellable local Web Worker. Files, code and report values are masked from session analytics. Clear removes current inputs and results.

PLCopen reference

The PLCopen XML Exchange overview explains the interchange format. Obtain the TC6 2.01 technical document and schema from PLCopen’s official downloads. Target-system documentation remains authoritative for importer, library and runtime support.