Importing CODESYS ST Programs and FBs into LogicLab

LogicLab 2.3.0 introduced an object-level path for moving Structured Text from CODESYS through a .exp export file. The supported objects are CODESYS programs, functions, and function blocks written in ST. Treat the transfer as source-code migration, not as a complete conversion of the controller project, hardware configuration, task schedule, libraries, or field I/O.

Why do the usual fixes fail?

Several tempting fixes act on the wrong part of the transfer chain. Look at the exported object and the importer result first. Changing unrelated project settings cannot repair missing or incompatible source content.

• Renaming a file to .exp: an extension does not create the export structure that LogicLab expects. Generate the file with the CODESYS export operation.
• Copying ST directly between editors: this may move visible statements, but it can omit declarations or separate referenced objects. Use the object export and import path before resorting to manual reconstruction.
• Adjusting the target hardware or I/O configuration: those settings affect execution after compilation; they do not make an unreadable export file valid.
• Trying to migrate an entire project as one supported object: the documented workflow selects exported functions, function blocks, or programs. Import the required objects and rebuild the surrounding application in LogicLab.
• Retuning application logic before validating signals: changed behavior after migration may come from declarations, I/O mapping, task assignment, or dependencies. Tuning does not fix wiring, and parameter changes do not fix a broken software interface.

What actually causes an import or runtime mismatch?

The transfer has four stages: the CODESYS object, its exported .exp representation, the LogicLab object importer, and the reconstructed destination application. A fault at each stage produces a different symptom. Import failure points toward the file, object type, language, or parser-visible content. A successful import followed by compilation errors points toward declarations or dependencies. Successful compilation with incorrect machine behavior moves the investigation downstream to task execution, mapped variables, and physical signals.

The language boundary matters. The stated import capability covers objects written in ST.

What should be checked before exporting?

Start with the source object rather than changing the destination blindly. Record whether each item is a Function, FB, or Program, then identify everything it calls or references. An ST body rarely operates alone: project data types, constants, global variables, nested function blocks, and library-defined elements may be required for compilation.

Confirm that the LogicLab installation is version 2.3.0 or later because the CODESYS import capability begins at that release. Keep the source project unchanged until the imported application passes compilation and behavior tests. This preserves a working reference for declarations, initial values, state sequencing, and signal comparisons.

Define an acceptance test before migration. For a function, select known input values and expected return values. For an FB, include initialization, state retention, and output transitions. For a Program, capture the relevant input conditions, execution sequence, and commanded outputs. A source-code comparison alone cannot prove equivalent control behavior.

How do you import the CODESYS objects?

1. Open the source project in CODESYS and select the ST objects required by the destination application.
2. Export those objects from CODESYS. The operation creates a file with the .exp extension.
3. Open the destination project in LogicLab version 2.3.0 or later.
4. Choose Import Object from library and open the CODESYS .exp file.
5. Select the exported Function, FB, or Program from the file and import it.
6. Repeat the export or import selection for every required dependency that is represented as another transferable ST object.
7. Inspect declarations before editing the implementation. Resolve missing types, variables, called objects, and library interfaces in dependency order.
8. Compile the destination project. Separate importer errors from compiler errors: the former concern reading or creating the object, while the latter concern its integration into the LogicLab application.
9. Bind the imported Program or FB instance into the destination execution and signal path as required by that controller application.

How do you verify that the migration worked?

Verification follows the control path from measured value to controller decision to final command. First confirm that the destination variables receive the same test inputs used in the CODESYS reference. Then monitor internal states, calculation results, and branch conditions. Finally compare the output commands before allowing them to drive the final element.

1. Compile with no unresolved declarations, calls, or data types.
2. Confirm that each imported object has the intended type: Function, FB, or Program.
3. Apply recorded test inputs and compare calculated values and Boolean decisions with the source behavior.
4. For FBs, test startup values, repeated calls, retained state, and reset paths.
5. For Programs, verify that the destination execution configuration actually calls the logic.
6. Check physical I/O mapping independently from the algorithm. An inverted, stale, scaled, or unmapped input can make correct ST appear defective.
7. Observe outputs at the software boundary before releasing commands to actuators.

Which migration pitfalls recur?

Partial exports are the most common integration trap. A top-level Program can import cleanly and still depend on functions, FBs, data definitions, or library facilities that were not transferred. Follow each unresolved identifier back to its defining object instead of modifying the calling logic to hide the error.

Name collisions can also obscure the result. If the destination already contains an object with the imported name, inspect which definition the application resolves and retain one controlled implementation. After any rename, update every reference and compile again.

Compilation is not proof of execution equivalence. Different task placement, initialization, variable binding, or I/O scaling can change results without producing a compiler error. Look at the trend first: compare the input, internal result, and output command in order. Adjust logic only after locating the first point where the values diverge.

FAQ