Concept

The TwinCAT variant management supports you from build 4024 in the implementation and maintenance of machines for which you offer different variants. For example, four variants are used in the following:

  1. Version: Basic machine
  2. Version: Basic machine with the option A
  3. Version: Basic machine with the option B
  4. Version: Basic machine with the options B and C

All four variants are largely based on the same configuration and code basis and differ only slightly due to the options. Examples of these options are a varying axis layout due to different product properties and the dynamics derived from them as well as an additional processing step with further hardware and software.

Division into four individual TwinCAT projects would lead to considerable added expenditure on account of the large overlaps, since changes to the common basis would have to be entered in the different projects in parallel. At this point the TwinCAT variant management enables the different machine variants to be configured, implemented and entered in just one TwinCAT project and in this way to minimize the necessary expenditure.

Project variants and groups of variants

The settings whose values differ for the different variants can be managed in so-called project variants within a TwinCAT project. A total of four project variants would be created for the example named above and the configurations necessary for option A would be carried out exclusively for the second project variant.

If you wish to make settings for several variants at once, you can define a group of variants. It provides a view of several project variants at once. The specific settings for the option B, which are contained in both the third and fourth variant, can be adopted simultaneously for both project variants with the help of such a group. In this way the necessary configuration expenditure is minimized.

A special group that is automatically added when creating the first variant is the group [All]. It provides a view of all existing project variants and can be used accordingly to adopt a specific value of a setting for all available variants.

Activation of the configurations

If a group is selected it is not possible to activate the configurations, as different variant-specific values for a setting can lead to an undefined state. Select an individual project variant before activation.

User interface

The new TwinCAT XAE Project Variants toolbar for the variant management is delivered with build 4024. Via this toolbar you can open the Manage Project Variants dialog for the creation and management of project variants and also select the desired active variants. On selecting a variant, the TwinCAT project will be automatically reloaded with the corresponding variant-specific values.

An object in which at least one setting is enabled for the variant management is displayed with a blue triangle in the top right-hand corner of the icon in the project tree. In the case of an output terminal the standard icon Concept 1: would be extended accordingly: Concept 2:. If a group is selected that contains variants in which different variant-specific values have been saved for a setting, the icon in the project tree is supplemented with a yellow/blue triangle. In this case the icon of the output terminal would look like this: Concept 3:.

Integration in the PLC project

The TwinCAT variant management features continuous integration into the PLC project. For this you can define variant-specific compiler definitions at System Manager level for a PLC project. The definitions are forwarded automatically to the PLC project and can be evaluated within the PLC project. The PLC for the variant management must first be enabled for this.

Concept 4:

The compiler definitions at System Manager level can be changed in the editor as shown above. There are two Project tab for compiler definitions:

  • Manual: You can define your own compiler definitions that are saved only for the selected variant and forwarded to the PLC project.
  • Implicit: If the "Implicit" function is activated, the names of the selected variants as well as all groups to which the variants belong are automatically set as compiler definitions and forwarded to the PLC project.

For the evaluation of the compiler definitions within the PLC project you can use conditional compilation and conditional referencing of libraries.

 

Conditional compilation in the PLC project

Conditional compilation is possible both in the declaration editor and in the programming editor within the PLC project with the help of Conditional pragmas. In this way sections of the program code defined by you can be automatically included or excluded depending on the selected variant.

Sample of conditional compilation in the declaration editor:

                                                                                                                            PROGRAM MAIN
VAR
    {IF defined (Variant1)}
        (* The following variables are only declared, if the compiler define 'Variant1' is set *)
        sVariantUsed                : STRING := 'Variant1';
        bOutput            AT %Q*    : BOOL;
    {ELSE}
        (* The following variables are only declared, if the compiler define 'Variant1' is not set *)
        sVariantUsed                : STRING := 'NotVariant1';
        bInput            AT %I*    : BOOL;
    {END_IF}
END_VAR

Sample of conditional compilation in the programming editor:

                {IF defined (Group1)}
    (* The following code is only executed, if the compiler define 'Group1' is set *)
    nCounter := nCounter + 1;
{ELSIF defined (Group2)}
    (* The following code is only executed, if the compiler define 'Group2' is set *)
    nCounter := nCounter - 1;
{END_IF}

 

Conditional referencing of PLC libraries

Via the Command Properties setting in the Conditional Referencing category, you can add entries to the desired library in the Properties window. These entries are compared with the compiler definitions set for the PLC project. The library is actively referenced on condition that at least one of the entries corresponds to one of the definitions. If none of the entries correspond, the library is deactivated and grayed out in the project tree. In this case, any license necessary for the use of the library in the PLC project will be ignored.

In the sample of the following screenshot of a Properties window, the Tc3_CM library is only active if the Variant1 or Variant3 entry is set as a compiler definition. Otherwise it is deactivated and the corresponding license is not needed.

Concept 5:

Integration into the stand-alone PLC project

The variant management supports the workflow of the stand-alone PLC. Basically, the stand-alone PLC project is a self-contained project outside of the System Manager project and can be managed both in the same Solution and in a separate Solution. In the System Manager, only the TMC file is added as an existing element instead of the complete PLC project. As a result, the PLC and System Manager projects can be clearly separated from each other.

Since they are both self-contained projects, they both have their own variant configuration. If you are planning an identical configuration in both projects, you can import an already existing configuration into the second project.

The challenge in using a stand-alone PLC project created for a specific variant is that it must be created in the right variant beforehand in the System Manager project when updating the TMC file. Otherwise the boot data and the process image will not match. For that reason it is possible to create both the boot data and the TMC file for a specific variant and to save them. Instead of the TMC file, the project file .tcpproj of the stand-alone PLC project can then be added in the System Manager project. In this way you have the option to select the desired variant of the PLC project manually or automatically in the System Manager project via the variants configured there. Further information can be found here.

Concept 6:

 

See also: