semaphore TBOX LT2-530 Series, User Manual, Page: 49 / 197

Version : 1.09 49
Alarm filter on both transitions: this option allows computing the filter of alarm condition during
both transitions: when the Tag value goes to alarm condition AND when it leaves
alarm condition.
This option will be applied to all alarm conditions.
This is particularly useful to filter interferences on inputs.
Delay alarm processing when recipient's time table not available
This feature is associated to the "Scheduling" and time table attached to the recipient.
If the time table is not active when the alarm is initiated, this feature provides 2
options:
- the alarm is auto-acknowledged (by default)
- the alarm is maintained in the alarms stack until the time table becomes active. The
"Start" timestamp is the one at the moment the alarm condition was generated.
Example: the alarm condition happens at 2:35 AM, but it is not an urgent alarm. It is
an SMS meant to inform the technician. The "recipient" is configured with a time table
starting at 8:00 AM (corresponding to the technician work shift). Therefore, the
technician will receive the message at 8:00 AM, but with a timestamp of 2:35,
informing him when the event happened
Display alarm calls in alarm table: This feature is associated to the alarm condition sent to a group
of recipients.
When this feature is active, the alarms table displays the event having initiated the alarm
and all the calls generated (see below).
Event stack displaying also alarm calls:
Working with group of recipients, it is also possible to display each call with its acknowledgment
status:
Message: message preceded by (*) means that it corresponds to a call
Start: always Ack’ed
Recipient: name of each recipient of the group
End timestamp: timestamp corresponding to the end of the call
End: acknowledgment status of the call: Not Ack; Ack'ed or Auto ack.
Display logon/logoff events in alarm table: Logon/Logoff are events logged when a user logs in on a
communication port which is protected.
These events can be removed from the list, to avoid events not being real alarms.
Check Alarm Inhibition after filter time: For each alarm condition, one can declare a filter before the
alarm will be computed. For each condition, an option "handling" allows inhibiting the
alarm according to external circumstances: flag Disala or power failure.
This option allows checking the inhibition condition after the filter has elapsed. This is
particularly useful working with “Power Failure” detection; the latter might be
detected after the sensors have been in error which will then generate an alarm. In