MpAlarmXHistory slow in MappView

Ask Questions HMI & Visualization
,
1

Hi
we use the AlarmHistory Widget on our mappView visualization but if too many alarms are in the history loading of the content takes a lot of time.
Is there a way to limit the value of entries which are possible in the AlarmHistory before the latest one will be overwritten?
So we could reduce the amount of entries to display and the loading would be faster.

Thanks

2

Hi @Stefan_Ruttimann ,
Could you please tell us which AS and mapp View version version are you using?

too many alarms are in the history loading of the content takes a lot of time

more or less how many alarms are we talking about? 100/500…

Which hw do you have?

======
I’m learning mappView, could you check if we have a filter available for AlarmHistory widget too? maybe you can filter based on time same we have for AlarmList:

image
image1888Ă—136 80.4 KB

AlarmList and fixed filters? - Ask Questions / HMI & Visualization - B&R Community

Ciao
Valerio

3

you can try to change rendering policy from default to performance.

4

@valerio.manenti
AS 6.5.2.12
MappView 6.6.0

Number of Alarms > 1’000
Filter does not help as I don’t want to filter for any column, I want to limit the amount of the Alarms in the history

@kovarj I did that before. It helped a bit but it is still slowly therefore my next idea was to limit the history in some way

5

you can configure memory size used for alarm history

6

So the memory size defines how many alarms are stored in the history? If more alarms comes acitve the oldest ones get deleted?

And how much memory does one alarm need? Or can I check that somehow so I have an idea of how many alarms can be stored in this memory size.

7

-> size of one alarm is not fixed and it depends:

  • Alarm message length
  • Alarm snippets (code snippets attached to alarm)
  • Additional information 1 & 2 fields
  • Category data
  • Timestamp data

-> it is a ring buffer. So you have to test what works the best for you. I mean from point of view of stored history versus performance. This is really application depended.

8

My two cents to this topic:

  • We also had troubles with AlarmHistory-Performance in the past (and are still not happy).
    We decided to not increase the available memory for the AlarmHistory, but leave it at the default 512KB (results in aroud 1000 Alarms for us).
  • In the past, filtering didn’t improve performance for us.
    The widget has to load the whole Alarm-History and filters after the fact. So you only filter from an already loaded list.
  • This likely doesn’t apply to you, as you are using AS6:
    There is an option “Auto detect” unter the Alarm Text Snippets category in the/every AlarmXCore (AS4 / mappServcies 5.x - can be found in the AlarmXList-Files in AS6).
    By setting it to Enabled you are storing only the necessary snippets for an alarm, thus reducing the memory a single alarm
  • The performance of the client makes adifference.
    How does your client compare to opening the history with e.g. your laptop?



A few insights on how the AlarmHistory-Module stores the alarms:

  • The complete history is saved in the datamodule/-object AlarmX$0
  • The module is organized in blocks of 256Bytes. Every alarm takes up as many slots as it needs to store all information (Timsetamp, AlarmID, Message, Additional Info, Snippets etc.)
  • If a single alarm takes up e.g. 300Bytes it uses two whole slots. The next alarm can only start at the beginning of the next slot.
  • AutoDetect does the following:
    If it is Disabled, every alarm contains all(!) snippets defined in the alarmCore/List. So if you define for example 20 alarms and 20 snippets (1 for each alarm), every entry of a single alarm also contains all 20 snippets.
    With AutoDetect enabled, only the snippets for this alarm are saved.

This research is based on mappServices 5.24., so I am not quite sure what exactly changed for mappServices 6.x. I assume it works very simmilar.

I explain that in detail, to give a better understanding on how thje configured memory is used so you can better decide, what you need.
For comparison here is a raw-dump of a single alarm in the history (left: auto detect off, right: auto detect on)

raw dump
raw dump1851Ă—694 195 KB

size comparison
size comparison1878Ă—244 19.8 KB



To conclude:

  • Depending on where the biggest bottleneck is:
    Maybe it is worth trying to look in the Cycle Idle Time. In the past we were able to increase performance a little bit by adjusting it.
  • Maybe it is worth trying to reduce the available memory, if you are fine with a shorter history.
  • Maybe you can shorten text-references to increase the number of stored alarms and then reduce the amount of memory for the module.
  • @B&R​:wink:: Hopefully the system gets a performance-boost in the future
A few Help-Links
9

Hi @PatrickS,

this is quite more then just 2 cent - thanks a lot for sharing your insights and experience with our Community! :clap:

BG Alex

10

This would deserve special article in Share Info & ideas category. Thanks @PatrickS for sharing..

11

@PatrickS Thanks for sharing…

AutoDetect is already enabled - our solution was to reduce the the memory