Dear All,

I will be very grateful if anyone can spare me a minute of your time to clarify a few things bothering my mind.

L30ALM is a signal driven by another signal, "alarm.horn" which becomes true (logic 1) whenever there is an an active alarm.

I have noticed that the alarm.horn signal remains true even when all alarms are cleared from the alarm screen.

The signal only goes to false and stays false when I toggle it in toolboxST until a new alarm appears then it goes to true again and stays true even if there are no more active alarms.

Can somebody please explain to me :

1. Where the alarm.horn signal is generated from.

2. How can the "alarm.horn" signal state be toggled to false automatically when all alarms have been cleared.

Very Best regards.

 

Kwaku,

I note this is the second time you've posted a similar query. I also note that you seem to have been editing CIMPLICITY displays, and possibly making changes to the EGD....

As with all things HMI-related, GE is constantly "evolving" their product (without documentation). So, unless one can see and "touch" the versions you are working on it can be difficult to say how they've implemented (or NOT implemented) features which one wouldn't think would not change very much but which can change with no notice and seemingly no reason. But I'll give this a go; no promises.

Have you tried Silencing the alarm(s)? Unfortunately, GE ships FAR TOO MANY HMIs with Alarm Silence buttons/targets that don't work!!! Why? Because the HMI engineers don't enable the audible alarm function, and they don't believe alarms are really important or meaningful. Why? Because most HMI engineers have NO operating or commissioning experience <b>AND</b> GE has <b>NO</b> standard and <b>NO</b> quality control to ensure that the Alarm Silence, Alarm Lock and Alarm Unlock functions work before shipment. I've even seen tens of HMIs that have non-functioning Alarm Acknowledgement buttons/targets....

Anyway, in the past alarm.horn was written to (set to logic "1") by the turbine control operating system when any alarm condition was being annunciated, and would go to logic "0" when the Alarm Silence button/target was clicked on.

However, in the past when I've encountered logic signals that would remain a "1" or "0" when forced and the force was removed that usually indicated that nothing was writing to the logic signal.... So nothing would "make" it revert to "0" or "1" when the force was removed.

But, as I write I think you are not using the Alarm Silence button/target to tell the OS that the audible alarm horn (enabled or not) has gotten the attention of a conscious and conscientious operator and can be disabled while the alarm condition is being troubleshot and resolved. So, when you force alarm.horn to "1" (and, frankly I'm surprised it can be forced!) it stays "1" until EITHER Alarm Silence is toggled (again--presuming it works, and there's no historical evidence to prove it does on many installed HMIs because commissioning personnel don't understand Alarm Management and don't want to be bothered dealing with alarms, particularly if they cause an audible alarm to sound, AND because most power plant operators quickly learn to "disable" any audible alarm horn so as not to disturb their "work" (read: relaxation)) or you force it to "0" in which case I think it might not go to zero is there are alarms which have not been silenced but have been cleared from the display!

So, please write back to let us know if you (and the operators) have been using Alarm Silence. And if there is even an audible alarm "horn" on the HMIs as installed. I think you are trying to install one if I recall correctly, and you're going to need a means of silencing it anyway.... Alarm Silence will likely be that method if you're using L30ALM driven by alarm.horn.

Again, please write back to let us know how you fare.

And how long before the control room operators disable the alarm horn--or demand it be disabled....

 

Hii CSA,
Thanks a lot for taking time off your busy schedule to reply my post.

1. First of all, my site uses cimplicity HMI version 6.1. but HMI does not have alarm horn facility.

2. The alarm silence button does not work at all but the acknowledge button works. However the acknowledge/Silence button does not toggle the Alarm. signal signal to false.

Since the HMI does not have an alarm horn horn,we have installed a separate alarm horn and programmed it to activate when L30ALM becomes true. I created an alarm silence button on the start-up screen to silence the alarm which is working perfectly.

However because the Alarm.horn signal does not toggle to false when all alarms are acknowledged, the horn sounds again seconds after silencing it.

I can toggle the Alarm.horn signal to "false" in ToolboxST and it stays false until another alarm appears then it toggles back to true and stays true even when all alarms are cleared.

I know the Alarm.horn signal is generated by Firmware and i would like to know whether there is a way to write to this signal in Firmware.

On the funny side, the operators requested for three different tones, one sound for generator breaker trip, one for turbine trip and the last for general alarm.

I have coded all that for them which is working perfectly except the general alarm which is activated by the L30ALM which sounds again a few seconds after silencing it because of how the Alarm.horn signal is behaving. They (The Operators) are now asking me to deactivate the general alarm sound since it is almost always sounding. You rightly predicted.

 

You should be writing true to Alarm.HornSilence instead of modifying Alarm.Horn directly; Alarm.Horn is an output variable from the alarm scanner in the Mark VIe firmware, so any value written to it is going to be overwritten almost immediately. See chapter 2 of GEH-6721 Volume I, it has a list of controller intrinsic variables and (brief) descriptions of what they do.

Must be an old version of ToolboxST if it lets you change the value of alarm.horn at all; later versions don't allow changes or forcing of controller intrinsic variables.

 

After I posted that I went back and checked, and it turns out that the controller intrinsic list was added to GEH-6721 fairly recently, and if you are running Cimplicity 6.1 you probably are not recent. If you have a GE Controls Connect account you can download the latest version from there.

 

Thank you, Demigrog. But I don't think Kwaku understands that to silence (stop) an audible alarm indication it's necessary to use ALARM SILENCE. And, unfortunately, it seems GE has shipped an HMI with a non-working ALARM SILENCE button/target.

Acknowledging alarms doesn't silence (stop) the audible alarm indication.

Even resetting or clearing an acknowledged alarm doesn't silence (stop) the audible alarm indication.

SILENCING the audible alarm indication silences (stops) the audible alarm indication.

Kwaku's succeeded in creating a button/target to silence the alarm horn he's created! The friggin' operators don't want to have to click on two buttons, ALARM SILENCE <b>and</b> ACKNOWLEDGE, so it seems he's created some kind of SILENCE/ACKNOWLEDGE button/target which isn't working. Some operator(s), believe that ACKNOWLEDGING alarms should also silence (stop) the alarm horn....

And, I predict: No matter what he does, the operators will <b>NEVER</b> be satisfied. And ALL audible alarms will be muted/silenced before the end of the year.

Most likely by cutting the wires, or plugging/blocking the noise-maker. Operators can be very creative when they want to be uninterrupted. I've seen operators sit at a table reading newspapers and ignore two alarm horns for more than thirty minutes (they were on a fifteen minuted break--all seven of them) and wouldn't even get up to silence the alarm horns, much less check to see what alarms were being annunciated. They knew the turbines were still running and hadn't tripped, so they weren't going to get up from their newspapers and coffee until their fifteen minute break (which took thirty minutes--at least) was over. When I got up to check the alarms, I was told to sit down or go outside and wait.

I've even seen operators wrap prayer rugs around their heads at night to reduce the chance of being awakened by audible alarms when they couldn't determine how to permanently disable/stop the alarm horn from sounding. They slept for hours with a continuously sounding alarm, sometimes while the turbine was tripped.

And, it was the Mark V's fault when the plant manager came to work in the morning. Not once, or twice, or even three times--but multiple times!!!!!

Never underestimate the ability of an operator to blame anything and everything on the turbine control system.

NEVER.

Full Stop.

Period.

End of discussion.

Even arriving late to work has been blamed on the turbine control system. (True story--and the plant manager almost believed it. The operator certainly believed it.)

 

Thanks a lot Demigrog for the enlightenment.

I have searched through the signals but could not find the Alarm.HornSilence signal in toolboxST.

Can you please elaborate a little on how to locate the Alarm.HornSilence Signal?

On the issue of the GEH 6721, all the versions i have does not have the controller intrinsic signal list. I have however registered at controls connect and am yet to be given access.

 

Thanks a lot CSA,
I am amazed how deep you know operators because everything you are saying is very true.

I am however not deterred by their behavior because i am motivated by digging deep to find answers and solutions for what i don't know for my own good.

 

The global variable name is simply Alarm.HornSilence, so it shows up in the variable browser in the Alarm folder. If you were searching for it using Find, you probably won't find it unless something in your application code is using it, and HornSilence is more commonly written from the HMI than application code. The Finder doesn't seem to find controller intrinsics.

 

I think the main problem is that the alarm horn was designed for a much simpler era, where there were only 50 alarms and when one went off the required action was both urgent and a little more clear to operators. These days there are so many alarms that they have to be categorized into priorities, and many plants run with active low priority alarms all the time. In these designs, it would make sense to me to only trigger the horn on priority one alarms, and rely on the sound effects that can be assigned to alarm classes for lower priority alarms. However, many engineers are too conservative to allow that--nobody wants to be the person that disabled the horn for a seemingly low priority alarm only to have it lead to a trip or unsafe condition later.

There are few things in control system design that can trigger bigger and nastier arguments than alarms and alarm management strategies, so I generally try to stay out of it. Probably should have this time as well.

As to non-working silence buttons on the HMI, I'm curious how the button is configured when it isn't working. It should just be writing True to devicename.Alarm.HornSilence. For that matter, you don't have to configure a button from the WorkstationST alarm viewer, it is built into the UI and directly communicates with the alarm server.

 

Demigrog,

There were some early Mark VIe's with early versions of WorkstationST that used CIMPLICITY 6.1 and some of them used the CIMPLICITY Alarm Viewer and some the WorkstationST Alarm Viewer. Kwaku hasn't really told us exactly what his configuration is....

So, we can't really be of much more help. He's obviously trying to make a good impression. Unless and until Kwaku tells us more about the exact configuration he's working with, and exactly what the operators are demanding (which it sounds like they want to be able to silence the audible alarm horn someone has foisted on them from ANY display/screen without clicking to the WorkstationST Alarm Viewer AND they want to acknowledge alarms with the same click) I don't think we can be of much more help.

I would imagine that a script could be written to do such a thing, but I have no idea how to do that.?.?.?