Alarm app Std Ack

Hi Trond. 

I am not aware of a workaround except what you described.  Maybe someone else  on here has a better interrim solution.
From our side in product management, I am aware of the challenge with the "Std Ack" comment overwriting the original alarm comment when acknowledgments are done via the context menu. We are actively looking into two enhancements to address this in some future release:

1. Additional Separate Columns for Ack Comment and Alarm Message: This will introduce two new columns in the Alarm App grid: "Ack Message" for the acknowledgment message and "Alarm Message" to display the original alarm comment. This allows for the separation of these messages while maintaining the original alarm comment visibility.

2. Alarm Acknowledgment Behavior in OMI: We're looking into making the alarm acknowledgment behavior consistent across different methods (buttons and context menus), especially regarding the preservation of the alarm description as a comment. The aim is to provide a way to maintain the alarm description when acknowledged via the context menu, similar to the button method (I believe this is possible in InTouch which uses the same control).

These enhancements are on our backlog, and while we are working towards improving this functionality, we cannot promise specific timelines for their release. If you could have only one of them, which one would it be?

Thanks for the detailed reply Ernst.

I think enhancement #2 would be much easier for you to implement without affecting the behaviour of alarms in general, and it is much more upgrade friendly. And I too think this functionality has been around in InTouch for System Platform, so you are only implementing functionality that should be there already.

Another or additional approach would be to create some kind of scripting function or API that we can use, similar to the script function to log events (LogDataChangeEvent?). This function could be used to update existing alarms, the same way analog values are updated for analog alarms. This is already included in the toolkit, but requires considerable development to expose to the objects.

The script function could also help with other use cases, such as posting the analog value and limit together with  alarms for analog measurements. We cannot use the "Limit alarm" functionality in System Platform since all our alarms are defined in the PLC. And this means we cannot publish the analog value and limit to the alarm list.

I would like to be able to sell the alarm systems greatness, but more often I find myself making excuses for it. So I hope it will receive some needed love and care in the near future.

Thanks, I will definitely take your responses into consideration!

For the limit alarms, have you tried the associated attribute function? I'd like to hear your take on it. It allows you to create a Boolean, link it to the PLC and then set it as an alarm and link an analogue attribute to it:

Thanks, I will definitely take your responses into consideration!

For the limit alarms, have you tried the associated attribute function? I'd like to hear your take on it. It allows you to create a Boolean, link it to the PLC and then set it as an alarm and link an analogue attribute to it:

Hi,

Apologies, it took some time to get back to you.

I had a look at the attribute you mentioned. It did not seem to do anything in InTouch or OMI. My understanding is that it works for the historian client, but not for real time alarming. Is that correct? I haven't had a chance to look at this for 2023-R2 though. I will have to look into that.

It would be a solution if we could connect the boolean alarm to both a analog value and a limit value separately, and if these values were actually integrated into alarm so they were sent to the alarm buffer.

No worries.  Yes, that analogue is just used in the historian, although I thing you can get the name of the analog in runtime if you have the alarm itself.  Today the limits will have to be created as separate attributes. There is an item on our backlog to allow users to consume an external alarm and treat it as part of our alarm subsytem, but it has not been prioritised yet.