Create generic Alarms in AS V6

Ask Questions
,
1

Actually I want to migrate my V4 Modules (written in ST) to V6 within my generic AlarmX- handling. In V4 I use the “MpAlarmXConfigT”-structure to decide whether the Alarm is an Acknowledged-Alarm or only an Information. To create an generic Alarm I used the function “MpAlarmXConfigAlarm”. Unfortunately, this functionality was changed (also the name of the function) in V6. Did someone know how this works in V6?
Many greetings
Frank

2

Hi!

Starting in mapp Services 6.0 you have a new function block MpComConfigBasic (or MpComConfigAdvanced). You can use either of these to modify the configuration of MpAlarmX.

I would suggest to first take a look at the help:

There is also an example of how to add a new alarm to the configuration…

Let us know if this helps you :wink: (or if you need more information)

1 Like
3

Hi, now I am able to create generic Alarms with MpComConfigAdvanced. When I write to flash I can see them as red additional items in On-Offline-Compare. But when I raise an Alarm with MpAlarmXSet the Return-Value is Zero (no item found). Has someone an idea how to “activate” the AlarmX-System? All modules “MpAlarmXCore”, “MpAlarmXListUI” and “MpAlarmXHistory” are active and are running.
mg Frank

4

Hmmm… That is interesting, for me it is working. Some clues:

  • Have you linked the “MpAlarmXList” configuration in the “MpAlarmXCore” configuration?
  • Which MpLink have you specified on the MpAlarmXSet?
    • This function needs the MpLink of the MpAlarmXCore configuration.
    • The MpLink of the MpAlarmXList configuration is not valid!
  • Are you able to set “pre-configured” alarms (those you directly configure in your AS project)?

And for reference, here is my test program:

PROGRAM _CYCLIC
    Advanced.MpLink := ADR(gAlarmXList);
    Advanced.Enable := TRUE;
    Advanced.Data := ADR(AlarmCfg);
    Advanced.DataType := mpALARMX_CFG_ALARM;
    Advanced.ApplyTo := mpCOM_CONFIG_TARGET_CFG;
    Advanced();
    
    IF (SetAlarm) THEN
        (* Make sure to specify the name of the MpAlarmXCore MpLink here *)
        ID := MpAlarmXSet(gAlarmXCore, Name);
        SetAlarm := FALSE;
    END_IF;
    
    IF (Advanced.CommandDone) THEN
        Advanced.CmdOpen := FALSE;
        Advanced.CmdWrite := FALSE;
        Advanced.CmdClose := FALSE;
    END_IF;
END_PROGRAM

And the corresponding variables:

VAR
    Advanced : MpComConfigAdvanced;
    AlarmCfg : MpAlarmXCfgListAlarmType;
    SetAlarm : BOOL;
    Name : STRING[80];
    ID : UDINT;
END_VAR

And here the configurations:

image
image336×224 6.2 KB

image
image350×208 5.99 KB

Then just perform these steps in the watch window:

  1. Give CmdOpen
  2. Give the new alarm (AlarmCfg.Name) a name
  3. Give CmdWrite
  4. Give CmdClose
  5. Set Name to the name of your alarm
  6. Set SetAlarm to TRUE
  7. Observe the value of ID
5

Hello,
now its working. The problem was that I mixed the two pointers from MpComIdentType.
p_AlarmXList: should be used for MpComConfigAdvanced and
p_AlarmXCore: should be used for MpAlarmXSet
I recognized still a difference to V4:
In AS V4 the generic Alarmbuilding with MpAlarmXConfigAlarm works “quasiparallel” over all taskclasses. I do not have to serialize the calls. In AS V6, when I replace it with MpComConfigAdvanced, only the last call works. I have to serialize the calls, even if I have different localstatic memory to work on. The startup-Time for the generic alarmgeneration is now much longer.
Is there a posibility that MpComConfigAdvanced works like MpAlarmXConfigAlarm?
The last possibility is to run the Alarmgeneration in INIT-Mode if there is a possibility to debug the code.
Greetings Frank Nonnenmacher

6

I am not sure I fully understand how you had your V4/5 logic built up.

But (at least in theory) the new MpComConfigAdvanced has better performance. The reason is that it only has to open the config once (rather than every time again). Here’s the key differences:

MpAlarmXConfigAlarm

Opens, loads and writes the configuration every time you save an alarm (regardless of new alarm or modification of existing alarm). The most expensive part is the write, as this will notify MpAlarmX (the component itself) that it has to re-load the complete configuration.

Process Outline:

  1. Open the configuration
  2. Load the configuration
  3. Write the configuration (e.g. new alarm)
  4. Save the configuration
    4.1. Notify MpAlarmX to reload the configuration

MpComConfigAdvanced

This one is in your hands. If you know you have to add 100 new alarms (for example), you can open and load the configuration once, then just call CmdWrite for every new alarm and only then you CmdClose. In this case the MpAlarmX component will only be re-loading the configuration after it has been closed (rather than every time).

Process Outline:

  1. Open the configuration
  2. Load the configuration
  3. Write the configuration (e.g. new alarm) → can be repeated multiple times!
    3.1. For adding new alarms I would recommend to set the WriteMode = mpCOM_CONFIG_WRITE_APPEND
  4. Save the configuration with CmdClose
    4.1. Notify MpAlarmX to reload the configuration

Note: The MpComConfigBasic works differently! This one is more similar to the old MpAlarmXConfigAlarm in that it re-opens and re-saves the configuration for every write…

But: I do not have any “real-world” measurements (but would be curious about your current and previous processes :wink:).

Regarding debugging in INIT: I don’t know if/how that is possible (but I think I have seen a question somewhere here on the community :thinking: )

7

For one call of MpComConfigAdvanced in the whole project your statement is correct. But my intention is, to build ST-modules including generic alarms. My modules contain up to 16 Errors/Infos which are risen in a solid-state-machine with MpAlarmXSet in the same ST-module. When the AutomationRuntime starts, each of my modules starts (quasiparallel) multiple MpComConfigAdvanced calls on different localstatic memory in cyclic mode. When I start 4 modules in one taskclass only the last module is able to write in RAM or Flash. The generated alarms of the first three modules are lost. All modules get on each action the DONE-Flag.

8

OK, now I (think I) understand your issue/point…
I guess you could try to use the MpComConfigBasic instead of the *Advanced… This one behaves similar to the MpAlarmXConfigAlarm in that it opens, loads, writes and saves (basically as one command).
However, I have never tested this and so cannot guarantee that it works as you would expect/need…

9

Now it works. I generate 50 Alarmlistitems. This is the expected maximum of my modules which have an alarmhandling. On the very first INIT I generate an array with all adresses of alarmlistitems (gAlarmXList_1, gAlarmXList_2 … gAlarmXList_50). Its not a fixed relation from Module to AlarmXList, it depends on the sequence of the INIT-calls. If I have more time in future I will put the alarmgeneration in the INIT of my modules. Thanks for your help greetings Frank

10

That’s great to hear! :tada:

PS: Please don’t forget to mark the answer/reply that helped you the most :wink: