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 ...