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?
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 
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 
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 
@istech can select way he prefers
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?