Opening a V2.3 project

Requirement: CODESYS is started (or a project is already open). You should be aware of the restrictions described below the following instructions.

  1. Click File ‣ Open project .

  2. In the Open project dialog, click any CoDeSys V2.3 project or project archive in the file system. For searching, you can set the file filter on the bottom right corner of the dialog.

    ⇒ If another project is still open, CODESYS instructs you to close it accordingly. After that the CoDeSys V2.3 converter automatically starts.

  3. The V2.3 converter checks that the project can be compiled without errors. If so, then it processes the project automatically.

  4. NOTE: If the project contains visualization objects with placeholder variables that the converter cannot resolve, the respective visualizations are shown as a group in place of the visualization references.

  5. Device conversion: When a device (target system) is referenced in the project to be opened and no conversion rules are defined for the device, then the dialog opens for Device conversion. Specify here whether and how the converter should replace the previous device reference with a current one.

    ⇒ For replacement, the converter added the new device in the place of the old one in the device tree of the converted project.

  6. Library conversion: if a library, for which no conversion rule has so far been defined, is referenced in the project to be opened, then the Conversion of library reference dialog opens. Specify here whether and how the converter should replace the existing library reference with a current one. If you select a library for which the project information is missing, then the Enter project information opens in order to specify this information.

    ⇒ The converter loads the adapted project. Note: The redefined library references are to be found in the global library manager in the POUs view.

Restrictions when reusing a CoDeSys V2.3 project in CODESYS

Compilation:

The project has to be compilable without errors in CoDeSys V2.3. Note: CODESYS stills issues warnings in V3 when compiling. These are caused by implicit conversions, which can lead to a loss of information (for example through sign changes).

CODESYS checks “case” statements against the switch variable: CASE USINT OF INT is not checked in CoDeSys V2.3, but it issues an error message when imported into V3.
Controller configuration: The Controller configuration of a CoDeSys V2.3 project cannot be imported into V3. You have to recreate the device configuration and re-declare the variables used in the controller configuration.
Network variables: For network variables, CODESYS creates V3 GVL objects and imports the variable declarations. However, the network properties are not imported. See the description of the network variable exchange for this.
Libraries: All variables and constants that are used in a library also have to be declared in the library. It must be possible to compile the library in CoDeSys V2.3 without errors.
Syntactic and semantic restrictions since CoDeSys V2.3:

  • FUNCTIONBLOCK is not a valid keyword instead of FUNCTION_BLOCK.

  • TYPE (declaration of a structure) must be followed by a “:”.

  • ARRAY initialization** must have parentheses.

  • INI is no longer supported (you have to replace this in the code by the Init method).

  • In function calls it is no longer possible to mix explicit with implicit parameter assignments. Therefore the order of the parameter input assignments can be changed:

    fun(formal1 := actual1, actual2); // -> error message

    fun(formal2 := actual2, formal1 := actual1); // same semantics as the following line:

    fun(formal1 := actual1, formal2 := actual2);

  • CoDeSys V2.3 pragmas are not converted. They produce an warning in V3.

  • The TRUNC operator now converts to the data type DINT instead of INT. CODESYS automatically adds a corresponding type conversion for a CoDeSys V2.3 import.
Visualization:        
Placeholders and their replacement Placeholder VAR_INPUT Usage Replacement
  PLC_PRG.$LocalVar$.aArr[0] localVar: MyStruct; localVar.aArr[0] localVar := PLC_PRG.myStructVar
  $Var$.aArr[0] Var : MyStruct; Var.aArr[0] Var := PLC_PRG.myStructVar
  PLC_PRG.myStructVar.aArr[$Index$] Index : INT; PLC_PRG.myStructVar.aArr[Index] Index := 0
Problematic placeholders

  • Placeholders within a text:

    Text: $axle$-Axis

    Correction:

    localVar : STRING;

    Text: %s-Axis

    Text variable: localVar

  • Placeholder describes only one part of a variable name:

    axis$axis$spur$spur$.fActPosition

    Correction:

    Define only one placeholder for the axis$axis$spur$spur$ placeholder.

    axis_spur : MyFunctionBlock;

    Then directly transfer the corresponding instance of the function block.

    axis_spur := PLC_PRG.axis1spur2;

  • Placeholder is replaced by an expression:

    $Expression$ -> PLC_PRG.var1 + PLC_PRG.var2

    Correction:

    You must transfer the expression to an auxiliary variable and then transfer this auxiliary variable as an instance.

  • The placeholder describes a program name: $Program$.bToggle -> PLC_PRG.bToggle D

    The converter cannot transfer this form of setting placeholders in V3. However, you will rarely use it in practice.

  • Placeholder is replaced by different types:

    $Var$

    -> replacement 1 : PLC_PRG.n (INT)

    -> replacement 2 : PLC_PRG.st (STRING)

    Correction:

    Define two different placeholders in the interface for this.

  • The visualization is located in a library. You replace the placeholder later from any desired project when you use the visualization there.

    Correction:

    Here you have to replace the TYPE_NONE data types manually. However, there is also the possibility for you to integrate the library in a project and the placeholder is correctly replaced. If you now import this project, the data type is also determined correctly in the library.
Non-importable elements: Trend, ActiveX – the import is not possible, because the implementation differs a great deal. In V3, a corresponding warning is issued and a corresponding manual reproduction is required.
Programming languages ST, IL, FBD: No restrictions
  LD:

CODESYS imports function blocks with parallel branches in such a way that the part before the branch is repeated for each branch. This corresponds to the generated code that CoDeSys V2.3 creates for parallel branches.
  SFC:
  • Step variables explicitly declared by the user must be declared locally in the SFC editor. You may not declare them as VAR_INPUT, VAR_OUTPUT or VAR_INOUT, because CODESYS cannot automatically adapt the calls. Explanation: Steps no longer use boolean variables for the management of the internal states in V3, but also structures of the type SFCStepType.
  • Identifier: the following identifiers may not begin with an underscore character:
    • Names of IEC actions in the tree
    • Variables that are called in an IEC association list
    • Names of transitions that have been programmed out

Explanation: In V3 the implicit variables that CODESYS creates for actions are given an underscore character as prefix. An invalid identifier with a double underscore character would result.
  CFC:
  • Large boxes: The layout of large boxes can lose quality due to an import. The boxes may overlap one another too much. (Correction planned).
  • Macros: Macros cannot be imported. (Correction planned).

See also