Trouble creating alarm silence SLC 500

[ceilingwalker]

Good day all. I have been trying to create a simple alarm circuit and I have everything working for me but one. When an alarm is triggered I need it to turn on a red light and energize a horn. Add to this a horn silence PB. I don't want the alarm to go away until what triggered it has been rectified, which also means that I don't want the red light to extinguish until fault has been cleared. I would like the horn to be able to be silenced though and I can't figure out how to write the instruction for it. I have attached what I'am working on and was hoping someone might be able to give a little guidance. Thank you much.

 

[Sergei Troizky]

MUTE is the screenbutton, but you can eliminate it and reset directly the SOUND bit from the screen.
The SOUND is not necessarily the horn itself. You may add a clock bit or some more elaborated modulation between them.
I often program "descending" sound alarm, when the period of beeps increases while the duration decreases every beep.
Also, I mute the sound automatically on guards open or estop button activated.
This prevents unnecessary sound alarms and allows to mute by opening a door, without need to walk to display for only this reason.

 

[bernie_carlton]

I don't see the attachment. Try this

 

  Alarm Condition                  Red Light

-----] [----+-------------------------( )

            | Silence PB         Silence Latch

            +----] [---------+--------( )

            | Silence Latch  |

            +----] [---------+

            | Silence Latch       Alarm Horn

            +----]\[------------------( )

If you have multiple alarms then each rung will have its own 'Red Light', 'Silence Latch' and 'Alarm Horn' bits. The 'Red Light' and 'Alarm Horn' bits will then each be ORed with others to turn on the actual outputs. (If any 'Red Light' then turn on the actual red light. If any 'Alarm Horn' then turn on the actual alarm horn.)

 

[bernie_carlton]

By the way, to avoid the 'inverted wedding cake' in rung 4 then after making and filling in the first branch right click on the lower left corner of the added branch and select 'extend down'. That way you aren't limited to 8 levels and it looks a little better.

 

[ceilingwalker]

Thank you Sergei and Bernie for the help, and the info about the "upside-down wedding cake", perfect. That's the kind of stuff I love to learn. Thanks again guy's.

 

[ceilingwalker]

Alarm Condition Red Light
-----] [----+-------------------------( )
| Silence PB Silence Latch
+----] [---------+--------( )
| Silence Latch |
+----] [---------+
| Silence Latch Alarm Horn
+----]\[------------------( )


I have tried this and it isn't working. I don't know if this is an issue, however, I can't make the extension's go to rail on the far right. It looks more like:


Alarm Condition Red Light
-----] [----+-------------------------( )--------
| Silence PB Silence Latch |
+----] [---------+--------------------( )--+
| Silence Latch | |
+----] [---------+ |
| Silence Latch Alarm Horn |
+----]\[------------------------------( )--+

Is this a problem?

 

[ceilingwalker]

Bernie, I tried to get yours to work but failed. I must be doing something wrong.

Sergei, I tried yours and it worked exactly the way I need it to.

I really enjoy getting to see the different ways that different people can resolve the same problem. Thanks to you both.

 

[Adam303]

Hope this helps

 

[ceilingwalker]

Hope this helps

Thank you. One question, do I do this for each of the four alarms, making the operator press the alarm silence push button for each alarm that has triggered the horn?

 

[Adam303]

No, this is just to silence the alarm horn. Once the alarm horn is silence it will not be triggered again if another fault has occurred.

 

[Ron Beaufort]

here are some BASIC things to think about before you design an "alarm system" ...

(A) how long should a "bad" signal from the field exist before the system declares that an actual "alarm condition" exists?

... (1) some signals might need to generate an alarm INSTANTLY ... (example: a boiler pressure is too high) ...

... (2) other signals might need to wait a certain amount of time before an alarm is declared – or "nuisance alarms" will result ... (example: a tank level which fluctuates rapidly in and out of an acceptable range) ...

(B) how long should we wait once the "bad" signal from the field no longer exists before the "alarm condition" should be cleared?

... (1) it might be ok to clear some alarms very quickly ...

... (2) other signals might need to wait a certain amount of time before the alarm is cleared ...

(C) once an "alarm condition" has been generated, should that condition be able to "ride through" a power cycle? ... specifically, if we have an existing alarm condition – but the power to the system flickers off for a few seconds, do we still want that existing "alarm condition" to be maintained when the power comes back on again? ... along the same lines, should a technician (or even a "clever" operator) be allowed to cancel an existing "alarm condition" just by cycling the PLC to the Program mode and then back to Run? ...

... (1) some programmers use "seal-in" rungs to hold their "alarm conditions" ... this technique will NOT retain any existing alarms in a Go-To-Run situation ...

... (2) some "alarm conditions" should definitely be programmed using Latches and Unlatches in order to make them "retentive" in a Go-To-Run situation ...

(D) once the operator has "silenced" the alarm horn – should the horn stay off regardless of how long the "alarm condition" remains in existence? ... in many (most?) cases it's best to have the system "nag" the operator periodically as a reminder that an alarm has been silenced – but still exists ... it's easy for the operator to ignore the flashing beacon – so resounding the horn again after a suitable delay is usually a good idea ...

... (1) some critical "alarm conditions" might require a fairly short "nag" delay before resounding the horn ...

... (2) other "alarm conditions" might be ok with a very long "nag" delay before resounding the horn ...

(E) once the operator has "silenced" the alarm horn for any existing alarms, should the horn stay off even if a NEW "alarm condition" is declared? ... in most (all?) cases it's best to have the system sound the horn again as soon as any new (different) "alarm condition" pops up ...

once you've considered the ideas above, take a look at the attached sample file and see if it helps with your project ...

 

[ceilingwalker]

(D) once the operator has "silenced" the alarm horn – should the horn stay off regardless of how long the "alarm condition" remains in existence? ... in many (most?) cases it's best to have the system "nag" the operator periodically as a reminder that an alarm has been silenced – but still exists ... it's easy for the operator to ignore the flashing beacon – so resounding the horn again after a suitable delay is usually a good idea ..

You must have known what I was going to ask next, Ron. I can silence the alarm now, however, if a new alarm comes in, it will not trigger the horn again, and I need to re-arm that horn in case a new alarm enters the picture. This is where it gets really difficult for me.

 

[Ron Beaufort]

just look at the program that I attached and pay attention to the logic that controls the horn ...

I included three separate "alarm conditions" as examples ... each one has its own "debounce" timers and its own "silence" setup with a separate "nag" timer ...

this is about as simple as it gets - yet it still satisfies what most alarm systems require ... and the separate timers make it really easy to "tweak" the operation for various types of alarm conditions ... also, using individual bits to mark the status of each condition means that it's pretty simple to connect an HMI system if that's a part of the project ...

even if this isn't exactly what you need, it should be pretty easy to modify it to fit your own system ...