Hi Claes,

Hope you re doing well since last tmie we exchanged.

I worked with Tbourdai on his project and I wouldn't say "everything is OK".

A. The crash in rt_xtt is one thing that I will look deeper further but it looks like we still do encounter some strange behaviour with alarms.

B. We have a test application that, if left alone just went itself to the "single fault line" issue we had since release 5.2.
Upgrading in V5.5, is far much better, ie the alarm list doesn't look to be jeopardized anymore and the number of alarms is always coherent with our first tests. I will let this test runni guntil newt monday to be sure but after one hour it's OK which is more that needed in V5.2 to make the bug appear.

But we use as home page for our H.M.I. a multiview graph that is loading an AlamView sub window and this one is still encoutering the same issue as before.

Do you think the corrections you add in V5.5 (compared to V5.2 at least which is the version I new better) could be only applicable for the real alarm list but not for derivated alarmView ? If yes would it be a huge work to reproduce the fix on it ?

Thanks in advance for your help
Snarf

Hi Snarf and Tbourdai,

There is a bugfix made in the 'set subwindow' command after the V5.5 release that has to do with the implementations of color themes. I can build a patch for this on V5.5 and we'll set if this solves the problem.

The satellite alarmlist in multiviews should be updated at the same time as the ordinary alarm list. Can you see a difference in the displayed alarms, or is it just the alarm count that differs? The new thing is that a status messages is implemented where the process stations sends all the active alarms to the outunits cyclically. The ordinary alarm list is updated with any differencies found between the message and the display, and the same differencies are also applied to the satellite alarm lists in the multiviews. But the satellite alarm lists are not compared themselves with the message, instead the actions applied on the ordinary alarmlist are also applied on the satellite alarm lists as they are supposed to be identical. But it is possible that there could be some timing problem and an improvement could be to compare each satellite alarm list with the message to ensure that is is correctly updated.

/Claes

Hi Claes,

Thanks for information. Of course we would like to test and applied your latest patch but clearly I don't think this has to do with color them only.

Indeed, previously (v5.2) when we face the "single alarm line" bug, the following items were noticed:
- Number of alarm in rt_xtt alarm banner was wrongly detected to 1
- "Show alarm" command displays a pop up with only one alarm
- All alarm satellite sub window were displaying a single alarm also
(of course in that case there were in real more that 50 alarm or whatever the number but greater than 1)

Now (v5.5)
- Number of alarm in rt_xtt alarm banner is correctly detected to the exact number of alarms -> solved
- "Show alarm" command displays a pop up with all alarm -> solved
- All alarm satellite sub window were displaying a single (or two with this release) alarm --> still erronous


Unfortunately in our integrated HMI we only make use of satellite alarm and not "show alarm" in order to ensure the closing of the window without allowing it to go background. So consequently all fixed items are not used in my case and the bug remains visible to me as before.

So definitely, It looks like alarm satellite content is not synchronized with "real" alarm list. So perhaps an additional comparison between alarm view content and message could help. At your disposal to test any improvement you may think of.

I hope this is more clear. If you need any other information, don't hesitate.

Thank you for your help
Snarf

Hi Snarf and Tbourdai,

I've found a problem with a dangling pointer when removing alarms in the satellite alarmlist. There is a new rt_xtt in pwr55_5.5.0_patch01 that you can test.

/Claes