I have my PLC code setup to receive an alarm acknowledgement from the SCADA. Without it the alarm that is latched in the PLC will not clear.
Is there a way to bind a tag to an alarm so that the ACK will be turned on once the acknowledge has been made on the alarm banner?
No, you would have to create your own acknowledge alert button using the function:
system.alert.acknowledgeAlert(system, path, stateName)
where you would also write to the tag or do something else. You can hide the ack buttons on the alert summary table.
Thanks for the reply. I could not see any method of achieving it.
I am fine with the alarm being acknowledged on SCADA only and the PLC clearing the alarm once the condition is gone.
If you want help creating the acknowledge alert button you can always give our tech support team a call.
Is it possible to do this now that the alarm module has been totally revamped?
If I have more than one HMI running (ie. a local Panel) that would avoid to acknowledge an alarm in each system separately.
You can create an acknowledge button of your own using the system.alarm.acknowledge function
inductiveautomation.com/support/ … wledge.htm
As for your other question, I’m not sure if I am missing something here or not, when you acknowledge an alarm on one HMI you do not have to go to the other launched HMIs and clear the alarm there also. You only have to clear the alarm once on one HMI.
Hi Greg,
Let me make myself clear regarding the acknowledgement of alarms in different HMIs.
I have a PLC object (add-on) which uses a signal for acknowledgment, so if I set the Ack signal from the PLC, the alarm changes its state to acknowledged (in the PLC). If I use a faceplate that links a button to that Ack signal, and I run the script to acknowledge the alarm for Ignition, it works.
The problem is if the operator acknowledges several alarms from the Alarm Banner, then this alarms is only logically acknowledged in Ignition, but from the point of view of the PLC, the alarm has not been acknowledged.
If I have a different HMI, such as AB PanelView Plus, the acknowledgment in Ignition does not have any effect in the PanelView, unless the alarm is acknowledged from the point of view of the PLC.
What I want to do is: when an alarm is acknowledged from the Alarm Banner, I want to associate a PLC signal to every acknowledged alarm to notify the PLC that the alarm was indeed acknowledged from an external HMI.
Regards,
Everardo
You can do just that but you will have to create your own acknowledge script as Greg suggested.
In that acknowledge script you will need to take the following steps:
Thanks Robert, I understand the steps you mention.
But there is still something I am not sure how to do it: How to intercept the press of the Acknowledge button of Alarm Status Table?
If I watch for a property change, this only works when the selection of alarms change, but I can’t find an event fired when the Acknowledge button is pressed.
Version: Ignition 7.6.4
It’s been a while since this topic was addressed, and I wanted to see if the above is still the case (and if it is I would like to second the request to bind the acknowledge status to a PLC tag).
In the other HMI packages I make use of I’ve designed my faceplates (templates) to allow users to acknowledge an alarm associated with that device right from the popup. For example, if they opened a pump and it had a overload fault, they could click on the text and (provided they had the right credentials) acknowledge the alarm.
When they acknowledge the alarm from the HMI it would set an acknowledge bit in the PLC that I could then use to synchronize my Alarms across multiple HMI frontends.
If I’m reading this thread correctly, it appears that it’s not even directly accessible to acknowledge an alarm outside the alarm status window. Is that correct? 
Let me step back and give a little overview of alarming in Ignition, just to make sure we are all on the same page.
Alarms are handled internally in Ignition. When you set up and alarm on a tag you’re specifying a condition of the tag value for which you consider an alarm condition. So, instead of a two bit scenario in the case you’re describing, imagine a scenario where you have just one tag (integer, let’s say) and when that tag has a value of 10 you consider that an alarm state. You define an alarm on that integer tag that says “when i’m equal to 10 trigger a High alarm”. This alarm is managed internally by Ignition. When the alarm goes high it does not affect the actual tag, but show that there is a tag in an alarm state within the Ignition alarming system. When you acknowledge that alarm you’re again not affecting that actual tag value in any way, you’re merely acknowledging this unique alarm event that is only defined within the Ignition system.
Now with the case you described you have bits within the plc that you interpret as alarms when they are high. These are separate from any alarms you define on Ignition tags that are tied to these bits. Acknowledging an alarm defined on a tag that’s tied to one of your physical alarm bits will not modify the value of that bit in any way, it merely tells the Ignition alarming system that you are aware of the state of the bit and not to notify you about it any more. If you wanted to actually reset that bit, what you could do in new versions of Ignition is add a script to the “Alarm Acknowledged” tag event on the tag in question that writes to the bit that you want to reset.
You can acknowledge alarms outside of the alarm status table, you just have to do it through scripting. The alarm status table creates an easy way for your to monitor your alarms and easily identify which alarms you which to acknowledge all through one component. There is nothing tying you to using this component as your only means for acknowledgement.
Hopefully this information helps.
Yeah, I understand how the alarming works (It’s very similar and design and nature to the other HMI packages I’ve used). I used the example of a couple of bits because that’s the simplest example. Well that and from a design standpoint I prefer to do all my alarming in the PLC and translate it to a boolean high = alarm bit for whatever HMI package I’m using to annunciate off of.
To be fair, it’s hit and miss in other HMI packages for this sort of control as well. FactoryTalk does it, but, to my knowledge, Wonderware does not. Not sure about iFix, but I think it does.
Fortunately, I was able to make a button with the following code to acknowledge a specific alarm (Apologies if the comments don’t describe exactly what’s happening, it’s my understanding of what the system is doing)
[code]"""
This script will acknowledge every instance of a specific alarm.
For the purpose of this script, BaseTagName is assumed to be the name of the tag that has an alarm assigned to it.
For example, if the tag 01AIT00201_CL2_BAD had an alarm assigned to it, then the BaseTagName is “01AIT00201_CL2_BAD” (minus the quotes)
“”"
#Get the string value of the BaseTagName custom property
stringval = ‘’.join([event.source.parent.BaseTagName])
#Require operators to confim acknowledgment command
if system.gui.confirm(u’CONFIRM ACKNOWLEDGE COMMAND’, ‘CONFORM’):
#Search the alarm status item for any alarm event that matches the BaseTagName variable
results = system.alarm.queryStatus(path=["*"+stringval+"*"])
# initizalize the loop counter
i = 0
#Iterate trough all the matching alarm events that match the BaseTagName
for item in results:
#convert the result to a Dataset
table = results.getDataset()
#To acknowledge an alarm you much provide the UUID of the alarm. A unique UUID is create for each time the alarm goes active
#this means that 1 alarm can have any number of previous unacknowledged alarm UUIDs out there still. Each unacknowledged alarm
#will create a row in the Dataset table created on the line above. The loop counter will get the UUID for the associate row so
#that it can be acknowledged
uuid = [str(table.getValueAt(i, 'EventId'))]
#Acknowledge the alarm with the associated UUID, log the user who is currently logged in
system.alarm.acknowledge(uuid, system.security.getUsername())
#increment the loop
i += 1
#end of for loop
#end of if statment[/code]
I also realized that I can add a
system.tag.write("[Path]/Tagname_ack_bit",1)to the Alarm Acknowledged Tag Event to give me a defacto PLC handshake in the meantime 
Just bumping an old thread to clarify the required syntax if the handshake tag I want to write to is part of the same UDT as the alarm tag…
E.g. I have a UDT which has among other things:
The AlarmCondition has an alarm configured so that when the tag goes high, an alarm is generated by Ignition. When the Ignition user acknowledges that alarm, I’d like the AlarmAckHandshake tag to be set to 1.
As per the previous post, I can add a script to the Alarm Acknowledged Tag Event on AlarmCondition, but I’m not sure of the correct syntax, when trying to direct it to another member of the same UDT.
system.tag.write("{[.]AlarmAckHandshake}, 1)?
system.tag.write("[.]AlarmAckHandshake, 1)?
system.tag.write("[.]/AlarmAckHandshake, 1)?
Something else?