System 800xA 6.0.3.3 alarms stays in banner after acknowledge
Hello,
We have an issue, when an alarm is no longer active it stays in the alarm banner, even though the alarm is no longer present. When reviewing the aspect itself, the alarm is not present anymore.
I saw a similar issue in System 800xA version 5.1 that was resolved with a patch, but in this version, the problem persists.
Please your advice.
We have an issue, when an alarm is no longer active it stays in the alarm banner, even though the alarm is no longer present. When reviewing the aspect itself, the alarm is not present anymore.
I saw a similar issue in System 800xA version 5.1 that was resolved with a patch, but in this version, the problem persists.
Please your advice.
Asked 3 months ago
Answers
0
When an alarm enters INACTIVE and ACKNOWLEDGED it vanishes from alarm lists (but can be viewed some additional time in event lists).
The image seem to indicate ACTIVE and ACKNOWLEDGED alarms.
The state can be viewed from right click > Event Details...
The OPC AE server and PLC behind should be investigated as they govern the alarm's state (the System 800xA HMI can merely present it and ask to acknowledge).
Please bring more detail.
0
Hi,
Your alarm list really shows that the alarms are still active (and acknowledged). I can agree to check the status of the alarm in the controller (or where it is generated)
In addition, check the configuration of your alarm list, where it is described which alarms to show or not.
Your alarm list really shows that the alarms are still active (and acknowledged). I can agree to check the status of the alarm in the controller (or where it is generated)
In addition, check the configuration of your alarm list, where it is described which alarms to show or not.
0
Hi, about the alarm state, in some cases the alarm is no longer present in the related aspect (in the alarm aspect as in the related object), but in the alarm banner still appears (sometimes appears as unacklowledged and is not possible to acknowledge it from the banner, other ties the alarm is already acknowledged and is no longer active but is still present in the banner, despite the fact that in the related alarm aspect is no longer present).
The first image is the alarm aspect, the following ones are the information related to that aspect that is shown in the banner and the are some differences, despite the fact that is the same referenced aspect.
In the last image you can see that the is no longer the alarm, but is still in the banner, unacknowledged and cannot be acknowledged.
The first image is the alarm aspect, the following ones are the information related to that aspect that is shown in the banner and the are some differences, despite the fact that is the same referenced aspect.
In the last image you can see that the is no longer the alarm, but is still in the banner, unacknowledged and cannot be acknowledged.
Answered 3 months ago
2
As I have written many times on this forum, in terms of Alarm & Event the System 800xA HMI is merely a backseat passenger of the connected OPC AE servers.
The below closeup of the Event Details (from the movie you posted) shows an alarm of category Process Condition Event having the slightly funny condition name of "CondName" was sent to the HMI on the very early morning of the 25th from an AC 800M OPC server. The alarm was most likely raised by a AlarmCond module inside a program, control module, function block, etc. The funny condition name may indicate the alarm is in active "development", since name is often chosen to reflect a situation such as "high", "low", "warm", "cold", etc.
The AC 800M OPC server seem to have "forgotten" about this alarm since it does not accept your attempts to acknowledge it. A flood may have caused the OPC server to forget it, etc.
1. Make sure "Supports Refresh" option is enabled on the Alarm Collection Definition of the AC 800M OPC Server (set in the Library Structure, below Alarm Collection Definitions)
2. Examine the AC 800M application with respect to this alarm. When online in Control Builder M, browse to this AlarmCond block. The alarm emitting block may be hidden inside an instance of an object type offering no transparency - however, the location of the alarm owning object 210FQIC10412_ALM1 should give a good hint where you should concentrate your efforts. When at the suspect object, right click and select Alarm Conditions. This command will show all alarms (also including inside protected & locked object types) known by the Control Builder M for the given object. The CondState is key. 0 = disabled or error in configuration. 1 = disabled. 2 = idle. 3, 4 or 5 are different states of alarm. 6 is auto disabled after too many alarm firings without receiving acknowledge.
If the alarm emitter has been removed (nothing found with the right click Alarm Conditions), a subsequent download should have resulted in an OPC AE alarm refresh and the removal of the obsoleted alarm from the HMI.
However:
a) download may still be pending (which should have been indicated when trying to go online with the application)
b) refresh may be disabled (which is not recommended)
c) the OPC AE server has suffered alarm overflow and lost the alarm
d) something else have gone wrong
3) Use a 3rd party OPC AE client and connect directly to the AC 800M OPC AE server and search for 210FQIC10412_ALM1. It might become necessary to revisit the alarm list's Event Details once more and scroll down to the SourceName attribute and use it to search the AC 800M OPC Server. The object name in the System 800xA HMI can be different, e.g. following a Name Upload.
4. Use right click > Delete to delete the alarm. NOTE: THIS WILL NOT WORK WELL, e.g. only have a temporary effect if the alarm is still in the AC 800M OPC Server (see previous item) since a refresh will bring it back at next warm download or failover. Never delete an alarm that still exist in the PLC / AC 800M OPC Server.
5. Check Diagram3 / Program3 by default running in the Slow task. It has a SystemDiagnostics object with Alarm & Event debugging information. It will tell if there is a problem with the AC 800M OPC server's MMS alarm subscription in the controller. IIRC, Subscription state should be "1" and all buffer values be "0" and the time for overflow should be 1979-01-01 (or something very long time ago).
If you find a lot of obsolete alarms in the AC 800M OPC server, you might need to give it a restart. If the incorrect alarms remain in the controller, a newly restarted AC 800M OPC server may still convey them to the System 800xA HMI. In severe cases you might need to restart the controller.
With the above data known and the problem causing problems for you, it is time for you to file a support case with your regional ABB Support Center to obtain professional assistance.
The below closeup of the Event Details (from the movie you posted) shows an alarm of category Process Condition Event having the slightly funny condition name of "CondName" was sent to the HMI on the very early morning of the 25th from an AC 800M OPC server. The alarm was most likely raised by a AlarmCond module inside a program, control module, function block, etc. The funny condition name may indicate the alarm is in active "development", since name is often chosen to reflect a situation such as "high", "low", "warm", "cold", etc.
The AC 800M OPC server seem to have "forgotten" about this alarm since it does not accept your attempts to acknowledge it. A flood may have caused the OPC server to forget it, etc.
1. Make sure "Supports Refresh" option is enabled on the Alarm Collection Definition of the AC 800M OPC Server (set in the Library Structure, below Alarm Collection Definitions)
2. Examine the AC 800M application with respect to this alarm. When online in Control Builder M, browse to this AlarmCond block. The alarm emitting block may be hidden inside an instance of an object type offering no transparency - however, the location of the alarm owning object 210FQIC10412_ALM1 should give a good hint where you should concentrate your efforts. When at the suspect object, right click and select Alarm Conditions. This command will show all alarms (also including inside protected & locked object types) known by the Control Builder M for the given object. The CondState is key. 0 = disabled or error in configuration. 1 = disabled. 2 = idle. 3, 4 or 5 are different states of alarm. 6 is auto disabled after too many alarm firings without receiving acknowledge.
If the alarm emitter has been removed (nothing found with the right click Alarm Conditions), a subsequent download should have resulted in an OPC AE alarm refresh and the removal of the obsoleted alarm from the HMI.
However:
a) download may still be pending (which should have been indicated when trying to go online with the application)
b) refresh may be disabled (which is not recommended)
c) the OPC AE server has suffered alarm overflow and lost the alarm
d) something else have gone wrong
3) Use a 3rd party OPC AE client and connect directly to the AC 800M OPC AE server and search for 210FQIC10412_ALM1. It might become necessary to revisit the alarm list's Event Details once more and scroll down to the SourceName attribute and use it to search the AC 800M OPC Server. The object name in the System 800xA HMI can be different, e.g. following a Name Upload.
4. Use right click > Delete to delete the alarm. NOTE: THIS WILL NOT WORK WELL, e.g. only have a temporary effect if the alarm is still in the AC 800M OPC Server (see previous item) since a refresh will bring it back at next warm download or failover. Never delete an alarm that still exist in the PLC / AC 800M OPC Server.
5. Check Diagram3 / Program3 by default running in the Slow task. It has a SystemDiagnostics object with Alarm & Event debugging information. It will tell if there is a problem with the AC 800M OPC server's MMS alarm subscription in the controller. IIRC, Subscription state should be "1" and all buffer values be "0" and the time for overflow should be 1979-01-01 (or something very long time ago).
If you find a lot of obsolete alarms in the AC 800M OPC server, you might need to give it a restart. If the incorrect alarms remain in the controller, a newly restarted AC 800M OPC server may still convey them to the System 800xA HMI. In severe cases you might need to restart the controller.
With the above data known and the problem causing problems for you, it is time for you to file a support case with your regional ABB Support Center to obtain professional assistance.
Add new comment