I try to acknowledge an alarm in the Alarm Status table, a message is displayed below the table saying that the alarm is acknowledged, but the alarm stays in the table as unacknowledged.
The log file has the message “Received acknowledgement for event that is no longer available.” Also the text in the Display Path for the alarms that cannot be acknowledged don’t match any of the text I am setting for any alarm Display Path properties. Other alarms that have the Display Path I expect can be ack’d.
I suspect these display path text values for the alarms that cannot be ack’d are left over from earlier settings, yet they are being applied to new alarms.
I’m really baffled and customer is not happy. It was happening on Ignition 7.6.4, upgraded to Ignition 7.6.7 and still the same issue. I have tried deleting the alarms file in the Ignition\data folder and no difference. Cleared the Ignition cache, no change. Deleted rows in alarm_events and alarm_event_data, no change.
I worked with support on a ticket for quite a while on this. It seemed everything that was tried didn’t work. I found the references to the old un-acknowledgeable alarms in the display paths in the Gateway internal database SQLTAGALARMPROP table. I made a Gateway backup and tried removing them, but that created other issues, so I restored the previous backup.
But long story short, I renamed the device that was referenced by the un-acknowledgeable alarms to basically create new tag references, stopped the Ignition Gateway, deleted the “.alarms_…” file in the “Inductive Automation\Ignition\data” folder (support recommendation), then restarted the Gateway. And now the old un-acknowledgeable alarms were gone and new generated alarms were all acknowledgeable. I renamed the device back to the original name and the old un-acknowledgeable alarms came back. It seems to really get rid of them they would need to be permanently cleared from the SQLTAGALARMPROP table. I asked support about a safe way to do this, but this was not recommended. So I am just going forward with the renamed device. The customer is not so happy because the new device name breaks their standard naming condition slightly, but they are accepting this solution.
In case this does not work for you, there were a few other items that I tried from support recommendations. I did not think they had any effect, so I went back to default settings, but those other items are:
On the Gateway -> Configure -> System -> Gateway Settings - disable ‘Persist Alarms’
Under Configure -> Alarming -> General - set ‘Continuous Event Detection Window (min)’ to 0 and ‘Notify Initial Events’ to False.
So I feel a little silly because I just restarted the gateway and the alarm cleared. I was trying to figure out how to remedy the situation without restarting the gateway, because I cannot simply do that while we are running in normal operation. Thankfully we are still in development and have not officially launched the new system as of yet. Anyways thank you for your assistance and good luck to you.