Emerson Exchange 365

So you are getting an audible horn, but cannot determine what condition is causing it?
In the DeltaV Node Status graphic, what do you have configured for Horn Sound for Node Status Changes?

In reply to Youssef.El-Bahtimy:

Yes getting audible horn ,No sound is configured from deltav node status on engineering station.

In reply to bhushan619:

Please reply i have also same problem.

Could this be an advisory alarm ? Where then your advisory alarm settings & configuration may be selected to not show the alarm in the alarm banner. I would start by checking your alarm priorities and what alarms are set to not show in the alarm banner.

In reply to mikesteiger:

Hello,

We apologize for the delay, I have passed this question along to several DeltaV solutions consultants and hope to have an answer for you soon. :)

Best Regards,

Rachelle McWright: Business Development Manager, Dynamic Simulation: U.S. Gulf Coast

Did you moved a module with active alarm(s) to another controller?

In reply to Bruno DB:

An alarm with a priority that is configured for auto-acknowledgement explains why an alarm that clears on its own is not in the active alarm summary. But there is something else going on I suspect, given you say that the alarm is not present in process history view. My suspicion is that this is a COMM_ALM. Workstations each independently create a COMM_ALM if they determine they’ve lost communications with a node, but the workstations do not record these “local” COMM_ALMs in the Event Chronicle.
I’m not 100% sure I understand what you mean by “…when acknowledged gets disappeared…” Are you saying that the alarm is in the alarm list initially and then disappears when it is acknowledged? Or by acknowledged do you mean silencing the horn, after which you look in the alarm list and can’t determine which alarm caused the horn? I’m going to assume that by ‘acknowledged’ you mean silencing the alarm, which does not actually acknowledge any alarms. Any new alarm entering the alarm list can trigger the horn, assuming the alarm list is set to filter the same as alarm banner, which is typically the case. Horn activation is actually tied to the alarm banner selection criteria vs to any particular alarm list’s filter settings. Alarms that initially enter the alarm list (meet the banner selection criteria) can trigger the horn, including alarms that start out in the acknowledged state, which can happen when an active alarm exits suppression or the alarm has a priority configured to auto-acknowledge new alarms. Auto-acknowledged alarms can be especially challenging if they have a fleeting behavior (are only active for a second or so) exiting the alarm list before you can find them. One can usually figure out what is going on by looking at the alarm state change events in the event history, but if it’s a COMM_ALM there will be no history to observe.