-

Automation Modules and Aspect Hierarchies

This topic contains the following information:

PLCnext Engineer provides the possibility of using Automation Modules which are used together with so-called Aspect Hierarchies. Automation Modules can only be activated together with Aspect Hierarchies.

This feature allows to prepare and reuse entire machine modules.

Activating the feature

  1. To activate the feature, select 'Extras > Options' and open the category 'Extensions > Aspect Hierarchies'.
  2. Mark the checkbox 'Enable Hierarchies' and confirm the dialog.
After restarting PLCnext Engineer,

Term definition: Automation Module

An Automation Module is a logical combination of several (at least two) so-called artifacts. An artifact designates a component type defined in the COMPONENTS area including the instance-related information how this type is connected to other artifacts (types) which are also part of the same Automation Module. You might consider an artifact as a "not yet assigned instance of a type".
Consequently, an Automation Module does not only contain several types but also the relations these types have to each other when instantiated.

Currently, the following types can be used as artifacts in Automation Modules:
Examples for Automation Module:

When using (instantiating) an Automation Module in the project, the contained artifacts must be located manually in the project. This has to be done by defining an instance for each artifact: a program POUs must be instantiated in a task, an FB in a program POU, an HMI symbol in an HMI page, a device in a device list (station editor). In doing so, the instance-related connections between the types are automatically created in the project. Figuratively, the assignments between the types are restored from the Automation Module and applied to the actual type instances you defined.

This way, entire machine modules can be instantiated in an easy and effective way.

Note
In the current PLCnext Engineer version, Automation Modules are only provided as libraries.

Term definition: Aspect Hierarchy

The term Aspect Hierarchy suggests that the project, or more specifically the PLANT can also be considered under different aspects than the well-known instance-related view: you can look at the plant under a functional aspect as well as under a locational aspect. For that purpose, further PLANT views are available which can be considered as aspect-related views each with its own logical arrangement/layout of objects.

After enabling the Aspect Hierarchies, the following views are currently available in the PLANT (future aspect-related views are possible):
Instance viewThis view on the project is also available if the Aspect Hierarchies are disabled. Even when enabled, the instance view is the leading view on the project. All unassigned artifacts coming from an Automation Module must be assigned here.

Note
Any unassigned artifacts, which remain in the 'Unassigned' category below the tree in the instance view, are ignored by the compiler, i.e., they are not used in the project.

Functional aspect viewThis view allows to consider the plant under functional aspects. The tree allows to create own aspects thus structuring the PLANT under functional viewpoints. Example: user-defined functional aspects could be MachinePartXY or Robot.
This is an optional and independent view, i.e., there may remain unassigned artifacts which are not located in any folder of this aspect view.
Locational aspect view This view allows to consider the plant under locational aspects. The tree allows to create own aspects thus structuring the PLANT under site-related viewpoints. Example: user-defined locational aspects could be FactoryFloorXY or OutgoingSorting.
This is an optional and independent view, i.e., there may remain unassigned artifacts which are not located in any folder of this aspect view.
Automation Modules viewThis view lists all instances of Automation Modules that have been inserted from the COMPONENTS area into the PLANT. The contained artifacts of a module are visible here.

After having inserted a module from the COMPONENTS area into this view, the contained artifacts are sorted into the 'Unassigned' category of all other views.

Working with Aspect Hierarchies and Automation Modules

The following procedure does not only apply to Automation Modules but also to single types (available in the COMPONENTS). The greatest benefits of the Aspect Hierarchies in the different PLANT views, however, is only unfolded in combination with complex Automation Modules as these modules contain artifacts that can be located in different aspects.

  1. Edit the functional and/or the locational aspect view, for example, by adding new aspects (via the context menu) or by structuring the tree.
  2. Drag the required Automation Module from the COMPONENTS area into the desired view in the PLANT.

    Note
    Automation Modules cannot be dragged into the instance-related view, i.e., into the usual project tree because they consist of different artifacts which cannot be instantiated in only one particular folder of the instance tree. Instead, Automation Modules can only be dragged into the functional or locational aspect view as the contained artifacts can be assigned to aspects.

    After dropping an Automation module on an aspect (folder), the contained artifacts are unpacked and listed under the Automation Module. Additionally, they are inserted in the 'Unassigned' category below the instance tree in the instance-related view.

    In the same way, you can also drag single types from the COMPONENTS into the functional or locational aspect view. After dropping a single type on an aspect, the type also appears in the 'Unassigned' category in the instance-related view.

  3. Switch to the instance-related view (usual project view).
    Create instances of the artifacts (or single types) which are still unassigned.

    Note
    The instantiation of artifacts can only be done in the corresponding editor which is open in the editors area. It is not possible to instantiate by dragging an unassigned artifact onto a PLANT node.

    • For an unassigned program POU: open the 'Tasks and Events' editor and drag the program into the grid to create a program instance.
    • For an unassigned function block POU: open a program or FB POU, create an instance variable in the variables table and an FB call in the code worksheet.
    • For an unassigned device/module: open the 'Device List' (station editor) of the respective hardware controller or device and drag the unassigned device or module into the list to create an instance.
    • For an unassigned HMI symbol: open or create an HMI page and drag the HMI symbol into the page.

    After having created an instance for an artifact in the instance view, the respective artifact is removed from the 'Unassigned' category.

    Note
    Any unassigned artifacts, which remain in the 'Unassigned' category below the tree in the instance view, are ignored by the compiler, i.e., they are not used in the project.
    When an artifact has been assigned, it is removed from the 'Unassigned' category in the instance-related project view. It is, however, still unassigned in the aspect-related views, as these are independent from the instance-related view which allow unassigned artifacts.

  4. If desired, switch to the functional and/or the locational PLANT view and assign unassigned types to available aspects. This is, however, not mandatory. The project remains valid and compilable, even if types remain unassigned in the functional or locational view.

    To assign an artifact or single type in the functional or locational view, drag the object from the 'Unassigned' category onto the respective aspect folder. By dropping it there, it is assigned to this aspect.

    When an instance of an artifact has been created in a particular aspect view, the respective artifact is removed from the 'Unassigned' category of this view.

When each artifact of an Automation Module has been instantiated as described above, the connections between the types are automatically created in the project. Figuratively, the assignments between the types are restored from the Automation Module and applied to the actual type instances you defined. This way, for example, the mapping of process data to POU variables or the connections between POU variables and HMI symbol parameters are valid again.

Instance editor for Automation Modules

Double-clicking an instantiated Automation Module in the 'Automation Module' view of the PLANT, opens the instance editor in the editors area. The editor tab is labeled with the module name with the file extension *.ami.

The editor shows status information on the current Automation Module instance by listing all contained artifacts with the Project, Location and Function, if assigned for this particular instance.

Example