Creating Alarms with MpAlarmXConfigAlarm takes very long

Hello,

depending of the machine configuration I have to write a lot of Alarms with MpAlarmXConfigAlarm. The save command takes ever longer, if the number of already saved alarms increases. Any ideas, how to speed up this?

1 Like

Hello Christian

This is a known problem which some of our Swiss customers already faced.

The reason is, that the MpAlarmXConfigAlarm FB was not designed for this use case. The procedure of the MpAlarmXConfigAlarm always makes the full sequence of:

  • Opening the whole alarm list configuration of the MpAlarmXCore and load it to DRAM
  • Check if the alarm you configure exists
    • If so, modify the alarm
    • If not, add the alarm
  • Close the whole alarm list configuration and write it to the USRROM config object
  • Apply the changes to the active component and trigger necessary component updates.

I’m not a mapp developer, so some points may be inaccurate, but the point is, that many repeating actions occur which take a long time, especially for bigger alarm lists. The MpAlarmXConfigAlarm call time increases exponentially for each alarm you add to the list.

You have two options to improve the performance.

Split your MpAlarmXCore

The easiest option is to split up your MpAlarmXCore into multiple smaller ones. You could e.g. make one alarm core for each task or each module of your machine. As the MpAlarmXConfigAlarm time increases exponentially for each alarm in the list, you will be much faster with this approach. Configuring 1000 Alarms on one core may take 15min while configuring 20 alarms each on 50 separate cores will probably finish within few seconds.

You can then make a hierarchy with MpComGroup components or with the MpComLink() function and escalate the alarms, so you will still have all alarms in one list on the UI.

Use MpComConfigManager

With the MpComConfigManager function block you can export and import whole mapp Component configurations in the XML format. With this approach you can freely configure all your mapp Components during runtime as you wish.

The disadvantage of this approach is, that you need to figure out the XML generating yourself. The advantage is, that you can configure everything, so adding snippets… is also possible.

Future

As we had a lot of product requests for this matter, there will be a couple of nice new features in the upcoming release of mapp Services V6.0.

First, the configuration of MpAlarmX in the AS editor is already much more modularized, which may make some programmed approaches obsolete.

Second, there will be new configuration FBs, similar to MC_BR_ProcessConfig / Param of the mapp Motion. These FBs will also support and Open - Edit - Close mode, which prevents the issues with the current implementation.

6 Likes

@patrick.tanner has already answered your question perfectly. I would like to add only two additional points from my experience in the past:

→ if the alarms are not changed after each restart or power off/on, it is enough to configure it once during first start up and not after each restart

→ some time improvement can be achieved if MpAlarmXCore.Enable = true is set after configuration is finished.

1 Like

I would not recommend this approach if not absolutely necessary. This approach can lead to a lot of confusion and inconsistency during development / commissioning because of code adjustments and transfers. Believe me, I speak from experience :wink:

Didn’t know this one. Do you have any rough numbers on how much is “some time”?

→ as far as I know configuration is stored in data module, so should not cause any inconsistency. You can even upload it to the project after you are finished. But of course you have to take this into consideration during transfer etc. So this would be good solution if you generate alarms only once at the beginning (if you have e.g. more types of the machines) and you do not change it later on.

→ I do not have any time, from our test in the past I could see some improvement but it depends on project, how many alarms you want to create etc etc. Bud do not expect that if will reduce minutes to seconds.

The inconsistency does not directly come from the transfer itself or the data object, but from the changes, or even from the build.

Various situations (there are probably even more):

  • You made a rebuild
    → The mapp AlarmX object will be transfered
    → All generated alarms will be lost
    → The alarms need to be generated again

  • You made a change to the other MpAlarmX settings
    → The mapp AlarmX object will be transfered
    → All generated alarms will be lost
    → The alarms need to be generated again

  • You added / changed / removed an alarm in your last code change
    → The alarms need to be generated again

  • You use the upload of the configuration to the AS project after generating
    → Less regenerating needed
    → The programmer needs to be very careful, and not forget to update the AS project on each change
    → The programmer needs to think if regenerating is needed on each change

What it means is, that on each project transfer you need to regenerate the alarms in order to be sure to have the correct alarm configuration. This also means that you need to wait for the configuration on each transfer.

If you do not generate the alarms on each transfer, you need to be VERY careful on what you changed. Otherwise, some alarms that you defined in your code may not exist, or alarms that you already removed may still exist. If you use alarm reactions with severities this may even lead to machine damage if not handled properly.

So, for a developer who is always very careful and does always exactly know how the build / transfer system of B&R works, and always has time to wait for generating the alarms this solution is ok. Especially during commissioning, I would not rely on so many ‘always’ points to think of :upside_down_face:

We had very troublesome support cases with this approach in the past. So, I would really not recommend it.

ok. your points are absolutely valid and must be taken into consideration, for sure. So good knowledge sharing with community here :slight_smile: @istech can select way he prefers :wink:

4 Likes

Many thanks for the informations. So I will be looking forward to V6.0. Is there already a release schedule?

Thank you for your points. The first point I knew. They are only written, if configuration (means not the AS configuration) changes. The second point, I will give a try, while I’m waiting for a possibly better solution with V6.0.

Many thanks for the informations. So I will be looking forward to V6.0. Is there already a release schedule?

The current AS6 release timeline is mid-2024!

3 Likes

Thanks for the info, Patrick. The MpAlarmXConfigAlarm FB is using 100% CPU as an idle time process, possibly missing a .sleep() .?
Also, if this FB isn’t meant for configuring alarms dynamically, why not? Many other dynamic FBs you offer handle similar tasks well?

Hi @patrick.tanner

I have gone through the same issue as Christian, I am trying to split my alarm X core as you mention and create a hierarchy, I am struggling to create the link, are you able to give more instructions/ example for making the links/ hierarchy. I would like to use the MpComLink() function, I can’t seem to get the link to work..

I have tried the function call in the INIT routine as the help advises.

Using AS4.12, mapp 5.23

Thanks! :smiley:

Hi @whyleys
Can you show me how you called MpComLink()?

It should be quite straight forward, e.g.:

PROGRAM _INIT
    MpComLink(gAlarmCoreParent, gAlarmCoreChild);
END_PROGRAM

Be aware, that according to the Help, the components must be Enable FALSE in the moment of linking.

If the application is not too dynamic, you can also configure the hierarchy in the project using MpComGroup components. An example how to configure is in the help use cases.
Alarm management for a printing press line

After you created the Hierarchy, it is best to open the MpWebXs in order to check if the Hierarchy was done correctly.
WebXs

Hi Patrick,

Thanks for the quick response!

I have tried as below:

gMpAlarmX_Core is my “framework” alarm x core which is linked to the UI & history for the HMI, and then my gMpAl_XC_EM03 is an equipment module, I was hoping in the INIT routines of the separate EM’s I could put the MpComLink so that if I install an EM into the project the alarms get linked to the framework.

The main gMpAlarmX_Core isn’t enabled until the cyclic part of the task.

Opps:

Does this mean its linked successfully?

is this normal

Yes, it was successful :smiley:

The second screenshot means, that you didn’t enable the MpAlarmXCore of the gMpAl_XC_EM03. You need to have a function block instance of MpAlarmXCore for each of the cores and call the function block in the module task.

1 Like

And just like that its now working :sweat_smile:

Got myself in a bit of a tangle there! Thanks for your help Patrick