As a library developer, you can define alarm conditions for a specific function block or structure type.
In concrete terms, this means that you create an alarm group template object for the variables of such POUs and configure alarm definitions in them. The alarm group template object for the POU object is then located in parallel in the POU tree or device tree. The alarm definitions from this are later instantiated in the application in the “Alarm Configuration” object in order to perform an alarm check at runtime.
As a user, you can use library POUs which include alarm definitions for the supported creation of an alarm configuration. By the way, you will also get support with the alarm configuration in your application during the entire development process. Below your application, add an alarm configuration. A special generation cycle then creates the alarms for the instances of function blocks with alarm definitions. To do this, execute the “Create or update alarm instances” command so that alarm instances are also created for all instances.
You can continue with the editing of the alarm configuration. For example, you can deselect individual alarm instances.
To keep the application code consistent with the alarm configuration, the completeness and correctness of the alarm instances is checked when the IEC code is compiled. The result is displayed in the message view so that you are always informed about the status of the alarm configuration. If you do not want this, then you can disable the “Check alarm instances during compilation” option in the alarm configuration.
You can use the alarm_creation_default
attribute pragma to control how the default for this
instance should be with regard to creation.
-
Defining alarm classes centrally in library
-
Using function blocks with an alarm group template in a library
-
Function block with inheritance
-
Creating and renewing alarm instances
-
Checking the project