Alarm SrcName translation and Ack in 800xA using A&E collector from 3rd party OPC Server
I am using redundant alarm event collector connected to redundant 3rd party OPC server (WinCC). Alarm and events are correctly linked to an object in either control or functional structure using OPC Source name aspect.
My first issue is with alarm names which are too long and are always a full path to the object in the OPC server (e.g @SYSTEMMACHINE::Process::KKS). Is there a way to cut the string before actual KKS? Could it be done in 800xA using NLS or some other translation? I am not sure about SrcName. Do you think it could be done on server side?
Secondly, ACK from 800xA is somehow blocked and is not going through. I am using tunneller so there should be no issue with securty. Do I need to set up the OPC server in order to receive remote ack or is it a default function? I have already checked the settings sending ack to one or both servers simultaneously. How to troubleshoot that?
Thank you very much for your help.
Voted best answer
When Event Collector receive a new alarm or event it will first attempt to match incoming SourceName with objects existing in the system and having one or more of the following aspects:
first) Controller Name
then*) OPC Source Name
*) I'm not 100% on the exact order and which aspects, but regular name should be last matching option attempted. With no match, Event Collector will (if enabled) create an object in Lost and Found and associate the unknown alarm with this new "genderless" object.
With access to 800xA Software Development Kit, SDK you can create a custom interceptor DLL which can do translation of the received SourceName to avoid having to mess too much with the name aspects.
In any case, you can configure the awkward names in the Controller Name aspect and configure a more useful name as Object Name. The latter is default used as presentation name in trends, process graphics, faceplates and alarm and event lists.
Unsure, but possibly can Bulk Data Manager be used to populate these names for you.
About acknowledge; if operator has "Operate" permission on the object, the system will allow you to attempt acknowledge.
Alarm state must be changed by OPC AE server itself. "Emitting" an acknowledge order does not change any alarm state in 800xA.
AfwApplogViewer.exe can be used to monitor the acknowledge and what comes back;
enable the logs "Events" and "Acknowledge" on the Event Collector in Service state that interfaces with the OPC AE server in regard and click Get Messages.
This is what you normally would see taking place:
- an alarm is raised in the PLC
Events: Some SourceName (*active*, enabled, *unacknowledged*)
- new blinking alarm arrive in list
- acknowledge requested by operator
Acknowledge: Acknowledge is accepted with S_OK from OPC server
- PLC receive acknowledge and accept it by emitting an update with acknowledged state
Events: SourceName (active, enabled, *acknowledged*)
- alarm stop blinking
- alarm return to inactive (idle) in PLC
Events: SourceName (*inactive*, enabled, acknowledged)
- alarm is removed from list (but remain in event lists until storage wrap)