EST EST2 v5.0 System Programming Manual

EST2
System Programming Manual
P/N 270187 • Rev 5.0 • 18AUG00
Technical Manuals Online! - http://www.tech-man.com

DEVELOPED BY Edwards Systems Technology
6411 Parkland Drive
Sarasota, FL 34243
(941) 739-4300
COPYRIGHT NOTICE Copyright © 2000 Edwards Systems Technology, Inc.
This manual is copyrighted by Edwards Systems Technology,
Inc. (EST). You may not reproduce, translate, transcribe, or
transmit any part of this manual without express, written
permission from EST.
This manual contains proprietary information intended for
distribution to authorized persons or companies for the sole
purpose of conducting business with EST. If you distribute any
information contained in this manual to unauthorized persons,
you have violated all distributor agreements and may be subject
to legal action.
TRADEMARKS IBM is a registered trademark of International Business
Machines Corporation.
Microsoft and MS-DOS are registered trademarks, and Microsoft
Mouse and Windows are trademarks of Microsoft Corporation.
CREDITS This manual was designed and written by the EST Technical
Services - Documentation Department, Sarasota.
DOCUMENT HISTORY
Date Revision Reason for change
03AUG98 4.5 Revised content to reflect programming using the Systems
Definition Utility.
Revisions 4.4 and earlier are obsolete.
August 2000 5.0 Updated manual to coincide with release of software version 1.3.
Added chapters on input events and output commands. Also
added a quick programming reference and a glossary. Corrected
minor technical errors and added procedures for the
programming of logic groups.
Revision 4.5 and earlier revisions are obsolete.

Content
Content
Important information • iii

Getting the most out of this manual • iv
About the Systems Definition Utility • vi
Chapter 1 Overview • 1.1

Introduction • 1.2
Programming using rules and objects • 1.3
Creating a rules file • 1.8
Compiling the rules file • 1.11
Developing a labeling plan • 1.12
Identifying object group relationships • 1.18
Chapter 2 Advanced programming features • 2.1

Variables • 2.2
Priorities • 2.5
Logic groups • 2.7
Actions and Sequences • 2.9
Chapter 3 Input events • 3.1

Active events • 3.2
Alarm events • 3.4
CallIn events • 3.5
Confirmation events • 3.6
Define events • 3.7
Monitor events • 3.9
Supervisory events • 3.10
TestActive events • 3.11
TestTrouble event • 3.13
Trouble events • 3.15
Chapter 4 Output commands • 4.1

Activate command • 4.2
Cancel command • 4.3
Close command • 4.4
CommonAlarmOff command • 4.5
CommonAlarmOn command • 4.6
CommonMonitorOff command • 4.7
CommonMonitorOn command • 4.8
CommonSupervisoryOff command • 4.9
CommonSupervisoryOn command • 4.10
CommonTroubleOff command • 4.11
CommonTroubleOn command • 4.12
Delay command • 4.13
Disable command • 4.14
Enable command • 4.16
FanOff command • 4.18
FanOn command • 4.19
EST2 System Programming Manual i

Content
HoldDoor command • 4.20

LEDOff command • 4.21
LEDOn command • 4.22
NSClose command • 4.23
NSCommonAlarmOff command • 4.24
NSCommonAlarmOn command • 4.25
NSCommonMonitorOff command • 4.26
NSCommonMonitorOn command • 4.27
NSCommonSupervisoryOff command • 4.28
NSCommonSupervisoryOn command • 4.29
NSCommonTroubleOff command • 4.30
NSCommonTroubleOn command • 4.31
NSFanOff command • 4.32
NSFanOn command • 4.33
NSHoldDoor command • 4.34
NSOpen command • 4.35
NSReleaseDoor command • 4.36
Off command • 4.37
OffGuard command • 4.39
On command • 4.40
OnGuard command • 4.42
Open command • 4.43
ReleaseDoor command • 4.44
Restore command • 4.45
Appendix A Quick reference • A.1

Event specification summaries • A.2
Events listed by device • A.6
Command specification summaries • A.10
Commands listed by device • A.17
Glossary • Y.1
Index • Z.1
ii EST2 System Programming Manual

Content
Important information
Limitation of liability
The content of this manual is proprietary in nature and is
intended solely for distribution to authorized persons,
companies, distributors and/or others for the sole purpose of
conducting business associated with Edwards Systems
Technology, Inc. The distribution of information contained
within this manual to unauthorized persons shall constitute a
violation of any distributor agreements and may result in
implementation of legal proceedings.
This product has been designed to meet the requirements of
NFPA Standard 72, 1999 Edition; Underwriters Laboratories,
Inc., Standard 864, 7th Edition; and Underwriters Laboratories
of Canada, Inc., Standard ULC S527. Installation in accordance
with this manual, applicable codes, and the instructions of the
Authority Having Jurisdiction is mandatory. EST, Inc. shall not
under any circumstances be liable for any incidental or
consequential damages arising from loss of property or other
damages or losses owing to the failure of EST, Inc. products
beyond the cost of repair or replacement of any defective
products. EST, Inc. reserves the right to make product
improvements and change product specifications at any time.
While every precaution has been taken during the preparation of
this manual to ensure the accuracy of its contents, EST assumes
no responsibility for errors or omissions.
FCC warning
This equipment can generate and radiate radio frequency energy.
If this equipment is not installed in accordance with this manual,
it may cause interference to radio communications. This
equipment has been tested and found to comply within the limits
for Class A computing devices pursuant to Subpart B of Part 15
of the FCC Rules. These rules are designed to provide
reasonable protection against such interference when this
equipment is operated in a commercial environment. Operation
of this equipment is likely to cause interference, in which case
the user at his own expense, is required to take whatever
measures may be required to correct the interference.
EST2 System Programming Manual iii

Content
Getting the most out of this manual

Knowing where to find help
The EST2 System Programming Manual is designed to act as a
supplement to the online help for the Systems Definition Utility
(SDU). It provides a quick reference to the programming of rules
in a paper-based medium. The scope of this manual includes
instructions for:
• Developing an effective label plan
• Using advanced programming features
• Writing input events
• Writing output commands
The programming manual also provides a quick reference to
assist you when you need to find out what to write for a job
specification. If you want to find out what a programming object
or term is, you can turn to the glossary for help.
The chapters that follow supply numerous instructions for
creating rules. The online help in the SDU offers even more
assistance. For example, the manual provides information about
AND groups and explains how to write rules for them. The SDU
help provides similar instructions, but it also explains how to
create AND groups. The programming manual provides
instructions for developing labeling plan. The SDU help
provides instructions for labeling objects in the Object
Configuration. The best practice is to use the programming
manual and the SDU help together.
Before you begin the programming process, read the Overview.
This will help you develop an effective programming scheme.
As you program your system, reference the sections you need. At
the same time, use the SDU help to find out how to configure
panels and objects.
Finding EST2 documentation

A library of related documents supports the EST2 product line.
Here is a complete list of the EST2 library:
• EST2 Installation and Service Manual (P/N 270186)
• EST2 Network Site Manual (P/N 270895)
• EST2 Network Supplement Manual (P/N 270894)
• EST2 System Operations Manual (P/N 270188)
• EST2 System Programming Manual (P/N 270187)
• EST2 Installation Sheets (P/N 3100060)
• 2-SDU Help (P/N180902)
Our technical writers constantly update the information in this
manual. Your comments during our training classes, technical
iv EST2 System Programming Manual

Content
support phone calls, and field trips are used to improve this
document.
Finding related documentation

The Signature Series Intelligent Smoke and Heat Detectors
Applications Bulletin (P/N 270145) provides instructions and
illustrations for smoke and heat detectors.
The Signature Series Component Installation Manual (P/N
270497) supports the installation of the Signature Series
detectors and modules.
The Serial Number Log Book (P/N 270267) provides a
convenient means for recording the serial number of each
Signature device connected to the fire alarm system.
The SAN Annunciator Installation Guide (P/N 250084) supports
the SAN annunciators mentioned in this manual.
The EST Speaker Application Guide (P/N 85000-0033) provides
information about the placement and layout of speakers for fire
alarm signaling and emergency voice communications.
The EST Strobe Applications Guide (P/N 85000-0049) provides
information for the placement and layout of strobes for fire alarm
signaling.
The Microline 182 Turbo Printer Handbook, by Okidata
provides all the necessary information for the maintenance and
configuration of the PT-1S Form Printer. The Okidata handbook
comes with the Form Printer.
EST2 System Programming Manual v

Content
About the Systems Definition Utility

The Systems Definition Utility (SDU) is a database application
used for setting up and programming the fire alarm system.
Using the SDU you can:
• Build setup files using forms to specify system the hardware
configuration and operating options for a given project
• Create extensive system controls using advanced rules-based
programming.
Minimum equipment requirements

Before installing the Systems Definition Utility, you should
make sure your computer system meets the following minimum
equipment requirements:
• IBM-compatible computer
• One or more serial communications (COM) ports for
connecting a bar code reader or a download cable
• One parallel printer port (LPT)
• Hard disk drive with at least 40 megabytes or more free disk
space
• 32 MB of Random Access Memory (RAM)
• One 3.5-inch floppy drive
• One 2X or faster CD-ROM drive
• SVGA color display, 640 x 480
• Microsoft Mouse or other compatible pointing device
• Windows 3.1x or later
Note: The amount of free disk space required varies with the
number of projects and the amount of audio messages you plan
to save on the hard drive. A general rule of thumb is to have at
least twice the amount of hard disk space required by your
largest project.
The Systems Definition Utility executes highly disk-intensive
functions. For best results, make sure your computer system is
configured to achieve optimal performance. To optimize your
system, refer to the documentation that came with your
equipment.
vi EST2 System Programming Manual

Content
Optional equipment
In addition to the basic system described above, you will also
need the following optional equipment to make use of some of
the advanced features available in the SDU:
• Bar code reader for configuring Signature data circuits
• 300-dpi laser printer or equivalent for printing reports
The following bar code readers are recommended:
Manufacturer Model
Zebra Technologies SCAN•ONE
VTI, Inc.
Zebra Technologies Barcode Anything SCAN 97
VTI, Inc.
Install the bar code reader per the manufacturer's instructions and
configure the reader to interpret Interleaved 2 of 5 bar codes.
EST2 System Programming Manual vii

Content
viii EST2 System Programming Manual

Chapter 1
Overview
Summary
Programmers should have a good idea of how the rules work in
the Systems Definition Utility before they begin their work. In
addition, every project should have a plan for logical and
consistent labeling schemes. Finally, an effective plan includes
an awareness of object group relationships within the database
and the system specifications.
Content
Introduction • 1.2
Programming using rules and objects • 1.3
Rules • 1.3
Events • 1.6
Device types • 1.6
Objects • 1.6
Labels • 1.6
Creating a rules file • 1.8
Exceeding rules editor memory limits • 1.8
Order is important • 1.8
Avoid careless use of wildcards • 1.10
Compiling the rules file • 1.11
Developing a labeling plan • 1.12
Why use labels • 1.12
Formatting labels • 1.13
Making descriptive labels • 1.14
Using common label modifiers • 1.15
Using numbers in labels • 1.15
Using labels as messages • 1.17
Identifying object group relationships • 1.18
Linking inputs to outputs • 1.18
Sample matrix • 1.18
EST2 System Programming Manual 1.1

Overview
Introduction
All process control systems may be divided into three
fundamental parts: inputs, controls, and outputs. Examples of
fire alarm system inputs are smoke detectors, pull stations, and
waterflow switches. Typical fire alarm system outputs include
bells, strobes, control relays, and emergency audio amplifiers.
System programming is accomplished by creating a series of
rules that specify what action or actions to execute when a
specific event occurs. Before you write any rules, take the time
to:
• Understand objects, device types, labels, and rules
• Develop a labeling plan
• Identify the objects in the system
• Determine the relationships between the inputs and outputs
1.2 EST2 System Programming Manual

Overview
Programming using rules and objects

System programming is accomplished using a set of rules that
determine the output responses for given input events. The rules
are written, compiled, and then downloaded into the panel.
When an input event occurs (a device goes active), the panel
connected to the device searches for the device/event type
combination in its response tables and, if found, executes the
appropriate output commands.
The most basic fire alarm systems can be programmed using one
simple rule: “when smoke detector A activates, sound horn B.”
As fire alarm systems become more extensive, they require a
more sophisticated set of rules to program them properly. Before
you begin writing a rule, you should have a thorough
understanding of:
• Rules
• Events
• Device types
• Objects
• Labels
Rules
A rule is a programming statement that specifies which
commands to execute when a certain event takes place. Every
rule consists of a label, an input statement, and an output
statement (or statements).
The basic syntax for a rule is:
[Rule_label]
Input_statement:
Output_statement_1, {comments}
Output_statement_2, {comments}
Output_statement_3; {comments}
The rule label can be up to 40 characters in length and enclosed
in brackets. The rule label can be any ASCII character except:
braces “{ }”, the percent symbol “%”, the number symbol “#”,
less than and greater than symbols “< >”, and asterisks “*”.
The input statement ends with a colon and the output statement
ends with a semicolon. When more than one output statement is
used in a rule, each output statement must end with a comma,
except for the last output statement, which must end with a
semicolon. A rule may contain up to 32 output statements.
When a rule has multiple output statements, each output
command will be executed in the order it is listed in the rule
(from first to last). When the event activating the rule restores,

Overview
the operations performed by the rule will automatically restore

in the reverse order (from last to first).
Writing comments about rules

You can use {braces} to make comments about your rules or to
isolate them for troubleshooting measures. Rules or characters
enclosed by braces become invisible to the rules editor. Though
comments are optional, it is advisable to include them for future
reference. Place the comments wherever they show a clear
relationship to the rule without cluttering it.
Input statements
An input statement is the part of a rule that determines what
must happen before the corresponding output statements will be
executed. There are two different syntaxes used in rule input
statements depending on the input event type selected. The two
input statement syntaxes are:
event_type :
event_type device_type 'object_label' :
where:
event_type Specifies the type of input event required for the

rule to execute. When a system input activates, the
resulting change in state creates an event. See
Input events for detailed descriptions of event
types and their usage.
device_type Specifies the device type of the input device
initiating the event. The device_type parameter is
optional when using the 'object_label' parameter.
When the device_type parameter is not included,
all devices whose label matches 'object_label' will
respond to the command.
'object_label' Specifies the label of the input device or circuit
that must go active for the rule to execute. The
'object_label' parameter is optional when using the
device_type parameter. When the 'object_label'
parameter is not included, all devices with the
specified device type will trigger the rule.
Note: When the device_type and 'object_label' parameters are

optional you must specify one or the other or both.
An input statement must be valid for the rule to be successfully
compiled. This means that the device type of the object
identified by 'object_label' must match that specified by
device_type. Also, the input event specified by event_type must
be applicable for the device_type.

Overview
Output statements
An output statement is the part of a rule that determines the
commands that will be executed in response to a given input and
in what order. There are nine different syntaxes used in rule
output statements depending on the output command selected.
The nine output statement syntaxes are:
command ;
command delay_value ;
command 'cabinet_label' ;
command 'routing_label' ;
command device_type 'object_label' ;
command priority 'object_label' ;
command priority device_type 'object_label' ;
command priority 'amp_label' to 'channel_label' ;
command 'guard_label' Route route_id ;
Note: When the device_type and 'object_label' parameters are
optional you must specify one or the other or both.
where:
command Specifies the required final state of the output

device. See Output commands for a description of
output commands and their usage.
priority Specifies the relative importance this command has
over other commands affecting the same output
device. See Priorities for a description on priority
levels and their usage.
device_type Specifies the device type of the output device
responding to the command. The device_type
parameter is optional when using the 'object_label'
parameter. When the device_type parameter is not
included, all devices whose label matches
'object_label' will respond to the command.
delay_value Specifies the length of a delay in seconds.
'object_label' Specifies the label of the output device or circuit
responding to the command. The 'object_label'
parameter is optional when using the device_type
parameter. When the 'object_label' parameter is not
included, all devices with the specified device type
will respond to the command.
'cabinet_label' Specifies the label of the panel responding to the
command (MCM1 for standalone systems).

Overview
'routing_label' Specifies the label of the network routing group

responding to the command (not available for
standalone systems).
'amp_label' Specifies the label of an amplifier.
'channel_label' Specifies the label of an audio channel.
'msg_label' Specifies the label of a voice message.
'guard_label' Specifies the label of the Guard Patrol group.
route_id Specifies the route number of the guard patrol tour.
Events
An event is the outcome produced by a controller module when
an addressable point on the panel changes state. The information
contained in an event includes the logical address of the point
that changed state, the event type, and the event message.
Device types
A device type is the classification given to objects created in the
database that defines the operating characteristics of the
corresponding device. For example, the PULL device type is
assigned to objects created for manual pull stations.
See the Quick Reference for a list of device types and their use.
Objects
An object is a database entity that represents an addressable
point in the system like a smoke detector, a switch, or a light
emitting diodes (LED).
Objects can also be:
• Logic groups
• Voice messages
• Pseudo points
For example, the Signature controller module is an object as are
any Signature devices connected to it.
Note: You do not have to include the device type with the object
label. As a safeguard, however, we suggest that your input
statements include the device type and the object label.
Labels
A label is a descriptive word or set of words that identifies a
specific object in the project database to simplify programming.
Labels are also used to identify a rule in the rules file. Typically,

Overview
object labels describe the physical location of the device that the
object represents.
Tip: Extensive labels are generally harder to read. Sometimes
less is more.
Labels have the following characteristics:
• Labels must be unique. Duplicate labels generate compiler
errors and prevent the database from compiling.
• Labels are arbitrary except for labels that are automatically
assigned by the system.
• Labels are not case sensitive and may contain up to 40
characters. The characters may be any ASCII character
except: braces “{ }” , the percent symbol “%”, the number
symbol “#”, less than and greater than symbols “< >”,
asterisks “*”, and blank spaces.
The SDU automatically replaces invalid label characters as
shown below to prevent programming errors.
Character substitution table

User types User sees
space underscore
* @
% @
# @
< (
> )
{ (
} )

Overview
Creating a rules file

Exceeding rules editor memory limits
The SDU provides an editing tool for creating and editing a rules
file. The tool is known as the Rules Editor and is limited to
editing files of 32 kilobytes or less. Most projects do not
approach the memory limits of the rules editor. If it appears,
however, that you cannot avoid exceeding the limits, you can
use a different text editor.
Note: You will no longer be able to use the rules editor if your
rules exceed the 32-kilobyte limit.
To use a text editor that can exceed the 32K limit:
1. Enter the rules in the text editor (MS Word®, Wordpad®, or

Notepad®).
2. Save the file as PROJRULE.TXt in C:\\FAST\2-
SDU\PROJECT\PROJECT_NAME\01_00_00.
3. Open the project in the 2-SDU.
4. Compile the rules by selecting Compile in the Rules menu.
If you attempt to open the rules editor you will see a warning
box, which states that you have exceeded the 32K limit.
Nevertheless, you can still compile the rules.
Tip: Look for instances where advanced programming
techniques may be used to reduce the rule file's size.
Order is important
When you have more than one rule that uses the same input
requirements to trigger separate output responses, the order in
which the rules appear in the rules file affects how the rules are
executed. The compiler takes multiple rules with common input
statements and executes them as though they were a single rule
containing multiple output statements. The output statements are
executed in the same order that they appear in the rules file.
Suppose, for example, that you have a rules file containing:
[Rule 1]
ALARM SMOKE 'LVL5_SMK1' :
DELAY 30,
FANON 'STAIRWELL_FAN_2';

Overview
[Rule 2]
LEDON 'FACP_LED28' ;
[Rule 3]
ON AUDIBLE 'LVL5_AMP1';
After compiling, the rules would be executed as though they
were written:
[Compiled Rule]
DELAY 30,
FANON 'STAIRWELL_FAN_2',
LEDON 'FACP_LED28',
Notice that the placement of Rule 1 before Rule 3 results in a
delay before sounding the horn. The outputs scattered over the
three rules all have a common input. If you begin by grouping all
the outputs to the common input, you can easily spot conflicts
and avoid them. You can also economize on rule editor memory.
It makes a difference, however, when you have more than one
rule that uses the same device but different event types. To
illustrate this suppose you have the following two rules:
[Rule 1]
TROUBLE SMOKE 'LVL5_*':
LEDON 'FACP_LED28',
DELAY 300,
[Rule 2]
ALARM SMOKE 'LVL5_*':
FAST 'CAB1_PNL1_LED1',
If any smoke detector on level 5 goes into trouble, the panel will
activate Rule 1. The panel will then turn the specified LED on,
wait 5 minutes (300 seconds), and turn on the specified
amplifier. If another smoke detector on level 5 goes into alarm
during the delay period, the panel will activate Rule 2, which
will immediately override any commands in Rule 1.
The panel does not wait for the trouble response (Rule 1) to
finish before running the alarm response (Rule 2). In this
example however, panel will resume executing Rule 1 if the
trouble condition remains after the delay period expires.
Tip: When adding rules to a previously compiled rules file, place
them at the beginning of the file so they will be checked first. If
they need to be in a certain spot in the file, you can move them
afterwards.

Overview
Avoid careless use of wildcards

A wildcard is a powerful programming aid that can help reduce
the size of your rules file. Remember, however, that the
wholesale use of wildcards could have undesirable results.
Consider, for example, the following three rules:
[Rule 1]
ALARM '*':
LEDON 'FACP_LED28';
[Rule 2]
ALARM 'SMK_*':
DELAY 10,
LEDON 'FACP_LED29';
[Rule 3]
ALARM 'SMK_LVL1_*':
DELAY 10,
LEDON 'FACP_LED30';
A wildcard in the input statement will cause the compiler to
create an output response for each device that matches it. In the
rules above, order is still important, and the output response for
an alarm-initiating device labeled 'SMK_LVL1_1' would result
in:
[Compiled Rule]
ALARM 'SMK_LVL1_1':
LEDON 'FACP_LED28',
DELAY 10,
LEDON 'FACP_LED29',
DELAY 10,
LEDON 'FACP_LED30';
The addition of the smoke detector device type (SMOKE) to the
input statement would limit the output responses to only smoke
detectors with matching labels.
Likewise, you must be careful when using the wildcard character
in an output statement. For example, placing a wildcard
immediately following the N-variable may return undesirable
results. 'LVL<N:1>*' will select 'LVL1', 'LVL19', 'LVL199', and
so on.

Overview
Compiling the rules file

You will have to compile the rules after you create them in the
rules editor. The compiler checks the rules for improper syntax
and other faults before translating the database into a binary
setup file. The compiler also checks the database for unlabeled
objects and objects with duplicate labels.
The speed at which the compiler checks the rules file depends on
the size of the database and the construction of the rules.
Compile speed is relative, but rules that specify:
• Only the device type compile fastest
• Only the object label compile slowest
• Device type and object label compile at medium speed
The rules compiler ignores any characters between opening and
closing braces. The rules compiler also ignores tabs, spaces, and
line breaks. Run the rules compiler for every change you make
in the project database.
Tip: As a troubleshooting aid, you can make temporary use of
braces to comment out parts of the rules file that are correct.

Overview
Developing a labeling plan

Why use labels
The reduction of human effort

Years ago, system designers had to use elaborate addressing
schemes when they configured large fire alarm networks. The
numeric addresses made sense to the network hardware, but
people struggled to interpret and remember them. The tracking
of numerous addresses increased the effort required to program a
system.
Advancements in system software design now permit
referencing system components by a name instead of a number.
In programming terms, this name is called a label. A suitable
label for a system component will immediately reveal its
identity, location, or function.
For example, what can you tell about the following two items?
Address Label
010324 SMOKE_ELEVLOBBY_LEVEL1
Both items identify the same smoke detector, located in the

elevator lobby on the first floor of a multifloor building. The
item on the left is a numeric device address that reveals little
information about the device. The item on the right is a label that
reveals quite a bit more information about the detector.
The formation of a consistent plan

System programming requires the assignment of labels to
modules and other objects in the database. Presumably, several
people will need to know how to interpret the label assignments.
Also, the meaning of the labels needs to be clear long after the
programmer has assigned them. A sound label plan will ensure
logical and useful labels.
Tip: Ensure that every label is unique. Any two objects with
identical labels will cause a system conflict.
A good plan will include consideration of:
• Label format
• Descriptive label content
• Common label modifiers
• Label numbering
• Labels as messages

Overview
Formatting labels
The person responsible for the labeling plan should remember
that labels will be viewed online, on printed reports, and on the
system display panel. Formatting considerations may include:
• How to separate label modifiers
• Whether to use uppercase, lowercase, mixed-case characters
• How to abbreviate label modifiers
Note: Functionally, it makes no difference whether your labels
contain upper or lowercase characters.
Methods for formatting labels

Suppose that you create labels for multiple cabinets in an
industrial park of several buildings. The following illustration
shows three different ways to format a label for a cabinet in one
of the buildings:
BLDG1CAB BLDG1_CAB Bldg1Cab
The left label may be hard to read because it uses all uppercase
characters and there is no separation between the label modifiers
BLDG1 and CAB. The center label places an underscore
between the two modifiers, which makes it easier to read. The
right label uses upper and lowercase characters to differentiate
between label modifiers.
Label formatting advice

Be consistent in any label-formatting plan you choose.
Consistency is the most important factor in making your labels
easy to use and understand. Notice in the example above that
each label abbreviates “Building” the same way. You want to
avoid using BLDG1, Bldg_1, and Bldg1 as label modifiers to
reference the same building.
Find a comfortable balance between readability and length.
Extra underscores may separate label modifiers and make the
label more intelligible but they may also add unnecessary length.
Consider the label BLDG_1_LEVEL_7_CAB. Perhaps a better
way to label the cabinet is BLDG1_LVL7_CAB. The reduction
of separators and the abbreviation of level 7 made the label more
efficient.
Projects that involve several programmers will require
cooperation between everyone who assigns labels. The team
should agree on a labeling format and adhere to it.

Overview
Making descriptive labels

The content of the label should include descriptive modifiers
that reference the object's location, its function, or its device
type. The combination of label modifiers to describe the object's
location and function depends on its application.
Using labels to describe location

Each cabinet in a system is given a numerical designation to
identify its position, but not its location. Therefore, a cabinet
label should always describe its location. Typical modifiers for
cabinet labels in a high-rise application might include:
• LOBBY
• LEVEL7
• EAST_WING
Typical modifiers for cabinet labels in a campus application
might include building names, like:
• BLDG1
• WILSON_HALL
• ADMIN
Using labels to describe function

Some devices in a system provide specific functions. Typical
modifiers for devices, which provide a specific function, might
include:
• DMPR_CNTRL_SW (for a damper control switch)
• AMP_LVL7 (for an amplifier on the 7th floor of a building)
• LEDPANEL (for an LED panel)
Using labels to describe a device type

A system may contain a large number of certain devices, such as
detectors. For devices that exist in large quantities, you might
want to consider using a label to describe the object's device
type. Typical modifiers for these devices include:
• SMK (for smoke detectors)
• PULL (for pull stations)
• LED (for LEDs)
• SW (for switches)
Tip: You can also use an object's device type in the input
statement of a rule. See Creating rules later in this chapter.

Overview
Using common label modifiers

As you develop your labeling plan, consider the use of common
label modifiers to simplify programming decisions. Common
label modifiers quicken the assignment of labels in the
Prefabricated Labels editor and allow the use of wildcards.
Using common labels for building levels

The use of Floor numbers as label modifiers can sometimes
create extra work for the system designer. The extra work comes
from areas, like basements and mezzanines, which do not have
floor numbers. Consequently, you may want to use a generic
label modifier, like LVL, which can apply to all areas of the
building. Figure 1-1 illustrates the use of LVL as a common
label modifier in a building with several kinds of areas.
Note: You may still want messages that appear on the system
display panel to reference floor numbers.
Penthouse LVL11
7th Floor LVL10
6th Floor LVL9
5th Floor LVL8
4th Floor LVL7
3rd Floor LVL6
2nd Floor LVL5
Mezzanine LVL4
Lobby LVL3
Basement LVL2
Sub-basement LVL1
PROG001.CDR
Figure 1-1: Diverse building areas labeled by a common modifier
Using numbers in labels

Another way to make programming easier is to include numbers
in your labeling plan. Numbers are particularly useful in labels if
several of them have common label modifiers. You will also be
able to apply advanced programming techniques to numerically
modified labels. For example, AMP_LVL1, AMP_LVL2, and
AMP_LVL3 will work well in floor-above and floor-below
applications. Devices activated floor-by-floor should include
some reference to the floor level number in the device label.

Overview
Using numbers to make a label unique

Unique labels can identify special control functions like elevator
lobby, smoke detector, stairwell, and duct applications. For
example, the modifier LVL2_DUCT identifies a duct smoke
detector on the second level of a building. Additional duct
detectors on the same floor can use a similar label, but they
require a unique numeric modifier for identification. For
example, LVL2_DUCT1 is one possible label for a duct smoke
detector located on the 2nd level. The only distinction it has
from any other duct label on level 2 is the 1 at the end of DUCT.
If there were no other duct detectors on level 2, LVL2_DUCT
would be sufficient to make the label unique.
Using wildcards with numbers

In programming, labels with one or more common modifiers
create a tremendous advantage. Common label modifiers allow
the use of wildcards (*). A wildcard acts like a space reserved
for any number that follows a common modifier. For example, a
database may include the following labels:
• LVL1_DUCT1
• LVL1_DUCT2
• LVL1_DUCT3
In the rules, LVL1_DUCT* could easily replace LVL1_DUCT1,
LVL1_DUCT2, or LVL1_DUCT3. If LVL1_DUCT3 becomes
active, the 3 will replace the wildcard (*) in the rule.
Tip: For more information about using wildcards, see Advanced
programming features.

Overview
Using labels as messages

You can program the system to display a different message on
the front panel display when each associated object goes active
or into alarm. If you design your labels with this function in
mind, you may be able use the label as the message instead of
creating a separate message in the Object Configuration.
Suppose that a device goes into alarm and you want the front
panel display to show its location and type. If you label the
smoke detector as ROOM101_SMOKE, the display will read:
SMOKE ACTIVE
ROOM101_SMOKE
Suppose also that the smoke detector is the only device in the
room, and a single modifier can uniquely identify it. You might
label the detector ROOM101, so the display would read:
SMOKE ACTIVE
ROOM101
This strategy limits the redundant information on the display and
shortens the label. Remember, however, that this plan will only
work if the labels remain unique.
Note: Only two 20-character rows appear in any message on the
front panel display. The balance of the message text is sent to
the printer.

Overview
Identifying object group relationships

Linking inputs to outputs
Whenever you read a job specification, try to get a feeling for
the functions (outputs) required of the system. Try also to find
the locations and types of devices (inputs) that initiate these
functions. The goal is to create user-friendly labels from
common functions, areas, or devices, which will also permit
efficient programming. The most effective method of
recognizing common input and output functions is to create an
input-to-output matrix.
Sample matrix
Figure 1-2 is an abbreviated example of an input-to-output
matrix. Place a mark (X) at the intersection of each output
activated by the input. When you have entered every input and
output on the matrix, inspect it for groups or patterns of marked
intersections. The patterns may appear as columns or blocks of
marked intersections. When you identify such groups, look at
the inputs to see what they have in common.
Alarm functions
Figure 1-2 illustrates six object groups of marked intersections.
Three object groups appear in columns, in which any input will:
• Sound general alarm
• Notify central station
• Lock stairwell Doors
Consequently, the first rule must activate all three functions
whenever any device in Figure 1-2 goes into alarm.
Elevator capture function

The next object group involves the Elevator Capture function.
All of the inputs that initiate the elevator capture function are
smoke detectors in the elevator lobby. Yet, the system also
includes other smoke detectors. Therefore, the label modifier
SMK is not the best choice to identify the elevator capture
function. You may include SMK as a modifier in the device
label, but you should avoid using it to signify the elevator
capture function. Better choices might include:
• ELEVATOR
• LOBBY
• ELEVATOR_SMK1
• LOBBY_SMK1
• ELEVLOBBY_SMK

Overview
Remember to make the labels unique. Suppose, for example that

you need to assign a label to the smoke detector in the elevator
lobby on the second floor. LVL2_SMK1_ELEVLOBBY would
work well with the elevator capture rule. The keyword
ELEVLOBBY will become a part of the elevator capture rule.
Any label with an ELEVLOBBY modifier will activate an
elevator capture.
Output functions
wn
e
ks
tio
tur
tdo
loc
AC
st
sta
e
ap
AC
tur
u
AC
C
rm
hu
HV
a
rc
or
al
VA
HV
ap
h
HV
ala
rs
do
ntr
ex
ato
rH
nt
c
ute
ce
ell
me
tor
or
or
lev
ral
loo
oo
flo
flo
irw
mp
tify
va
ne
.e
se
df
t fl
Ele
3rd
1-3
Sta
Ge
No
Co
Ba
Alt
2n
1s
Input functions
3rd floor pull station X X X

3rd floor area smoke detector X X X
LVL3
3rd floor duct smoke detector X X X X X
3rd floor elevator lobby smoke detector X X X X
2nd floor pull station X X X X
2nd floor area smoke detector X X X X
LVL2
2nd floor duct smoke detector X X X X X X
2nd floor elevator lobby smoke detector X X X X X
1st floor pull station X X X
1st floor area smoke detector X X X
LVL1
1st floor duct smoke detector X X X X X
1st floor elevator lobby smoke detector X X X
Bsmnt floor pull station X X X
Bsmnt floor area smoke detector X X X
LVL0
Bsmnt floor duct smoke detector X X X X
Bsmnt floor elevator lobby smoke detector X X X X
[PROG002.CDR]
Figure 1-2: Input-to-output matrix
Computer shutdown function

Another object group is the computer shutdown function, which
can be initiated by any input from the second floor. Accordingly,
every device on the second floor should include a label modifier

Overview
like LVL2. In fact, the floor or level number should modify

every device label in a multifloor structure. Any device with the
LVL2 modifier in its label will activate the computer shutdown
function. Note that the elevator lobby detector labeled in the
previous example will also shutdown the second floor computer.
LVL2 is also a keyword in the elevator shutdown rule.
Floor exhaust function

The final object group is the 1-3 floor exhaust function, which is
initiated by duct smoke detectors on floors 1, 2, and 3. Include
the modifier DUCT with the device label for all duct detectors.
Notice that the input-to-output matrix rules out the activation of
the 1-3 Exhaust function by the basement duct detector. This
fact should not affect the choice of DUCT as a label modifier in
the device label. It will still be useful to the designer in
determining the device function.
DUCT is a keyword in the 1-3 exhaust rule. Yet, not all
detectors with DUCT in their labels are required to activate the
1-3 exhaust function. Therefore, the additional keywords LVL1,
LVL2, and LVL3 will be added to the 1-3 exhaust function rule.
Devices that will active the 1-3 exhaust rule will include the
label modifiers:
• LVL1_DUCT
• LVL2_DUCT
• LVL3_DUCT
Specific functions and devices

Notice that there are a few matrix entries, which are not part of
any group. A specific device will activate these functions. The
rules used to activate these outputs are written for the specific
function, rather than use by multiple objects.
The matrix for a major project would be very large and detailed.
Many inputs will have only one or two output correlations. The
experienced system designer will recognize developing patterns.
In Figure 1-2, note that the first, second, and third floors are
basically copies of each other. This is typical of high rise
buildings. This duplication of functions permits a designer to
recognize that the floor (or level) number will be an important
label modifier when creating labels for devices.
Our example also reveals the importance of well-planned label
modifiers. The proper selection of device labels permits the
designer to account for the common functions throughout the
building by writing only a few rules.

Chapter 2
Advanced programming features
Summary
Advanced programming techniques provide additional
programming tools, which can simplify application
programming and reduce the size of the rules file.
Content
Variables • 2.2
Using wildcards • 2.2
Using the N-variable • 2.2
Using L-variables • 2.3
Using mathematical operators • 2.4
Priorities • 2.5
Priority 0 (Clear) • 2.5
Priority 99 (Latch) • 2.5
Logic groups • 2.7
AND groups • 2.7
Bell code groups • 2.7
Dialer groups • 2.7
Guard patrol groups • 2.8
Actions and Sequences • 2.9
Related information • 2.9
Actions • 2.9
StartAction • 2.10
GuardPatrolAlarm • 2.11
NetworkClassAFault • 2.11
Sequence • 2.11
StartSequence • 2.12
TimeControl • 2.13

Variables
Variables add flexibility to the rules and sometimes reduce the
number of rules required to program the system.
Using wildcards
The asterisk (*) can be used in a rule to conditionally select
devices based on the character pattern used in their object labels.
The asterisk may be substituted for any single or group of
characters anywhere in the label.
Example Selects
LVL* any devices whose labels begin with LVL
*_SMK any devices whose labels end with _SMK
LVL*_SMK any devices whose labels begin with LVL and
end with _SMK
*_SMK_* any devices that have _SMK_ somewhere in
the label
In the following example, any smoke detector on levels 2-10 will

activate the horns and strobes on the floor of incident.
ALARM SMOKE'LEVEL<N:2-10>_SMK*':
ON AUDIBLE 'LEVEL<n>_HORN',
ON VISUAL 'LEVEL<n>_STROBE';
Using the N-variable

The programming variable N can be used in a rule to
conditionally select devices based on the numerical indexing
used in their object labels.
When using the N-variable, the numbers required to make the
conditional true are specified in the input statement. When the
input statement becomes true, the number is substituted for the
variable n in the output statement.

Example Selects
<N: #> a single number entry
<N: # - #> a range of numbers
<N: #, #, # - #, # - #> a combination of single numbers and
number ranges
where:
• # may be any number between 0 and 32767
• Wildcards may not be used in place of a number
• The N-variable can only be used once in a label
Example
When the device labeled LVL1_PHONE_JACK confirms that it
has been energized, the LED labeled LVL1_PHONE_CALL is
turned off.
[PHONE_CONNECT_MADE]
CONFIRMATION FIREPHONE 'LVL<N:1,3-5>_PHONE_JACK': LEDOFF LED 'LVL<N>_PHONECALL';
Note: Placing a wildcard immediately after the N-variable may

return undesirable results. For example, specifying 'LVL<N:1>*'
includes 'LVL1', 'LVL19', 'LVL199', and so on.
Using L-variables
The programming variable L can be used in the output statement
of a rule to direct commands to multiple devices based on the
numerical indexing used in their object labels.
Example Selects
<L: #> a single number entry
<L: # - #> a range of numbers
<L: #, #, # - #, # - #> a combination of single numbers
and number ranges
where:
• # may be any number between 0 and 32767
• Wildcards may not be used in place of a number
• The L-variable can only be used once in a label

Example
The following rule lights the same LED on four separate panels
when a detector goes active in Building 1.
[SAMPLE_RULE]
ACTIVE SMOKE 'BLDG1_SMK_<N:1-4>': ON LED 'BLDG<L:1-4>_LED<N>';
Using mathematical operators

Mathematical operators can be used in conjunction with the N-
variable in the rule output statement to conditionally select
devices based on the numerical indexing used in their object
labels.
When using mathematical operators, the numbers required to
make the conditional true are specified by the N-variable in the
input statement. When the input statement becomes true, the
number is substituted for the variable n in the output statement
and then increased or decreased by the number specified by the
#-variable.
Example Substitutes
<n + #> a number greater than the number
determined by n in the input statement
<n - #> a number less than the number
determined by n in the input statement
where:
• # may be any number between 1 and 32767, inclusive.
• Wildcards may not be used in place of a number.
• <N + #> may not equal greater than 32767.
• <N - #> may not equal less than zero.
Example
Any smoke detector on levels 2 through 10 will turn on the fire
floor horns and strobes when it goes into alarm. It will also turn
on the horns and strobes of the floors above and below fire floor.
[FloorAbove_FloorBelow]
ALARM SMOKE'LVL<N:2-10>_SMK*': ON AUDIBLE 'LEVEL<N>_HORN',
ON VISUAL 'LEVEL<N>_STROBE',
ON AUDIBLE 'LEVEL<N+1>_HORN',
ON VISUAL 'LEVEL<N+1>_STROBE',
ON AUDIBLE 'LEVEL<N-1>_HORN',
ON VISUAL 'LEVEL<N-1>_STROBE’;

Priorities
Priorities specify the order of importance a command has over
other commands affecting the same output device. When an
output device is turned on (set) or turned off (reset) using a
priority, the state of the output device can only be changed by
another command with a greater priority. If another command is
executed that has a priority of equal or lesser value, then the
output device will not change states.
Tip: If outputs do not The following priority values may be used in a rule:
require prioritizing, assign
the default priorities as 00 • Any number between 0 and 99
in the project preferences. • Low (25), medium (50 ), or high (75)
• Clear (0), or latch (99).
The default priority is set for 0, but can be changed in the
project preferences in the Systems Definition Utility. Priority 0
and 99 perform special functions as described in the following
sections.
Priority 0 (Clear)
Priority 0 may be used exclusively when outputs do not need to
be prioritized. When an output is turned on or off with priority
00, the following occurs:
• The output is forced to the new condition (set or reset)
regardless of its previous priority. In this case, priority 00 is
considered the highest priority.
• Immediately after the output changes state, it assumes the
characteristics of an output with the lowest priority level and
may be commanded to the opposite state again by any new
priority.
Priority 99 (Latch)
Priority 99 may be used to latch the output of a device to either
the set or the reset state. An output, when latched, will not
restore when the input causing the change of state has restored.
This type of priority may be useful in the following applications:
• amplifier backup switching
• security circuits
• fan control circuits
The following points must be considered when using relay
priority 99:
• An output that is turned on by priority 99 can only be turned
off by a priority 0
• An output that is turned off by priority 99 can only be turned
on by a priority 99 or 0

Additionally, when priority 0 overrides priority 99, the output is

assigned the lowest nonlatching priority level (priority 0).

Logic groups
Input devices can perform system functions based on their
association with logic groups. Logic groups include AND
groups, Bell Code groups, Dialer groups, and Guard Patrol
groups. Logic groups are defined in the Object Configuration.
Note: The programmer must select labeled devices in the Object
Configuration tables to include them in a logic group. Also, the
device must be appropriate for the logic group. For example, a
smoke detector is not compatible with a guard patrol group.
AND groups
AND groups generate a group response when all devices in the
group are active. In addition to configuring the logic group in the
database, the AND group response must also be defined in a rule
statement.
Note: Each active device in a group generates an individual
response.
Example
10 smoke detectors are installed in a computer room. Three of
the ten detectors are assigned to AND_GROUP1 for setting off
the automatic release of a fire-extinguishing agent.
The first rule below provides an individual response for each
detector in the room. The second rule specifies that the detectors
in AND_GROUP1 will release the agent when it goes active.
[COMPUTER_ROOM]
ALARM SMOKE 'COMPROOM_SMK<N:1-10>: LEDON LED 'COMPUTER_ROOM';
[AND_GROUP1]
DEFINE AND 'AND_GROUP1': ON RELAY 'AGENT_RELEASE';
Bell code groups

Bell Code groups provide a coded notification signal, which
represents a specific floor or zone. Bell code groups do not
require rules.
Dialer groups
Dialer groups provide automatic notification of an incident on a
particular floor or zone to a Central Monitoring Station. Dialer
groups do not require rules.

Guard patrol groups

Patrol groups are sets of input devices, which must be activated
within specific time intervals and in sequential order. The
typical application is for guard patrols. Guard patrol groups are
defined in the Object Configuration. Each route of a guard patrol
group lists the number of stations and minimum times to reach
each patrol station.
Note: The GuardPatrolAlarm response must be defined in a rule
statement. See Define event and Activate command.
Example
Tip: Open the Object Configuration and click tab labeled Guard
Patrol Groups to get the full benefit of this example.
A programmer created a guard patrol in the Object
Configuration. The guard patrol was labeled
GUARD_PATROL_GROUP1 and it includes several routes.
Route 2 requires the toggling of an SWU-8 switch at a station on
each floor. Each station must be reached within ten minutes of
the last station. The building consists of six floors and the check-
in sequence is in ascending order from LVL1_SWU8_SW1 to
LVL6_SWU8_SW1.
The guard patrol is actually initiated at the fire alarm control
panel upon the activation of a switch labeled FACP_SW17. The
switch is located on the second LED/switch module at the fire
alarm control panel. The system will issue a GuardPatrolAlarm
for any check-in that is overdue or out of sequence. In this case,
the GuardPatrolAlarm will light an LED labeled FACP_LED17.
The LED also has a slip-in label next to it to identify the guard
patrol route.
To carry out the specifications of the guard patrol group, the
system requires two rules. One rule will turn on the guard patrol
and the specific route. The other rule will define the system
response to a GuardPatrolAlarm when the route is not properly
executed.
[ON_GUARD_PATROL1_ROUTE2]
ACTIVE SWITCH 'FACP_SW17': ONGUARD GUARDPATROL 'GUARD_PATROL_GROUP1' 2;
[GUARD_PATROL_ALARM]
DEFINE GUARDPATROLALARM 'MCM1': LEDON LED 'FACP_LED17';

Actions and Sequences

Actions and sequences may be defined in rule statements to
execute common output responses. These common output
responses can then be activated whenever required without
having to duplicate them in each rule.
Related information
You can find more information about actions and sequences in:
• Activate command
• Define events
• Restore command
Actions
Actions that perform certain system functions are predefined in
the panel controller. For example, the front panel Drill switch calls
the Drill action. The programmer may expand these actions by
defining additional output responses in a rule statement. The
system programmer can also define other actions.
Predefined Actions Description

AlarmSilence Turns off all audibles and, optionally,
(Action 9004) all visuals depending on panel
configuration.
Drill Turns on all audibles and, optionally,
configuration.
Evacuation Turns on all audibles and, optionally,
configuration.
SysReset Resets the panel controller and all
(Action 9002) restored alarm initiating devices.
LampTest Flashes all LEDs on panel controller
display and all local display strips.

Modifying predefined actions

To add additional responses to a predefined action, use the
following syntax:
[rule_label]
DEFINE action_name 'object_label': output_statement;
where:
• action_name is name of the predefined action
• 'object_label' is the label of the panel controller*
• output_statement is the additional system responses
*'MCM1' for standalone systems
Creating user-defined actions

To create a user-defined action, use the following syntax:
[rule_label]
DEFINE ACTION 'object_label': output_statement;
where:
• [rule_label] is the name of the user-defined action
• output_statement is the system response
Note: There is no limit to the number of nested actions that can
be activated from within an action (i.e., action 1, activates action
2, which activates action 3, etc.)
StartAction
Use StartAction to initialize the configuration of selected program
elements whenever the system is powered up (cold started) or
restarted (warm boot). For example, a StartAction may can enable
the system time control functions or initialize supplementary
systems connected to the panel.
To define a StartAction, use the following syntax:
[rule_label]
DEFINE STARTACTION 'object_label': output_statement;
where:
Note: The StartAction does not occur after a panel reset.

GuardPatrolAlarm
Use GuardPatrolAlarm to define a set of responses that will
execute when a guard patrol station is activated out of sequence
or not activated within the required time period.
To define a GuardPatrolAlarm, use the following syntax:
[rule_label]
DEFINE GUARDPATROLALARM 'object_label': output_statement;
where:
See Guard patrol groups for an example.
NetworkClassAFault
Use NetworkClassAFault to define a set of responses, which
will execute upon the detection of an open circuit on the
network RS-485 line.
To define a NetworkClassAFault, use the following syntax:
[rule_label]
DEFINE NETWORKCLASSAFAULT 'object_label': output_statement;
where:
Sequence
Use Sequence to define a series of time-delayed output responses.
These responses can be commands, actions, or other sequences.
Time delays are placed before each response using the Delay
command and may be set anywhere between 5 and 4096 seconds,
inclusive.
Typical uses for sequences are:
• To automatically change a tone to a pre-recorded message
after a time delay
• For staggering the activation and shut down of air supply fans
during an alarm
Note: Outputs that have been SET by a sequence will not restore
when the input causing the sequence has restored. These outputs
must be reset by the SysReset function or by a switch.

To define a Sequence, use the following syntax:
[rule_label]
DEFINE SEQUENCE 'object_label': output_statement;
where:
The panel controller allocates 1024 blocks of memory space for
executing sequences. Each sequence consists of a 1-block
definition header and any number of 1-block delay/action pairs.
It is possible define a single sequence with up to 1023 blocks
(delay/action pairs.)
[FANON_SEQ]
1 BLOCK DEFINE SEQUENCE 'MCM1':
1 BLOCK
DELAY 5,
NSFANON FANCONTROL 'EXHFAN_RELAY',
DELAY 10,
1 BLOCK
NSFANON FANCONTROL 'SUPFAN_RELAY';
= 3 BLOCKS
If more than one sequence is active at the same time, the total
number of sequence blocks may not exceed 1024.
Note: There is no limit on the number of actions or nested
actions that a sequence executes.
StartSequence
Use StartSequence to initialize the configuration of selected
program elements whenever the system is powered up (cold
started) or restarted (warm boot.) A start sequence may be used,
for example, to stagger power to air supply fans and large motor-
driven circuits.
Note: The StartSequence does not occur after a panel reset.

TimeControl
Use TimeControl to define a set of responses that will activate
when a configured time control goes active. Time controls are
created in the Time controls dialog box.
Caution: Make sure you create actual time controls before you
create rules for them. If the compiler sees a rule that references a
nonexistent time control, it may go into a loop error and corrupt
the SDU software.
To create a time control:
1. Click the following path in the SDU: Configure/Time

Controls.
2. In the Select Time Control dialog box, click New.
3. Enter the parameters for the time control in the Time
Control dialog box.
4. Click OK.
To define a time control action, use the following syntax:
[RULE_LABEL]
DEFINE TIMECONTROL 'object_label': output_statement;
where:
• 'object_label' is the label of the configured time control
Note: Time controls may be enabled from the front panel or
automatically at startup, but no more than 63 time controls may
be enabled at any one time.
Example
The programmer created a time control that will start every day
at 19:30 hours (7:30 PM) and last for 60 minutes. The
programmer labeled the time control TCGP1_2 to signify its
function turning on route 2 of GUARD_PATROL_GROUP1. By
itself, however, the time control will have no effect on the
system. The programmer's last task is to define the time control
in the rules.
[ON_TCGP1_2]
DEFINE TIMECONTROL 'TCGP1_2' : ONGUARD GUARDPATROL 'GUARD_PATROL_GROUP1' 2;

Note: For more information about guard patrols, see Guard

patrol groups.

Chapter 3
Input events
Summary
Use this chapter to compose input statements in the rules editor.
Content
Active events • 3.2
Alarm events • 3.4
CallIn events • 3.5
Confirmation events • 3.6
Define events • 3.7
Monitor events • 3.9
Supervisory events • 3.10
TestActive events • 3.11
TestTrouble event • 3.13
Trouble events • 3.15

Input events
Active events
Purpose
Use the Active input event to trigger the execution of a rule
when any device goes active during normal, standby operation.
Syntax
Active device_type 'object_label' :
– or –
Active device_type :
Device types
Table 3-1 identifies valid devices for Active events.
Table 3-1: Valid device types and devices

Device types Devices
Alarm initiating devices Duct
Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow
Latching or non-latching AuxPowerSupply
supervisory devices Gatevalve
Power
SprinklerSupervisory
SupDuct
Supervisory
Tamper
Temperature
Non-latching monitor devices DamperFeedback
DoorFeedback
Emergency
FanFeedback
Monitor
Switch devices Switch
UserDefinedSwitch
Object labels
The object label specifies the unique label of the device initiating
the Active event.

Input events
Examples
Example 3-1 identifies possible syntax for a rule, in which:
• LVL1_PHONE_CNTRL turns on LVL1_PHONE_JACK
Example 3-1: Syntax for active phone switches

[PHONE_SWITCH]
ACTIVE SWITCH 'LVL<N:1,3-5>_PHONE_CRNTL' : ON FIREPHONE 'LVL<N>_PHONE_JACK';
Example 3-2 identifies possible syntax for a rule that will turn on
NAC_1 and NAC_2 when a heat detector goes active. The rule
will work for every heat detector on the first floor as long as the
labels follow a consistent scheme. For example, the labeling
scheme could be HEAT_FLR1F_1 for a fixed-temperature heat
detector or HEAT_FLR1R_1 for a rate-of-rise heat detector.
Example 3-2: Syntax for active heat detectors

[HEAT_FLR1]
ACTIVE HEAT 'HEAT_FLR1*_*' : ON 'NAC_<L:1-2>';

Input events
Alarm events
Purpose
Use the Alarm event to trigger the execution of a rule when an
alarm-initiating device goes active during normal, standby
operation.
Syntax
Alarm device_type 'object_label' :
– or –
Alarm device_type :
Device types
Valid devices for the Alarm events include:
• Duct
• Heat
• Pull
• Smoke
• SmokeVfy
• StageOne
• Waterflow
Object labels
the Alarm event.
Example
Example 3-3 identifies possible syntax for a rule that will set off
a strobe on the respective floor of any pull station on levels 1
through 10. For example, a pull station on level 6 will cause the
rule to turn on the strobe in level 6.
Example 3-3: Syntax for manual pull stations

[MANUAL_PULL]
ALARM PULL 'LEVEL<N:1-10>_PULL' : ON VISUAL 'LEVEL<N>_STROBE';

Input events
CallIn events
Purpose
Use the CallIn event to trigger the execution of a rule when a
firefighter's telephone is plugged into a remote call-in jack.
Note: To establish two-way communications, the relay pseudo
points at addresses 4106 and 4107 on the audio controller must
be turned on using the On command.
Syntax
CallIn device_type 'object_label' :
– or –
CallIn device_type :
Device types
Firephone and Telephone are the only valid devices for CallIn
events.
Object labels
the CallIn event.
Example
Example 3-4 identifies possible syntax for a rule, in which a call
from any firephone on levels 1, 3, 4, or 5 will cause the panel to:
• Turn on an associated LED at the fire alarm control panel
• Close the relay labeled PHONE_CALL_IN_RELAY_1_41
• Close the relay labeled CALLIN_EXISTS_1_41
Example 3-4: Syntax for Firephone callins

[PHONE_CALLIN]
CALLIN FIREPHONE 'LVL<N:1,3-5>_PHONE_JACK' : ON LED 'LVL<N>_PHONE_CALLME',
ON RELAY 'PHONE_CALL_IN_RELAY_1_41',
ON RELAY 'CALLIN_EXISTS_1_41';

Input events
Confirmation events
Purpose
Use the Confirmation event to trigger the execution of a rule
when a supervised output device is activated in response to a
system command.
Syntax
Confirmation device_type 'object_label' :
– or –
Confirmation device_type :
Device types
Valid devices for Confirmation events include:
• Audible
• AudioAmp
• CommonAlarmOutput
• CommonMonitorOutput
• CommonSupervisoryOutput
• CommonTroubleOutput
• DamperControl
• DigitalMessage
• DoorControl
• FanControl
• Firephone
• Telephone
• Visual
Object labels
the Confirmation event.
Example
Example 3-5 identifies possible syntax for a rule, in which:
• LVL1_PHONE_JACK turns on LVL1_PHONE_READY
Example 3-5: Syntax for confirmation of firephone

CONFIRMATION FIREPHONE 'LVL<N:1,3-5>_PHONE_JACK' : LED ON LED 'LVL<N>_PHONE_READY';

Input events
Define events
Purpose
Use the Define event to determine system responses that should
occur for a given action, sequence, AND group, or time control.
Note: By default, the 2-SDU automatically generates rules that
define Drill (action 9003), AlarmSilence (action 9004), and
Evacuation (action 9500) responses. Deselect the Generate
Default Rules in Project Preferences to customize these actions.
Syntax
Define device_type 'object_label' :
Device types
Table 3-2 identifies valid devices for Define events.

Actions Action
AlarmSilence
Drill
GuardPatrolAlarm
LampTest
NetworkClassAFault
Sequence
StartAction
SysReset
Sequences Sequence
StartSequence
AND groups And
Time controls TimeControl
Object labels
the Define event. The object label specifies:
• MCM1 for actions and sequences
• AND group labels for AND groups
• Time control labels for time controls
Examples
Example 3-6 identifies possible syntax for defining an action that
will cause MCM1 to turn on the dialer relay.

Input events
Example 3-6: Syntax for defining dialer action

[DIALER]
DEFINE ACTION 'MCM1' : ON 'DIALER_RELAY';
Example 3-7 identifies possible syntax for defining a guard

patrol alarm, which causes MCM1 to light several LEDs.
Example 3-7: Syntax for defining a guard patrol alarm

[GUARDPATROL_ALARM_RESPONSE]
DEFINE GUARDPATROLALARM 'MCM1' : LEDON LED 'BLDG_5_LED<L:2-7>;
Example 3-8 identifies possible syntax for defining a sequence

that will cause the main controller module (MCM1) to:
• Delay for 5 seconds
• Turn on an exhaust fan labeled EXHFAN_RELAY
• Delay for 10 more seconds
• Turn off SUPFAN_RELAY
Example 3-8: Syntax for defining a sequence

[FANON_SEQ]
DEFINE SEQUENCE 'MCM1' : DELAY 5,
NSFANON NSFANCONTROL 'EXHFAN_RELAY',
DELAY 10,
NSFANOFF NSFANCONTROL 'SUPFAN_RELAY';
Example 3-9 identifies possible syntax for defining an AND

group that will activate an action labeled EVACUATION.
Example 3-9: Syntax for defining an AND group

[AND_GROUP1_RESPONSE]
DEFINE AND 'AND_GROUP1' : ACTIVATE ACTION 'EVACUATION';
Example 3-10 identifies possible syntax for defining a time

control that will release a door relay.
Example 3-10: Syntax for defining a time control

[TIME_CNTRL_1_RESPONSE]
DEFINE TIMECONTROL 'TC1' : RELEASEDOOR DOORCONTROL 'DOOR_RELAY';

Input events
Monitor events
Purpose
Use the Monitor event to trigger the execution of a rule when
any monitor device goes active while the system is in normal
standby operation.
Syntax
Monitor device_type 'object_label' :
– or –
Monitor device_type :
Device types
Valid devices for Monitor events include:
• DamperFeedback
• DoorFeedback
• Emergency
• FanFeedback
• Monitor
Object labels
the Monitor event.
Example
Example 3-11 identifies possible syntax for a rule that will turn
on ANNUNCIATOR_LED_10 if WEST_DOOR is opened.
Example 3-11: Syntax for a monitored door

[WEST_DOOR]
MONITOR DOORFEEDBACK 'WEST_DOOR' : LED ON LED 'ANNUNCIATOR_LED_10';

Input events
Supervisory events
Purpose
Use the Supervisory event to trigger the execution of a rule when
any supervisory device goes active while the system is in normal
standby operation.
Syntax
Supervisory device_type 'object_label' :
– or –
Supervisory device_type :
Device types
Valid devices for Supervisory events include:
• AuxPowerSupply
• Gatevalve
• Power
• SprinklerSupervisory
• SupDuct
• Supervisory
• Tamper
• Temperature
Object labels
the Supervisory event.
Example
Example 3-12 identifies possible syntax for a rule that will light
ANNUNCIATOR_LED_5 whenever water flows through
GATEVALVE_1.
Example 3-12: Syntax for a supervised gatevalve

[GATEVALVE_1_RESPONSE]
SUPERVISORY GATEVALVE 'GATEVALVE_1' : LEDON LED 'ANNUNCIATOR_LED_5';

Input events
TestActive events
Purpose
Use the TestActive event to trigger the execution of a rule when
any initiating device goes active while the system is in test mode.
Syntax
TestActive device_type 'object_label' :
– or –
TestActive device_type :
Device types
Table 3-3 identifies valid devices for TestActive events.

Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow
Latching supervisory devices AuxPowerSupply
Gatevalve
Power
SupDuct
Supervisory,
Tamper
Temperature
DoorFeedback
Emergency
FanFeedback
Monitor
Object labels
the TestActive event.

Input events
Example
Example 3-13 identifies possible syntax for a rule that causes a
pull station to light an associated LED if it goes active during
test mode. For example:
• PULL_1 will light ANNUNCIATOR_LED_1
Example 3-13: Syntax for a testing pull stations

[TEST_PULL_STATIONS]
TESTACTIVE PULL 'PULL_<N:1-5>' : LED ON LED 'ANNUNCIATOR_LED_<N>';

Input events
TestTrouble event
Purpose
Use the TestTrouble event to trigger the execution of a rule when
any initiating device goes into trouble while the system is in test
mode.
Syntax
TestTrouble device_type 'object_label' :
– or –
TestTrouble device_type :
Device types
Table 3-4 identifies valid devices for TestTrouble events.

Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow
Gatevalve
Power
SupDuct
Supervisory
Tamper
Temperature
DoorFeedback
Emergency
FanFeedback
Monitor
Supervised output devices Audible
AudioAmp
CommonAlarmOutput
CommonMonitorOutput
CommonSupervisoryOutput
CommonTroubleOutput
DamperControl
DigitalMessage
DoorControl
FanControl

Input events

Supervised output devices Firephone
continued Telephone
Visual
Object labels
the TestTrouble event.
Example
ANNUNCIATOR_LED_2 if FLR_2_SPKR goes into a trouble
condition during the test mode.
Example 3-14: Syntax for a speaker in trouble during test mode

[TEST_SPEAKER_TROUBLE]
TESTTROUBLE AUDIBLE 'FLR_2_SPKR' : LED ON LED 'ANNUNCIATOR_LED_2';

Input events
Trouble events
Purpose
Use the Trouble event to trigger the execution of a rule when any
initiating device goes into trouble while the system is in normal
standby operation.
Syntax
Trouble device_type 'object_label' :
– or –
Trouble device_type :
Device types
Table 3-5 identifies valid devices for Trouble events.

Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow
Gatevalve
Power
SupDuct
Supervisory
Tamper
Temperature
DoorFeedback
Emergency
FanFeedback
Monitor
Non-supervised output devices NonSupervisedOutput
NSDamperControl
NSDoorControl
NSFanControl
Relay
RemoteTextMessage

Input events

Supervised Output devices Audible
AudioAmp
CommonAlarmOutput
CommonMonitorOutput
CommonTroubleOutput
DamperControl
DigitalMessage
DoorControl
FanControl
Firephone
Telephone
Visual
Object labels
the Trouble event.
Example
ANNUNCIATOR_LED_12 if SPRKLR_1_TAMP_2 goes into a
trouble condition during normal standby operation.
Example 3-15: Syntax for a tamper switch in a trouble condition

[TAMPER_TROUBLE_RESPONSE]
TROUBLE TAMPER 'SPRKLR_1_TAMP_2' : LED ON LED 'ANNUNCIATOR_LED_12';

Chapter 4
Output commands
Summary
Use this chapter to write output statements in the rules editor.
Content
Activate command • 4.2
Cancel command • 4.3
Close command • 4.4
CommonAlarmOff command • 4.5
CommonAlarmOn command • 4.6
CommonMonitorOff command • 4.7
CommonMonitorOn command • 4.8
CommonSupervisoryOff command • 4.9
CommonTroubleOff command • 4.11
Delay command • 4.13
Disable command • 4.14
Enable command • 4.16
FanOff command • 4.18
FanOn command • 4.19
LEDOff command • 4.21
LEDOn command • 4.22
NSClose command • 4.23
NSCommonAlarmOff command • 4.24
NSCommonAlarmOn command • 4.25
NSCommonMonitorOff command • 4.26
NSCommonMonitorOn command • 4.27
NSCommonSupervisoryOn command • 4.29
Off command • 4.37
OffGuard command • 4.39
On command • 4.40
OnGuard command • 4.42
Open command • 4.43
ReleaseDoor command • 4.44
Restore command • 4.45

Output commands
Activate command
Description
Use this command to execute an action or a sequence.
Syntax
Activate [Action | Sequence] 'rule_label';
– or –
Activate device_type 'object_label';
Device types
Valid devices for the Activate command include:
• Action
• AlarmSilence
• And
• Drill
• Evacuation
• GuardPatrolAlarm
• LampTest
• NetworkClassAFault
• Sequence
• StartAction
• StartSequence
• SysReset
• TimeControl
Object label
The object label specifies the unique label of the device
responding to the Activate command.
Example
Example 4-1 illustrates possible syntax for a rule that will
activate an action labeled STROBE_SEQ during any alarm
event.
Example 4-1: Syntax for activating of a strobe sequence

[GENERAL_ALARM]
ALARM '*' : ACTIVATE ACTION 'STROBE_SEQ';
Related information
You can find information related to this topic in:
• Restore command
• Define event

Output commands
Cancel command
Description
Use this command to stop the execution of a sequence.
Syntax
Cancel Sequence 'rule_label';
– or –
Cancel StartSequence 'MCM_label';
Rule label
The rule label identifies the sequence that responds to the cancel
command.
MCM label
The MCM label specifies the label of the main controller module
that responds to the cancel command. Use MCM1 for standalone
systems.
Example
Example 4-2 illustrates possible syntax for a rule that cancels the
activation of an action labeled STROBES_SEQ when
STROBE_SW1 is active.
Example 4-2: Syntax for canceling a strobe sequence

[CANCEL_TURN_ON_STROBES_SEQ]
ACTIVE SWITCH 'STROBE_SW1' : CANCEL SEQUENCE 'STROBE_SEQ';
Related information
• Activate
• Restore

Output commands
Close command
Description
Use the Close command to deenergize (reset) supervised control
relay modules configured to operate dampers.
Syntax
Close -priority device_type 'object_label';
– or –
Close -priority device_type;
Priority
Priorities are optional. If you plan to use a priority for this
command, see Priorities in Advanced Programming features.
Device type
The only valid device type for the Close command is the
DamperControl.
Object label
responding to the Close command.
Example
During a fire, it may be necessary to close dampers to isolate
smoke or flames. Example 4-3 illustrates possible syntax for a
rule that will close supervised dampers upon the activation of a
switch labeled DAMP_CNTRL_SW1.
Example 4-3: Syntax for closing a DamperControl

[CLOSE_DAMPER]
ACTIVE SWITCH 'DAMP_CNTRL_SW1' : CLOSE DAMPERCONTROL 'DAMPER_RELAY';
Related information
• NSClose command
• NSOpen command
• Open command

Output commands
CommonAlarmOff command
Description
Use the CommonAlarmOff command to turn off (reset) a
supervised output device configured to automatically activate
when the system detects an active alarm point.
Syntax
CommonAlarmOff -priority device_type
'object_label';
– or –
CommonAlarmOff -priority device_type;
Priority
Device type
The only valid device type for the CommonAlarmOff command
is the CommonAlarmOutput.
Object label
responding to the CommonAlarmOff command.
Example
Example 4-4 illustrates possible syntax for a rule that will turn
off any active CommonAlarmOutput upon the activation of a
switch labeled ALRM_SW1.
Example 4-4: Syntax for resetting a CommonAlarmOutput

[TURN_OFF_COMMON_ALARM_OUTPUTS]
ACTIVE SWITCH 'ALRM_SW1': COMMONALARMOFF COMMONALARMOUTPUT '*';
Related information
• CommonAlarmOn command
• NSCommonAlarmOff command
• NSCommonAlarmOn command

Output commands
CommonAlarmOn command
Description
Use the CommonAlarmOn command to turn on (set) a
supervised output device turned off by the CommonAlarmOff
command.
Syntax
CommonAlarmOn -priority device_type
'object_label';
– or –
CommonAlarmOn -priority device_type;
Priority
Device type
The only valid device type for the CommonAlarmOn command
is the CommonAlarmOutput.
Object label
responding to the CommonAlarmOff command.
Example
on any CommonAlarmOutput that was turned off by a
CommonAlarmOff command. CommonAlarmOn is initiated
upon the activation of a switch labeled ALRM_SW2.
Example 4-5: Syntax for setting a CommonAlarmOutput

[TURN_ON_COMMON_ALARM_OUTPUTS]
ACTIVE SWITCH 'ALRM_SW2' : COMMONALARMON COMMONALARMOUTPUT '*';
Related information
• CommonAlarmOff command

Output commands
CommonMonitorOff command
Description
Use the CommonMonitorOff command to turn off (reset) a
when the system detects an active monitor point.
Syntax
CommonMonitorOff -priority device_type
'object_label';
– or –
CommonMonitorOff -priority device_type;
Priority
Device type
The only valid device type for the CommonMonitorOff
command is the CommonMonitorOutput.
Object label
responding to the CommonMonitorOff command.
Example
off any active CommonMonitorOutput upon the activation of a
switch labeled MONTR_SW1.
Example 4-6: Syntax for resetting a CommonMonitorOutput

[TURN_OFF_COMMON_MONITOR_OUTPUTS]
ACTIVE SWITCH 'MONTR_SW1' : COMMONMONITOROFF COMMONMONITOROUTPUT '*';
Related information
• CommonMonitorOn command
• NSCommonMonitorOff command
• NSCommonMonitorOn command

Output commands
CommonMonitorOn command
Description
Use the CommonMonitorOn command to turn on (set) a
supervised output device turned off by the CommonMonitorOff
command.
Syntax
CommonMonitorOn -priority device_type
'object_label';
– or –
CommonMonitorOn -priority device_type;
Priority
Device type
The only valid device type for the CommonMonitorOn
command is the CommonMonitorOutput.
Object label
responding to the CommonMonitorOn command.
Example
on any CommonMonitorOutput that was turned off by a
CommonMonitorOff command. CommonMonitorOn is initiated
upon the activation of a switch labeled MONTR_SW2.
Example 4-7: Syntax for setting a CommonMonitorOutput

[TURN_ON_COMMON_MONITOR_OUTPUTS]
ACTIVE SWITCH 'MONTR_SW2' : COMMONMONITORON COMMONMONITOROUTPUT '*';
Related information
• CommonMonitorOff command

Output commands
CommonSupervisoryOff command
Description
Use the CommonSupervisoryOff command to turn off (reset) a
when the system detects an active supervisory point.
Syntax
CommonSupervisoryOff -priority device_type
'object_label';
– or –
CommonSupervisoryOff -priority device_type;
Priority
Device type
The only valid device type for the CommonSupervisoryOff
command is the CommonSupervisoryOutput.
Object label
responding to the CommonSupervisoryOff command.
Example
off any active CommonSupervisoryOutput upon the activation of
a switch labeled SUPV_SW1.
Example 4-8: Syntax for resetting a CommonSupervisoryOutput

[TURNOFF_COM_SUPV_OUTPUTS]
ACTIVE SWITCH 'SUPV_SW1' : COMMONSUPERVISORYOFF COMMONSUPERVISORYOUTPUT '*';
Related information
• CommonSupervisoryOn command
• NSCommonSupervisoryOff command
• NSCommonSupervisoryOn command

Output commands
CommonSupervisoryOn command
Description
Use the CommonSupervisoryOn command to turn on (set) a
supervised output device turned off by the
CommonSupervisoryOff command.
Syntax
CommonSupervisoryOn -priority device_type
'object_label';
– or –
CommonSupervisoryOn -priority device_type;
Priority
Device type
The only valid device type for the CommonSupervisoryOn
command is the CommonSupervisoryOutput.
Object label
responding to the CommonSupervisoryOn command.
Example
on any CommonSupervisoryOutput that was turned off by a
CommonSupervisoryOff command. CommonSupervisoryOn is
initiated upon the activation of a switch labeled SUPV_SW2.
Example 4-9: Syntax for setting a CommonSupervisoryOutput

[TURNON_COM_SUPV_OUTPUTS]
ACTIVE SWITCH 'SUPV_SW2' : COMMONSUPERVISORYON COMMONSUPERVISORYOUTPUT '*';
Related information
• CommonSupervisoryOff command

Output commands
CommonTroubleOff command
Description
Use the CommonTroubleOff command to turn off (reset) a
when the system detects an active trouble point.
Syntax
CommonTroubleOff -priority device_type
'object_label';
– or –
CommonTroubleOff -priority device_type;
Priority
Device type
The only valid device type for the CommonTroubleOff
command is the CommonTroubleOutput.
Object label
responding to the CommonTroubleOff command.
Example
off any active CommonTroubleOutput upon the activation of a
switch labeled TRBL_SW1.
Example 4-10: Syntax for resetting a CommonTroubleOutput

[TURNOFF_COM_TRBLE_OUTPUTS]
ACTIVE SWITCH 'TRBL_SW1' : COMMONTROUBLEOFF COMMONTROUBLEOUTPUT '*';
Related information
• CommonTroubleOn command
• NSCommonTroubleOff command
• NSCommonTroubleOn command

Output commands
CommonTroubleOn command
Description
Use the CommonTroubleOn command to turn on (set) a
supervised output device turned off by the CommonTroubleOff
command.
Syntax
CommonTroubleOn -priority device_type
'object_label';
– or –
CommonTroubleOn -priority device_type;
Priority
Device type
The only valid device type for the CommonTroubleOn command
is the CommonTroubleOutput.
Object label
responding to the CommonTroubleOn command.
Example
on any CommonTroubleOutput that was turned off by a
CommonTroubleOff command. CommonTroubleOn is initiated
upon the activation of a switch labeled TRBL_SW2.
Example 4-11: Syntax for setting a CommonTroubleOutput

[TURNON_COM_TRBLE_OUTPUTS]
ACTIVE SWITCH 'TRBL_SW2' : COMMONTROUBLEON COMMONTROUBLEOUTPUT '*';
Related information
• CommonTroubleOff command

Output commands
Delay command
Description
Use the Delay command to suspend the execution of a command
for a specified duration.
Syntax
Delay delay_value;
The delay_value can be any duration between 5 and 4095
seconds.
Example
Example 4-12 illustrates possible syntax for a rule that will delay
the activation of visual notification appliances. The delay of
visual NACs on 'MCM_NAC2' lasts for five seconds. The delay
of visual NACs on 'LCX_NAC2' lasts for 10 seconds.
Example 4-12: Syntax for delaying the activation of Visuals

[TURN_ON_STROBES_SEQ]
DEFINE SEQUENCE 'MCM1' : DELAY 5,
ON VISUAL 'MCM_NAC2',
DELAY 10,
ON VISUAL 'LCX_NAC2';
Related information
You can find information related to this topic in the Define event
topic. See Define events in Input events.

Output commands
Disable command
Description
Use the Disable command to inhibit the automatic or manual
activation of an input device, time control, AND group, action,
or sequence.
Syntax
Disable [Action | Sequence] 'rule_label';
– or –
Disable device_type 'object_label';
Device types
Table 4-1 identifies the device types and the specific devices for
which you can use the Disable output statement.

Actions or sequences AlarmSilence
Drill
Evacuation
GuardPatrolAlarm
LampTest
NetworkClassAFault
StartAction
StartSequence
SysReset
Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow
Latching supervisory devices Gatevalve
Power
SupDuct
Supervisory
Tamper
Temperature
DoorFeedback
Emergency
FanFeedback
Monitor

Output commands

Switch devices Switch
UserDefinedSwitch
Telephone Firephone
Telephone
Object label
responding to the Disable command.
Examples
Whenever the fire alarm control panel gives an audible
indication of trouble, it is tempting to silence the buzzer and
ignore the problem. Fire alarm notifications should never be
ignored or silenced. Example 4-13 illustrates possible syntax for
a rule that disables all manual controls.
Example 4-13: Syntax for defining an action that will disable a control switch
[CNTRL_SWITCH_DISABLE_RESPONSE]
DEFINE ACTION 'MCM_SDC_1_01' : DISABLE SWITCH '*_CNTRL_SW*';

activate the rule in Example 4-13. The condition that will disable
all manual controls is a fire alarm.
Example 4-14: Syntax for activating the action that disables the control switch
[DISABLE_MAN_CNTRLS]
ALARM '*' : ACTIVATE ACTION 'CNTRL_SWITCH_DISABLE_RESPONSE';
Related information
You can find information related to this topic in Enable
command.

Output commands
Enable command
Description
Use the Enable command to permit the automatic or manual
activation of an input device, time control, action, or sequence,
inhibited by the Disable command.
Syntax
Enable [Action | Sequence] 'rule_label';
– or –
Enable device_type 'object_label';
Device types
Table 4-2 identifies the device types and the specific devices for
which you can use the Enable output statement.

Actions or sequences AlarmSilence
Drill
Evacuation
GuardPatrolAlarm
LampTest
NetworkClassAFault
StartAction
StartSequence
SysReset
Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow
Latching supervisory devices Gatevalve
Power
SupDuct
Supervisory
Tamper
Temperature
DoorFeedback
Emergency
FanFeedback
Monitor

Output commands

Switch input devices Switch
UserDefinedSwitch
Telephone inputs Firephone
Telephone
Object label
responding to the Enable command.
Example
During a fire, it may become necessary to open dampers
manually. Example 4-15 illustrates possible syntax for a rule that
will enable the manual damper controls during a fire alarm.
Example 4-15: Syntax for enabling a damper control switch

[ENABLE_MAN_DAMPER_CNTRL]
ALARM SMOKE 'SMOKE*' : ENABLE SWITCH 'DAMPER_CNTRL_SW*';
Related information
You can find information related to this topic in Disable
command.

Output commands
FanOff command
Description
Use the FanOff command to deenergize (reset) supervised
control relay modules configured to operate fans.
Syntax
FanOff -priority device_type 'object_label';
– or –
FanOff -priority device_type;
Priority
Device type
The only valid device type for the FanOff command is the
FanControl.
Object label
responding to the FanOff command.
Example
During a fire, it may be necessary to shut off fans in various
areas of a building to prevent the spread of smoke and flames.
Example 4-16 illustrates possible syntax for a rule that will shut
off the fans upon the activation of a switch labeled
FAN_CNTRL_SW1.
Example 4-16: Syntax for resetting a FanControl

[FAN_SHUTDOWN]
ACTIVE SWITCH 'FAN_CNTRL_SW1' : FANOFF FANCONTROL 'FAN_RELAY';
Related information
• FanOn command
• NSFanOff command
• NSFanOn command

Output commands
FanOn command
Description
Use the FanOn command to energize (set) supervised control
relay modules configured to operate fans.
Syntax
FanOn -priority device_type 'object_label';
– or –
FanOn -priority device_type;
Priority
Device type
The only valid device type for the FanOn command is the
FanControl.
Object label
responding to the Restore command.
Example
During a fire, it may be necessary to turn fans on that will clear
smoke from various parts of a building. Example 4-17 illustrates
possible syntax for a rule that will turn a fan on upon the
activation of a switch labeled FAN_CNTRL_SW2.
Example 4-17: Syntax for setting a FanControl

[FAN_POWERUP]
ACTIVE SWITCH 'FAN_CNTRL_SW2' : FANON FANCONTROL 'FAN_RELAY';
Related information
• FanOff command
• NSFanOn command

Output commands
HoldDoor command
Description
Use the HoldDoor command to energize (set) supervised control
relay modules controlling automatic door holders.
Syntax
HoldDoor -priority device_type 'object_label';
– or –
HoldDoor -priority device_type;
Priority
Device type
The only valid device type for the HoldDoor command is the
DoorControl.
Object label
Example
During a fire, it may become necessary to seal off sections of a
building by keeping doors shut. Example 4-18 illustrates
possible syntax for a rule that will keep a door shut upon the
activation of a switch labeled DOOR_CNTRL_SW1.
Example 4-18: Syntax for holding a DoorControl in the closed position

[DOORS_CLOSED]
ACTIVE SWITCH 'DOOR_CNTRL_SW1' : HOLDDOOR DOORCONTROL 'DOOR_RELAY';
Related information
• ReleaseDoor command
• NSHoldDoor command
• NSReleaseDoor command

Output commands
LEDOff command
Description
Use the LEDOff command to turn off (reset) an annunciator
panel light emitting diode.
Syntax
LEDOff -priority device_type 'object_label';
– or –
LEDOff -priority device_type;
Priority
Device types
The only valid device types the LEDOff command are LEDs and
the UserDefinedLED.
Object label
Example
An LED may be programmed to turn on in the event of an
initiated firephone call. It is also advisable to program a visual
confirmation when a firefighter makes a connection at the
receiving jack. Example 4-19 illustrates possible syntax for a
rule that will turn off an LED when a firefighter makes a
connection to the associated firephone jack.
Example 4-19: Syntax for confirming a firephone connection

CONFIRMATION FIREPHONE 'LVL<N:3-5>_PHONEJACK' : LEDOFF LED 'LVL<N>_PHONECALL';
Related information
You can find information related to this topic in LEDOn
command.

Output commands
LEDOn command
Description
Use the LEDOn command to turn on (set) an annunciator panel
light emitting diode.
Syntax
LEDOn -priority device_type 'object_label';
– or –
LEDOn -priority device_type;
Priority
Device types
The only valid device types for the LEDOn command are LEDs
and the UserDefinedLED.
Object label
Example
on an LED when a firefighter makes a connection to its
associated firephone jack.
Example 4-20: Syntax for confirming a firephone connection

CONFIRMATION FIREPHONE 'LVL<N:3-5>_PHONEJACK' : LEDON LED 'LVL<N>_PHONECALL';
Related information
You can find information related to this topic in LEDOff
command.

Output commands
NSClose command
Description
Use the NSClose command to deenergize (reset) nonsupervised
control relay modules configured to operate dampers.
Syntax
NSClose -priority device_type 'object_label';
– or –
NSClose -priority device_type;
Priority
Device type
The only valid device type for the NSClose command is the
NSDamperControl.
Object label
Example
During a fire, it may be necessary to close dampers to isolate
smoke or flames. Example 4-21 illustrates possible syntax for a
rule that will close nonsupervised dampers upon the activation of
a switch labeled NSDAMP_CRNTL_SW1.
Example 4-21: Syntax for closing an NSDamperControl

[CLOSE_DAMPER]
ACTIVE SWITCH 'NSDAMP_CRNTL_SW1' : NSCLOSE NSDAMPERCONTROL 'DAMPER_RELAY';
Related information
• NSOpen command
• Open command

Output commands
NSCommonAlarmOff command
Description
Use the NSCommonAlarmOff command to turn off (reset) a
nonsupervised output device configured to activate automatically
when the system detects an active alarm point.
Syntax
NSCommonAlarmOff -priority device_type
'object_label';
– or –
NSCommonAlarmOff -priority device_type;
Priority
Device type
The only valid device type for the NSCommonAlarmOff
command is the NSCommonAlarmOutput.
Object label
Example
off any active NSCommonAlarmOutput upon the activation of a
switch labeled NSALRM_SW1.
Example 4-22: Syntax for resetting an NSCommonAlarmOutput

[TURN_OFF_NSCOMMON_ALARM_OUTPUTS]
ACTIVE SWITCH 'NSALRM_SW1' : NSCOMMONALARMOFF NSCOMMONALARMOUTPUT '*';
Related information

Output commands
NSCommonAlarmOn command
Description
Use the NSCommonAlarmOn command to turn on (set) a
nonsupervised output device turned off by the
NSCommonAlarmOff command.
Syntax
NSCommonAlarmOn -priority device_type
'object_label';
– or –
NSCommonAlarmOn -priority device_type;
Priority
Device type
The only valid device type for the NSCommonAlarmOn
command is the NSCommonAlarmOutput.
Object label
Example
on any NSCommonAlarmOutput that was turned off by a
NSCommonAlarmOff command. NSCommonAlarmOn is
initiated upon the activation of a switch labeled NSALRM_SW2.
Example 4-23: Syntax for setting an NSCommonAlarmOutput

[TURN_ON_NSCOMMON_ALARM_OUTPUTS]
ACTIVE SWITCH 'NSALRM_SW2' : NSCOMMONALARMON NSCOMMONALARMOUTPUT '*';
Related information

Output commands
NSCommonMonitorOff command
Description
Use the NSCommonMonitorOff command to turn off (reset) a
nonsupervised output device configured to automatically activate
when any active monitor point is detected by the system.
Syntax
NSCommonMonitorOff -priority device_type
'object_label';
– or –
NSCommonMonitorOff -priority device_type;
Priority
Device type
The only valid device type for the NSCommonMonitorOff
command is the NSCommonMonitorOutput.
Object label
Example
off any active NSCommonMonitorOutput upon the activation of
a switch labeled NSMONTR_SW1.
Example 4-24: Syntax for resetting an NSCommonMonitorOutput

[TURNOFF_NSCOM_MONTR_OUTPUTS]
ACTIVE SWITCH 'NSMONTR_SW1' : NSCOMMONMONITOROFF NSCOMMONMONITOROUTPUT '*';
Related information

Output commands
NSCommonMonitorOn command
Description
Use the NSCommonMonitorOn command to turn on (set) a
NSCommonMonitorOff command.
Syntax
NSCommonMonitorOn -priority device_type
'object_label';
– or –
NSCommonMonitorOn -priority device_type;
Priority
Device type
The only valid device type for the NSCommonMonitorOn
command is the NSCommonMonitorOutput.
Object label
Example
on any NSCommonMonitorOutput that was turned off by a
NSCommonMonitorOff command. NSCommonMonitorOn is
initiated upon the activation of a switch labeled
NSMONTR_SW2.
Example 4-25: Syntax for setting an NSCommonMonitorOutput

[TURNON_NSCOM_MONTR_OUTPUTS]
ACTIVE SWITCH 'NSMONTR_SW2' : NSCOMMONMONITORON NSCOMMONMONITOROUTPUT '*';
Related information

Output commands
NSCommonSupervisoryOff command
Description
Use the NSCommonSupervisoryOff command to turn off (reset)
a nonsupervised output device configured to automatically
activate when any active supervisory point is detected by the
system.
Syntax
NSCommonSupervisoryOff -priority device_type
'object_label';
– or –
NSCommonSupervisoryOff -priority device_type;
Priority
Device type
The only valid device type the NSCommonSupervisoryOff
command is the NSCommonSupervisoryOutput.
Object label
Example
off any active NSCommonSupervisoryOutput upon the
activation of a switch labeled NSSUPV_SW1.
Example 4-26: Syntax for resetting an NSCommonSupervisoryOutput

[TURNOFF_NSCOMSUPVOUT]
ACTIVE SWITCH 'NSSUPV_SW1' : NSCOMMONSUPERVISORYOFF '*';
Note: This rule will compile even if the command does not specify the device type. Commands
with multiple valid device types require device-type specification.
Related information

Output commands
NSCommonSupervisoryOn command
Description
Use the NSCommonSupervisoryOn command to turn on (set) a
NSCommonSupervisoryOff command.
Syntax
NSCommonSupervisoryOn -priority device_type
'object_label';
– or –
NSCommonSupervisoryOn -priority device_type;
Priority
Device type
The only valid device type for the NSCommonSupervisoryOn
command is the NSCommonSupervisoryOutput.
Object label
Example
on any NSCommonSupervisoryOutput that was turned off by a
NSCommonSupervisoryOff command.
NSCommonSupervisoryOn is initiated upon the activation of a
switch labeled NSSUPV_SW2.
Example 4-27: Syntax for setting an NSCommonSupervisoryOutput

[TURNON_NSCOMSUPVOUT]
ACTIVE SWITCH 'NSSUPV_SW2' : NSCOMMONSUPERVISORYON '*';
Note: This rule will compile even if the command does not specify the device type. Commands
with multiple valid device types require device-type specification.
Related information

Output commands
NSCommonTroubleOff command
Description
Use the NSCommonTroubleOff command to turn off (reset) a
nonsupervised output device configured to automatically activate
when the system detects any active trouble point.
Syntax
NSCommonTroubleOff -priority device_type
'object_label';
– or –
NSCommonTroubleOff -priority device_type;
Priority
Device type
The only valid device type for the NSCommonTroubleOff
command is the NSCommonTroubleOutput.
Object label
Example
Example 4-28 illustrates possible syntax for a rule turn off any
active NSCommonTroubleOutput upon the activation of a switch
labeled NSTRBL_SW1.
Example 4-28: Syntax for resetting an NSCommonTroubleOutput

[TURNOFF_NSCOMTRBLOUT]
ACTIVE SWITCH 'NSTRBL_SW1' : NSCOMMONTROUBLEOFF NSCOMMONTROUBLEOUTPUT '*';
Related information

Output commands
NSCommonTroubleOn command
Description
Use the NSCommonTroubleOn command to turn on (set) a
NSCommonTroubleOff command.
Syntax
NSCommonTroubleOn -priority device_type
'object_label';
– or –
NSCommonTroubleOn -priority device_type;
Priority
Device type
The only valid device type for the NSCommonTroubleOn
command is the NSCommonTroubleOutput.
Object label
Example
Example 4-29 illustrates possible syntax for a rule turn on any
NSCommonTroubleOutput that was turned off by a
NSCommonTroubleOff command. NSCommonTroubleOn is
initiated upon the activation of a switch labeled NSTRBL_SW2.
Example 4-29: Syntax for setting an NSCommonTroubleOutput

[TURNON_NSCOMTRBLOUT]
ACTIVE SWITCH 'NSTRBL_SW2' : NSCOMMONTROUBLEON NSCOMMONTROUBLEOUTPUT '*';
Related information

Output commands
NSFanOff command
Description
Use the NSFanOff command to deenergize (reset) nonsupervised
Syntax
NSFanOff -priority device_type 'object_label';
– or –
NSFanOff -priority device_type;
Priority
Device type
The only valid device type for the NSFanOff command is the
NSFanControl.
Object label
Example
During a fire, it may be necessary to shut off fans in various
areas of a building to prevent the spread of smoke and flames.
Example 4-30 illustrates possible syntax for a rule will shut off
the nonsupervised fans upon the activation of a switch labeled
NSFAN_CRNTL_SW1.
Example 4-30: Syntax for resetting an NSFanControl

[FAN_SHUTDOWN]
ACTIVE SWITCH 'NSFAN_CRNTL_SW1' : NSFANOFF NSFANCONTROL 'FAN_RELAY';
Related information
• FanOff command
• FanOn command
• NSFanOn command

Output commands
NSFanOn command
Description
Use the NSFanOn command to energize (set) nonsupervised
Syntax
NSFanOn -priority device_type 'object_label';
– or –
NSFanOn -priority device_type;
Priority
Device type
The only valid device type for the NSFanOn command is the
NSFanControl.
Object label
Example
During a fire, it may be necessary to turn fans on that will clear
smoke from various parts of a building. Example 4-31 illustrates
possible syntax for a rule that will turn a supervised fan on upon
the activation of a switch labeled NSFAN_CRNTL_SW2.
Example 4-31: Syntax for turning on an NSFanControl

[FAN_POWERUP]
ACTIVE SWITCH 'NSFAN_CRNTL_SW2' : NSFANON NSFANCONTROL 'FAN_RELAY';
Related information
• FanOff command
• FanOn command

Output commands
NSHoldDoor command
Description
Use the NSHoldDoor command to energize (set) supervised
control relay modules configured to operate automatic door
holders.
Syntax
NSHoldDoor -priority device_type
'object_label';
– or –
NSHoldDoor -priority device_type;
Priority
Device type
The only valid device type for the NSHoldDoor command is the
NSDoorControl.
Object label
Example
During a fire, it may become necessary to seal off sections of a
building by keeping doors shut. Example 4-32 illustrates
possible syntax for a rule that will keep a door shut upon the
activation of a switch labeled NSDOOR_CRNTL_SW1.
Example 4-32: Syntax for holding an NSDoorControl in the closed position

[DOORS_CLOSED]
ACTIVE SWITCH 'NSDOOR_CRNTL_SW1' : NSHOLDDOOR NSDOORCONTROL 'DOOR_RELAY';
Related information
• HoldDoor command

Output commands
NSOpen command
Description
Use the NSOpen command to energize (set) nonsupervised
control relay modules configured to operate dampers.
Syntax
NSOpen -priority device_type 'object_label';
– or –
NSOpen -priority device_type;
Priority
Device type
The only valid device type for the NSOpen command is the
NSDamperControl.
Object label
Example
During a fire, it may become necessary to open dampers to route
smoke out of the building. Example 4-33 illustrates possible
syntax for a rule that will open the nonsupervised dampers upon
the activation of a switch labeled NSDAMP_CRNTL_SW2.
Example 4-33: Syntax for opening an NSDamperControl

[OPEN_DAMPER]
ACTIVE SWITCH 'NSDAMP_CRNTL_SW2' : NSOPEN NSDAMPERCONTROL 'DAMPER_RELAY';
Related information
• Close command
• Open command
• NSClose command

Output commands
NSReleaseDoor command
Description
Use the NSReleaseDoor command to deenergize (reset)
nonsupervised control relay modules configured to operate
automatic door holders.
Syntax
NSReleaseDoor -priority device_type
'object_label';
– or –
NSReleaseDoor -priority device_type;
Priority
Device type
The only valid device type for the NSReleaseDoor command is
the NSDoorControl.
Object label
responding to the NSReleaseDoor command.
Example
Doors throughout the building may be programmed to shut in the
event of a fire. In the case of an evacuation, however, it may
become necessary to open the doors. Example 4-34 illustrates
possible syntax for a rule that will release an associated,
nonsupervised door upon the activation of a switch labeled
NSDOOR_CRNTL_SW2.
Example 4-34: Syntax for releasing an NSDoorControl

[DOORS_OPEN]
ACTIVE SWITCH 'NSDOOR_CRNTL_SW2' : NSRELEASEDOOR NSDOORCONTROL 'DOOR_RELAY';
Related information

Output commands
Off command
Description
Use the Off command to deactivate a point in the system.
Syntax
Off -priority device_type 'object_label';
– or –
Off -priority device_type;
Priority
Device types
Valid devices for the Off command include:
• Audible
• DamperControl
• DoorControl
• FanControl
• Firephone
• LED
• NSDamperControl
• NSDoorControl
• NSFanControl
• NonSupervisedOutput
• Relay
• RemoteTextMessage
• Telephone
• UserDefinedLED
• Visual
Object label
responding to the Off command.
Example
After the evacuation of a building and the containment of a fire,
it will be necessary to investigate the cause of the fire alarm.
During the investigation, firefighters will want the horns to be
silenced. Example 4-35 illustrates possible syntax for a rule that
will:

Output commands
• Turn off LVL1_HORN when HORN_SW1 is pressed

Example 4-35: Syntax for resetting Audible devices

[DEACTIVATE_AUDIBLES]
ACTIVE SWITCH 'HORN_SW<N:1-5>' : OFF AUDIBLE 'LVL<N>_HORN' ;
Related information
You can find information related to this topic in On command.

Output commands
OffGuard command
Description
Use the OffGuard command to deactivate a guard patrol route.
Syntax
OffGuard device_type 'group_label' route_id;
Device type
The device type identifies the class of the device named by the
object label. The only device type for which you can use the
OffGuard command is the GuardPatrol.
Group label
The group label in the Object Configuration tables specifies
which guard patrol group responds to the command.
Route ID
The route ID specifies the route sequence number of the targeted
guard patrol group.
Example
Guard patrols require personnel to check in at designated points
in a timed sequence. Any deviations in time or sequence will set
off a programmed GuardPatrolAlarm. In some cases, it may be
necessary to deactivate a guard patrol route. Example 4-36
illustrates possible syntax for a rule that will turn off a guard
patrol route upon the activation of a switch labeled
GUARD_PRTL_SW1.
Note: The guard patrol group and the designated route are
defined separately. See the Guard Patrol Group tab in the Object
Configuration.
Example 4-36: Syntax for turning off a guard patrol route

[DEACTIVATE_GPG1_ROUTE_1]
ACTIVE SWITCH 'GUARD_PRTL_SW1' : OFFGUARD GUARDPATROL 'GUARD_PATROL_GROUP1' 1;
Related information
• OnGuard command
• Define event (GuardPatrolAlarm)

Output commands
On command
Description
Use the On command to activate a point in the system.
Syntax
On -priority device_type 'object_label';
– or –
On -priority device_type;
Priority
Device types
Valid devices for the On command include:
• Audible
• DamperControl
• DoorControl
• FanControl
• Firephone
• LED
• NSDamperControl
• NSDoorControl
• NSFanControl
• NonSupervisedOutput
• Relay
• RemoteTextMessage
• Telephone
• UserDefinedLED
• Visual
Object label
responding to the On command.
Example
During a fire, it may be necessary to evacuate floors selectively.
For example, if the fire is on the fourth floor it will be necessary
to evacuate floors 3, 4, and 5 immediately. Occupants on floors 1
and 2 should remain where they are to allow occupants of the

Output commands
fire floors to evacuate. Example 4-37 illustrates possible syntax

for a rule that will allow a firefighter to:
• Sound LVL1_HORN by pressing HORN_SW6
Example 4-37: Syntax for turning on audible devices

[ACTIVATE_AUDIBLES]
ACTIVE SWITCH 'HORN_SW<N:6-10>' : ON AUDIBLE 'LVL<N-5>_HORN';
Related information
You can find information related to this topic in Off command.

Output commands
OnGuard command
Description
Use the OnGuard command to activate a guard patrol route
deactivated by the OffGuard command.
Syntax
OnGuard device_type 'group_label' route_id;
Device type
The device type identifies the class of the device named by the
object label. The only device type for which you can use the
OnGuard command is the GuardPatrol.
Group label
The group label in the Object Configuration tables specifies
which guard patrol group responds to the command.
Route ID
The route ID specifies the route sequence number of the targeted
guard patrol group.
Example
Guard patrols require personnel to check in at designated points
in a timed sequence. Any deviations in time or sequence will set
off a programmed GuardPatrolAlarm. Example 4-38 illustrates
possible syntax for a rule that will activate a guard patrol upon
the activation of a switch labeled GUARD_PRTL_SW2.
Note: The guard patrol group and the designated route are
defined separately. See the Guard Patrol Group tab in the Object
Configuration.
Example 4-38: Syntax for turning on a guard patrol route

[ACTIVATE_GPG1_ROUTE_1]
ACTIVE SWITCH 'GUARD_PRTL_SW2' : ONGUARD GUARDPATROL 'GUARD_PATROL_GROUP1' 1;
Related information
• OffGuard command
• Define event (GuardPatrolAlarm)

Output commands
Open command
Description
Use the Open command to energize (set) supervised control
relay modules configured to operate dampers.
Syntax
Open -priority device_type 'object_label';
– or –
Open -priority device_type;
Priority
Device type
The only valid device type for the Open command is the
DamperControl.
Object label
responding to the Open command.
Example
During a fire, it may become necessary to open dampers to route
smoke out of the building. Example 4-39 illustrates possible
syntax for a rule that will open the dampers upon the activation
of a switch labeled DAMP_CNTRL_SW2.
Example 4-39: Syntax for opening a DamperControl

[OPEN_DAMPER]
ACTIVE SWITCH 'DAMP_CNTRL_SW2' : OPEN DAMPERCONTROL 'DAMPER_RELAY';
Related information
• NSClose command
• NSOpen command
• Close command

Output commands
ReleaseDoor command
Description
Use the ReleaseDoor command to deenergize (reset) supervised
control relay modules configured to operate automatic door
holders.
Syntax
ReleaseDoor -priority device_type
'object_label';
– or –
ReleaseDoor -priority device_type;
Priority
Device type
The only valid device type for the ReleaseDoor command is the
DoorControl.
Object label
responding to the ReleaseDoor command.
Example
Doors throughout may be programmed to shut in the event of a
fire. In the case of an evacuation, however, it may become
necessary to open the doors. Example 4-40 illustrates possible
syntax for a rule that will release an associated door upon the
activation of a switch labeled DOOR_CNTRL_SW2.
Example 4-40: Syntax for releasing a DoorControl

[DOORS_OPEN]
ACTIVE SWITCH 'DOOR_CNTRL_SW2' : RELEASEDOOR DOORCONTROL 'DOOR_RELAY' ;
Related information

Output commands
Restore command
Description
Use the Restore command to return a time control, And group,
action, or drill to its previous state before being activated by the
Activate command.
Syntax
Restore Action 'rule_label';
– or –
Restore device_type 'object_label';
Device types
Valid devices for the Restore command include:
• Action
• AlarmSilence
• And
• Drill
• Evacuation
• GuardPatrolAlarm
• StartAction
• SysReset
• TimeControl
Object label
Example
restore the sequence labeled TURN_ON_STROBES_SEQ upon
the activation of the switch labeled STROBE_SW2.
Example 4-41: Syntax for restoring an action

[RESTORE_TURNON_STROBES_SEQ]
ACTIVE SWITCH 'STROBE_SW2' : RESTORE ACTION 'TURN_ON_STROBES_SEQ';
Related information
• Activate command
• Cancel command

Output commands

Appendix A
Quick reference
Summary
The Systems Definition Utility (SDU) supports numerous types
of devices. The SDU also has a wide array of events and
commands. Use the tables in the Quick reference to speed up
your search for the appropriate devices to use with events and
commands.
Content
Event specification summaries • A.2
Events listed by device • A.6
Command specification summaries • A.10
Commands listed by device • A.17
EST2 System Programming Manual A.1

Quick reference
Event specification summaries

While the system is in standby mode, the panel controller waits
for inputs from the system components or from an operator.
These inputs are classified as events and are summarized in
Table A-1. The event_type parameter is used in a rule to specify
the type of input required for the rule to be executed.
For example, the rule below was created to capture an elevator in
the event a smoke detector goes into alarm. The input event, in
this case, is ALARM.
[ElevatorCapture]
ALARM SMOKE 'BLD2_ELOBBY*':
ON RELAY 'ELEVRELAY';
As the rule above is written, any detector with
“BLD2_ELOBBY” as the first 11 characters of its label will
activate the elevator capture relay (labeled ELEVRELAY) when
the detector goes into alarm.
Table A-1: Event specification summaries

For this input specification… Use this event type… With this device type…
Alarm initiating device goes into Active, Alarm Alarm
alarm indicating the presence of Duct
a fire Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow
Latching or non-latching Active AuxPowerSupply
supervisory device goes active Gatevalve
indicating a condition that would Power
prevent normal system SprinklerSupervisory
operation SupDuct
Supervisory
Tamper
Temperature
Non-latching monitor device Active DamperFeedback
goes active DoorFeedback
Emergency
FanFeedback
Monitor
Local or remote panel switch is Active Switch
pressed UserDefinedSwitch
Firefighter telephone is plugged CallIn Firephone
into a call-in jack Telephone
A.2 EST2 System Programming Manual

Quick reference

Supervised output device Confirmation Audible
activated in response to a AudioAmp
system command CommonAlarmOutput
CommonMonitorOutput
CommonTroubleOutput
DamperControl
DigitalMessage
DoorControl
FanControl
Firephone
Telephone
Visual
Alarm initiating device goes into TestActive Alarm
alarm while in system test mode Duct
Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow
Latching supervisory device TestActive Gatevalve
goes active while in system test Power
mode SprinklerSupervisory
SupDuct
Supervisory
Tamper
Temperature
Non-latching monitor device TestActive DamperFeedback
goes active while in system test DoorFeedback
mode Emergency
FanFeedback
Monitor
Alarm initiating device goes into TestTrouble Alarm
trouble while in system test Duct
mode Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow

Quick reference

Latching supervisory device TestTrouble Gatevalve
goes into trouble while in Power
system test mode SprinklerSupervisory
SupDuct
Supervisory
Tamper
Temperature
Non-latching monitor device TestTrouble DamperFeedback
goes into trouble while in DoorFeedback
system test mode Emergency
FanFeedback
Monitor
Supervised output device goes TestTrouble Audible
into trouble while in system test AudioAmp
mode CommonAlarmOutput
CommonMonitorOutput
CommonTroubleOutput
DamperControl
DoorControl
FanControl
Firephone
Telephone
Visual
Alarm initiating device goes into Trouble Alarm
trouble Duct
Heat
Pull
Smoke
SmokeVfy
StageOne
Waterflow
Latching supervisory device Trouble Gatevalve
goes into trouble Power
SupDuct
Supervisory
Tamper
Temperature
Non-latching monitor device Trouble DamperFeedback
goes into trouble DoorFeedback
Emergency
FanFeedback
Monitor

Quick reference

Non-supervised output device Trouble NonSupervisedOutput
goes into trouble NSDamperControl
NSDoorControl
NSFanControl
Relay
RemoteTextMessage
Supervised output device goes Trouble Audible
into trouble AudioAmp
CommonAlarmOutput
CommonMonitorOutput
CommonTroubleOutput
DamperControl
DoorControl
FanControl
Firephone
Telephone
Visual

Quick reference
Events listed by device

Table A-2 provides a quick reference of the valid events for each
device type.
Table A-2: Valid events by device

Device type Event(s)
Action (user-programmed) Define
AlarmSilence (Action 9004) Define
AND Define
Audible Confirmation
TestTrouble
Trouble
AudioAmp Confirmation
TestTrouble
Trouble
AuxPowerSupply Active
CommonAlarmOutput Confirmation
TestTrouble
Trouble
CommonMonitorOutput Confirmation
TestTrouble
Trouble
CommonSupervisoryOutput Confirmation
TestTrouble
Trouble
CommonTroubleOutput Confirmation
TestTrouble
Trouble
DamperControl Confirmation
TestTrouble
Trouble
DamperFeedback Active
TestActive
TestTrouble
Trouble
DoorControl Confirmation
TestTrouble
Trouble
DoorFeedback Active
TestActive
TestTrouble
Trouble
DigitalMessage Confirmation

Quick reference

Drill (Action 9003) Define
Duct Active
Alarm
TestActive
TestTrouble
Trouble
Emergency Active
TestActive
TestTrouble
Trouble
FanControl Confirmation
TestTrouble
Trouble
FanFeedback Active
TestActive
TestTrouble
Trouble
Firephone CallIn
Confirmation
TestTrouble
Trouble
Gatevalve Active
TestActive
TestTrouble
Trouble
GuardPatrol (Action 9000) Define
GuardPatrolAlarm Define
Heat Active
Alarm
TestActive
TestTrouble
Trouble
LampTest Define
Monitor Active
TestActive
TestTrouble
Trouble
NetworkClassAFault Define
NonSupervisedOutput Trouble
NSDamperControl Trouble
NSDoorControl Trouble

Quick reference

NSFanControl Trouble
Power Active
TestActive
TestTrouble
Trouble
Pull Active
Alarm
TestActive
TestTrouble
Trouble
Relay Trouble
RemoteTextMessage Trouble
Sequence Define
Smoke Active
Alarm
TestActive
TestTrouble
Trouble
SmokeVfy Active
Alarm
TestActive
TestTrouble
Trouble
SprinklerSupervisory Active
TestActive
TestTrouble
Trouble
StageOne Active
Alarm
TestActive
TestTrouble
Trouble
StartAction Define
StartSequence Define
SupDuct Active
TestActive
TestTrouble
Trouble
Supervisory Active
TestActive
TestTrouble
Trouble

Quick reference

Switch Active
See also UserDefinedSwitch
SysReset Define
Tamper Active
TestActive
TestTrouble
Trouble
Telephone CallIn
Confirmation
TestTrouble
Trouble
Temperature Active
TestActive
TestTrouble
Trouble
TimeControl Define
UserDefinedSwitch Active
Visual Confirmation
TestTrouble
Trouble
Waterflow Active
Alarm
TestActive
TestTrouble
Trouble

Quick reference
Command specification summaries

The output command parameter specifies the required final state
of the targeted device. Output commands are summarized in
Table A-3.
In our example, it has been assumed that the elevator capture
relay was to be turned ON when the smoke detectors went into
alarm. When writing a rule, the output command must be
specified.
The rule used in the elevator capture example includes the “ON”
output state:
[ElevatorCapture]
ON RELAY 'ELEVRELAY';
As the rule above is now written, any smoke detector with the
label modifier “BLD2_ELOBBY” at the beginning of its label
will turn ON the elevator capture relay (labeled ELEVRELAY)
when it goes into alarm.
Multiple output commands may be placed on the right side of a
rule using a comma (,) as a divider. In our elevator capture
example, the requirements have changed to require the activation
of an elevator capture strobe in addition to activating the elevator
capture relay.
Rewriting the rule used in the elevator capture example to
include two output commands:
[ElevatorCapture]
ON RELAY 'ELEVRELAY',
ON RELAY 'ELEVSTROBE';
Note: Up to 32 commands may be used in a single rule.

Quick reference
Table A-3: Command Summary

For this output specification… Use this command… With this device type…
Start the execution of an action Activate Action
or sequence AlarmSilence
And
Drill
Evacuation
GuardPatrolAlarm
LampTest
NetworkClassAFault
Sequence
StartAction
StartSequence
SysReset
TimeControl
Stop the execution of a Cancel Sequence
sequence StartSequence
Turn off a supervised common CommonAlarmOff CommonAlarmOutput
alarm output device
Turn on a supervised common CommonAlarmOn CommonAlarmOutput
alarm output device
Turn off a supervised common CommonMonitorOff CommonMonitorOutput
monitor output device
Turn on a supervised common CommonMonitorOn CommonMonitorOutput
monitor output device
Turn off a supervised common CommonSupervisoryOff CommonSupervisoryOutput
supervisory output device
Turn on a supervised common CommonSupervisoryOn CommonSupervisoryOutput
supervisory output device
Turn off a common trouble CommonTroubleOff CommonTroubleOutput
output device
Turn on a common trouble CommonTroubleOn CommonTroubleOutput
output device
Deenergize a damper control Close DamperControl
device
Energize a damper control Open DamperControl
device
Delay the execution of a Delay none
command in a rule

Quick reference

Inhibit the automatic or manual Disable Action
control of a device Alarm
AlarmSilence
And
DamperFeedback
DoorFeedback
Drill
Duct
Emergency
Evacuation
FanFeedback
Firephone
Gatevalve
GuardPatrolAlarm
Heat
LampTest
Monitor
NetworkClassAFault
Power
Pull
Sequence
Smoke
SmokeVfy
StageOne
StartAction
StartSequence
SupDuct
Supervisory
Switch
SysReset
Tamper
Telephone
Temperature
TimeControl
UserDefinedSwitch
Waterflow

Quick reference

Allow the automatic or manual Enable Action
control of a device Alarm
AlarmSilence
And
DamperFeedback
DoorFeedback
Drill
Duct
Emergency
Evacuation
FanFeedback
Firephone
Gatevalve
GuardPatrolAlarm
Heat
LampTest
Monitor
NetworkClassAFault
Power
Pull
Sequence
Smoke
SmokeVfy
StageOne
StartAction
StartSequence
SupDuct
Supervisory
Switch
SysReset
Tamper
Telephone
Temperature
TimeControl
UserDefinedSwitch
Waterflow
Deenergize a supervised fan FanOff FanControl
control device
Energize a supervised fan FanOn FanControl
control device
Energize a supervised door HoldDoor DoorControl
control device
Denergize a supervised door ReleaseDoor DoorControl
control device
Turn LED off LEDOff LED
UserDefinedLED

Quick reference

Turn LED on LEDOn LED
UserDefinedLED
Energize a non-supervised NSClose NSDamperControl
damper control device
Deenergize a non-supervised NSOpen NSDamperControl
damper control device
Turn off a non-supervised NSCommonAlarmOff NSCommonAlarmOutput
common alarm output device
Turn on a non-supervised NSCommonAlarmOn NSCommonAlarmOutput
common alarm output device
Turn off a non-supervised NSCommonMonitorOff NSCommonMonitorOutput
common monitor output device
Turn on a non-supervised NSCommonMonitorOn NSCommonMonitorOutput
common monitor output device
Turn off a non-supervised NSCommonSupervisoryOff NSCommonSupervisoryOutput
common supervisory output
device
Turn on a non-supervised NSCommonSupervisoryOn NSCommonSupervisoryOutput
common supervisory output
device
Turn off a non-supervised NSCommonTroubleOff NSCommonTroubleOutput
common trouble output device
Turn on a non-supervised NSCommonTroubleOn NSCommonTroubleOutput
common trouble output device
Deenergize a non-supervised fan NSFanOff NSFanControl
control device
Energize a non-supervised fan NSFanOn NSFanControl
control device
Energize a non-supervised door NSHoldDoor NSDoorControl
control device
Deenergize a non-supervised NSReleaseDoor NSDoorControl
door control device
Deactivate a guard patrol OffGuard GuardPatrol
Activate a guard patrol OnGuard GuardPatrol

Quick reference

Deactivate an output device Off Audible
CommonAlarmOutput
CommonMonitorOutput
CommonTroubleOutput
DamperControl
DoorControl
FanControl
Firephone
LED
NSDamperControl
NSDoorControl
NSFanControl
NonSupervisedOutput
Relay
RemoteTextMessage
Telephone
UserDefinedLED
Visual
Activate a device On Audible
CommonAlarmOutput
CommonMonitorOutput
CommonTroubleOutput
DamperControl
DoorControl
FanControl
Firephone
LED
NSDamperControl
NSDoorControl
NSFanControl
NonSupervisedOutput
Relay
RemoteTextMessage
Telephone
UserDefinedLED
Visual

Quick reference

Returns device to state before Restore Action
changed by the execution of an AlarmSilence
action of sequence And
Drill
Evacuation
GuardPatrolAlarm
LampTest
NetworkClassAFault
StartAction
SysReset
TimeControl

Quick reference
Commands listed by device

Table A-4 provides a quick reference of the valid commands for
each device type.
Table A-4: Valid commands by device type

Device type Command(s)
Action (user-programmed) Activate
Disable
Enable
Restore
AlarmSilence (Action 9004) Activate
Disable
Enable
Restore
AND Activate
Disable
Enable
Restore
Audible Off
On
CommonAlarmOutput CommonAlarmOff
CommonAlarmOn
Off
On
CommonMonitorOutput CommonMonitorOff
CommonMonitorOn
Off
On
CommonSupervisoryOutput CommonSupervisoryOff
CommonSupervisoryOn
Off
On
CommonTroubleOutput CommonTroubleOff
CommonTroubleOn
Off
On
DamperControl Close
Open
Off
On
DamperFeedback Disable
Enable

Quick reference

DoorControl HoldDoor
ReleaseDoor
Off
On
DoorFeedback Disable
Enable
Drill (Action 9003) Activate
Disable
Enable
Restore
Duct Disable
Enable
Evacuation (Action 9500) Activate
Disable
Enable
Restore
Emergency Disable
Enable
FanControl FanOff
FanOn
Off
On
FanFeedback Disable
Enable
Firephone Disable
Enable
Off
On
Gatevalve Disable
Enable
GuardPatrol OffGuard
OnGuard
GuardPatrolAlarm Activate
Disable
Enable
Restore
LampTest Activate
Disable
Enable
Restore

Quick reference

LED LEDOff
See also UserDefinedLED LEDOn
Off
On
Monitor Disable
Enable
NetworkClassAFault Activate
Disable
Enable
Restore
NonSupervisedOutput Off
On
NSCommonAlarmOutput NSCommonAlarmOff
NSCommonAlarmOn
Off
On
NSCommonMonitorOutput NSCommonMonitorOff
NSCommonMonitorOn
Off
On
NSCommonSupervisoryOutput NSCommonSupervisoryOff
NSCommonSupervisoryOn
Off
On
NSCommonTroubleOutput NSCommonTroubleOff
NSCommonTroubleOn
Off
On
NSDamperControl NSClose
NSOpen
Off
On
NSDoorControl NSHoldDoor
NSReleaseDoor
Off
On
NSFanControl NSFanOff
NSFanOn
Off
On
Power Disable
Enable

Quick reference

Pull Disable
Enable
Relay Off
On
RemoteTextMessage Off
On
Sequence Activate
Cancel
Disable
Enable
Restore
Smoke Disable
Enable
SmokeVfy Disable
Enable
SprinklerSupervisory Disable
Enable
StageOne Disable
Enable
StartAction Activate
Disable
Enable
Restore
StartSequence Activate
Cancel
Disable
Enable
SupDuct Disable
Enable
Supervisory Disable
Enable
Switch Disable
See also UserDefinedSwitch Enable
SysReset Activate
Disable
Enable
Restore
Tamper Disable
Enable

Quick reference

Telephone Disable
Enable
Off
On
Temperature Disable
Enable
TimeControl Activate
Disable
Enable
Restore
UserDefinedLED LEDOff
LEDOn
Off
On
UserDefinedSwitch Disable
Enable
Visual Off
On
Waterflow Disable
Enable

Quick reference

Y
Glossary
Accessory database A tab on the Communication Functions dialog box that

accesses download prompts for LSRAs and SMDNs. See
Communications in the Tools menu.
Actual data Device data read from the data circuit and stored in the
controller during the mapping process.
Address An electronic number assigned by the SDC controller to locate
and poll a device.
Alarm verification The shortest time span, during business hours, that a device
has to report an alarm condition before the system verifies it (05
to 55 seconds).
Alternate alarm verification The shortest time span, outside of normal business hours, that
a device has to report an alarm condition before the system
verifies it (05 to 55 seconds).
AND statement A logic function, which requires two or more conditions to be
met before it initiates a response.
AND group A labeled group consisting of two or more devices selected
from the object configuration table to form an AND statement.
Audible An assignment made in the SDC Configuration table for a
supervised module output wired to a notification appliance
circuit that building occupants can hear.
Audible notification appliances Indicating appliances designed to produce a signal that building
occupants can hear. Examples include bells, horns, chimes,
electronic horns, or buzzers.
AudioAmp An assignment made in made in SDC Configuration table for a
supervised output relay on a 30 or 50 Watt amplifier.
AuxPowerSupply An assignment made in SDC Configuration table for a
supervised power supply that supports appliances not tied to
the primary power supply.
Barcode Vertical bars of varying width that identify the serial numbers of
Signature series components.
Bell code group A label that identifies devices selected from the object
configuration table and grouped as members of a set that
activates a coded alarm signal.
CommonAlarmOff Command used to turn off a supervised notification signal
output circuit that a panel automatically activates when an
Alarm event occurs.
CommonAlarmOn Command used to turn on a supervised notification signal
Alarm event occurs.
EST2 System Programming Manual Y.1

Glossary
CommonAlarmOutput Classification used for a supervised notification signal output

circuit that a panel automatically activates when an Alarm event
occurs.
CommonMonitorOff Command used to turn off a supervised notification signal
output circuit that a panel automatically activates when a
Monitor event occurs.
CommonMonitorOn Command used to turn on a supervised notification signal
CommonMonitorOutput Classification used for a supervised notification signal output
circuit that a panel automatically activates when a Monitor
event occurs.
CommonSupervisoryOff Command used to turn off a supervised notification signal
Supervisory event occurs.
CommonSupervisoryOn Command used to turn on a supervised notification signal
CommonSupervisoryOutput Classification used for a supervised notification signal output
circuit that a panel automatically activates when a Supervisory
event occurs.
CommonTroubleOff Command used to turn off a supervised notification signal
Trouble event occurs.
CommonTroubleOn Command used to turn on a supervised notification signal
CommonTroubleOutput Classification used for a supervised notification signal output
circuit that a panel automatically activates when a Trouble
event occurs.
DamperControl A module assignment made in the SDC Configuration for a
supervised output relay that automatically turns on when a
damper’s status goes active.
DamperFeedback A module assignment made in the SDC Configuration for a
monitor that reports damper status.
Deenergize To place a relay in its nonoperating position where the normally
closed contact is closed and the normally open contact is open.
DigitalMessage A module assignment made in the SDC Configuration for a
digital message module goes active.
Digital message module A voice-quality, audio message, record and playback module
that can store one or two 30-second messages.
Dialer A digital alarm communicator transmitter or receiver that
automatically calls up the central monitoring station in the event
of a fire alarm.
Y.2 EST2 System Programming Manual

Glossary
Dialer group A logic group, which consists of two or more zones associated
with a dialer.
DoorControl A module assignment made in the SDC configuration for a
door’s status goes active.
DoorFeedback A module assignment made in the SDC Configuration for a
monitor that reports door status.
Duct A module assignment made in the SDC Configuration for an
alarm input that detects a fire by sampling air from piping or
tubing for products of combustion
Emergency An assignment made in the SDC Configuration for a module
that monitors an emergency input used in distress notification
applications.
Energize To place a relay in its operating position where the normally-
closed contact is open and the normally-open contact is closed.
EOL (end-of-line) Any device or resistor at that is last on a data line.
Expected data Device data programmed in the database through Systems
Definition Utility and downloaded into the panel controller
afterwards.
Fan control A module assignment made in the SDC Configuration for a
supervised output relay that automatically turns on when a fan
goes active.
Fan feedback A module assignment made in the SDC Configuration for a
monitor that reports fan status.
Firephone A module assignment made in the SDC Configuration for a
supervised firephone circuit.
Gatevalve A module assignment made in the SDC configuration for a
sprinkler supervisory input that reports valve status.
General A setting that causes time controls to take place every day.
Guard patrol A series of locations, from which an active security patrol
initiates devices to indicate that they are following a designated
route at the proper intervals.
Heat A module assignment made in the SDC Configuration for an
alarm input that detects a fire by its thermal properties.
Holiday A setting that causes time controls to take place only during a
specified holiday.
IDC (initiating device circuit) A supervised input circuit connected to alarm initiating devices
like smoke detectors, manual pull stations, and waterflow
switches.
Label Descriptive text assigned by the system designer to an object in
the database.
Latching Any device that remains locked on until it is reset.
LED (light emitting diode) A device that lights up to indicate activity on its associated
device or function.

Glossary
Mapping The process the data circuit controller uses to determine the
electrical relative positions between devices on the data circuit.
Monitor A module assignment made in the SDC Configuration for a
monitor input that activates system common monitor functions.
NAC A circuit directly connected to notification appliances. See also
(Notification Appliance Circuit) Notification appliance.
Node A single control panel that is part of a network.
Non-latching A device that will activate and reset to its normal position
according to its own input condition.
NonSupervisedOutput A module assignment made in the SDC Configuration for relays
that do not monitor the integrity of the circuit they are
controlling.
Notification appliance Any alarm device that provides a visual, audible, or tactile
(touchable) warnings of fire alarm conditions.
NSCommonAlarmOff Command used to turn off a nonsupervised notification signal
Alarm event occurs.
NSCommonAlarmOn Command used to turn on a nonsupervised notification signal
Alarm event occurs.
NSCommonAlarmOutput Classification used for a nonsupervised notification signal
Alarm event occurs.
NSCommonMonitorOff Command used to turn off a nonsupervised notification signal
NSCommonMonitorOn Command used to turn on a nonsupervised notification signal
NSCommonMonitorOutput Classification used for a nonsupervised notification signal
NSCommonSupervisoryOff Command used to turn off a nonsupervised notification signal
NSCommonSupervisoryOn Command used to turn on a nonsupervised notification signal
NSCommonSupervisoryOutput Classification used for a nonsupervised notification signal
NSCommonTroubleOff Command used to turn off a nonsupervised notification signal

Glossary
NSCommonTroubleOn Command used to turn on a nonsupervised notification signal

NSCommonTroubleOutput Classification used for a nonsupervised notification signal
NSDamperControl A module assignment made in the SDC configuration for a
nonsupervised output that automatically turns on when a
damper’s status goes active.
NSDoorControl A module assignment made in the SDC configuration for a
nonsupervised output that automatically turns on when a door’s
status goes active.
NSFanControl A module assignment made in the SDC configuration for a
nonsupervised output that automatically turns on when a fan’s
status goes active.
Object An entity in the controller database, which represents an
addressable device, a circuit, or a point in the system.
Power A module assignment made in the SDC Configuration for a
sprinkler supervisory input that reports a loss of power to
electrically powered sprinkler equipment.
Priority Numbers assigned to commands in output statements to
specify their importance over other commands.
Pseudo point An input generated by a nonphysical device in the system.
Pull A module assignment made in the SDC Configuration for an
alarm input that is activated using a mechanical switch, as in a
manual pull station.
Relay A module assignment made in the SDC Configuration for a
device that switches positions to activate other devices or
outputs.
RemoteTextMessage An object that displays an active system point on a remote
alphanumeric annunciator. Select the LSRA or the SMDN
accessory in the Object Configuration table and look for a
RemoteTextMessage in the Device Type column.
Revision A set of changes made and saved in a single project database.
Rule A programming statement that consists of a label, an input
statement, and one or more output statements that specify what
the system will do during a specific event.
SDC (Signature data circuit) The wiring that connects detectors and modules to each other
and to the main controller module.
SDU The Systems Definition Utility (SDU), which consists of
everything necessary to program a fire alarm system, check its
status, and generate reports on it.
Smoke A module assignment made in the SDC Configuration for an
alarm input that goes active when a Signature series smoke
detector senses a prescribed level of obscuration.

Glossary
SmokeVfy A module assignment made in the SDC Configuration for an

alarm input that goes active when a smoke detector is in the
verification mode.
SprinklerSupervisory A module assignment made in the SDC Configuration for a
sprinkler supervisory input.
StageOne A module assignment made in the SDC Configuration for the
pre-alarm stage (first address) of a two-stage pull station.
SupDuct A module assignment made in the SDC Configuration for a duct
input that reports off-normal supervisory duct status.
Supervisory A module assignment made in the SDC Configuration for an
IDC that monitors the integrity of its circuit.
Switch A module assignment made in the SDC Configuration for a
control/display module switch.
Tamper A module assignment made in the SDC Configuration for a
supervisory input that reports off-normal sprinkler system
status.
Telephone A module assignment made in the SDC Configuration for a
supervised telephone circuit.
Temperature A module assignment made in the SDC Configuration for a
sprinkler supervisory input that reports freezing temperatures in
the vicinity of sprinkler system components.
Time control Any programmed command that takes placed during a
specified day type at a prescribed hour and minute for a chosen
duration. See also General, Holiday, Weekend, and Weekday.
UserDefinedLED A light emitting diode (LED) on the front panel display that the
user may program to light for any system function.
UserDefinedSwitch A switch on the front panel display that the user may program
to perform any system function.
Visible notification appliances Indicating appliances designed to produce a signal building
occupants can. Examples include strobes, lamps, target, or
meter deflection.
Visual An assignment made in the SDC Configuration table for a
supervised module output wired to a notification appliance
circuit that building occupants can see.
Waterflow A module assignment made in the SDC configuration for an
alarm input that detects a fire by the movement of water
through the fire-protection sprinkler system.
Weekday A setting that causes time controls to take place only during
weekdays.
Weekend A setting that causes time controls to take place only during
weekends.
Zone A distinct physical area, in which closely associated devices are
located.

Z
Index
* commands (continued)
Cancel • 4.3
*. See wildcards Close • 4.4
CommonAlarmOff • 4.5
{ CommonAlarmOn command • 4.6
CommonMonitorOff • 4.7
{. See comments, rule
CommonMonitorOn • 4.8
CommonSupervisoryOff • 4.9
A CommonSupervisoryOn • 4.10
action 9000. See GuardPatrolAlarm CommonTroubleOff • 4.11
action 9002. See SysReset CommonTroubleOn • 4.12
action 9003. See Drill Delay • 4.13
action 9004. See AlarmSilence Disable • 4.14–4.15
action 9500. See Evacuation Enable • 4.16–4.17
actions FanOff • 4.18
described • 2.9–2.10 FanOn • 4.19
in Activate commands • 4.2 HoldDoor • 4.20
in Define events • 3.7 LEDOff • 4.21
in Disable commands • 4.14 LEDOn • 4.22
in Enable commands • 4.16 listed by device • A.17–A.21
in Restore commands • 4.45 NSClose • 4.23
Activate command • 4.2 NSCommonAlarmOff • 4.24
Active event • 3.2–3.3 NSCommonAlarmOn • 4.25
Alarm event • 3.4 NSCommonMonitorOff • 4.26
alarm initiating devices NSCommonMonitorOn • 4.27
in Active events • 3.2 NSCommonSupervisoryOff • 4.28
in Alarm events • 3.4 NSCommonSupervisoryOn • 4.29
in Disable commands • 4.14 NSCommonTroubleOff • 4.30
in Enable commands • 4.16 NSCommonTroubleOn • 4.31
in TestActive events • 3.11 NSFanOff • 4.32
in TestTrouble events • 3.13 NSFanOn • 4.33
in Trouble events • 3.15 NSHoldDoor • 4.34
AlarmSilence • 2.9 NSOpen • 4.35
AND groups • 2.7, 3.7 NSReleaseDoor • 4.36
Off • 4.37–4.38
Offguard • 4.39
B
On • 4.40–4.41
bar code readers • vii OnGuard • 4.42
bell code groups • 2.7 Open • 4.43
ReleaseDoor • 4.44
C Restore • 4.45
comments, rule • 1.4
CallIn event • 3.5 CommonAlarmOff command • 4.5
Cancel command • 4.3 CommonAlarmOn • 4.6
Close command • 4.4 CommonMonitorOff command • 4.7
commands CommonMonitorOn command • 4.8
Activate • 4.2 CommonSupervisoryOff command • 4.9
EST2 Installation and Service Manual Z.1

Index
CommonTroubleOff command • 4.11 F

compiling the rules file • 1.11 FanOff command • 4.18
Confirmation event • 3.6 FanOn command • 4.19
Firephone
in Callin events • 3.5
D in Disable commands • 4.15
default priorities • 2.5 in Enable commands • 4.17
Define event • 3.7–3.8 in Off commands • 4.37
Delay command • 4.13 in On commands • 4.40
device type lists, valid formats, label • 1.13
for Activate commands • 4.2
for Active events • 3.2 G
for Alarm events • 3.4
for Confirmation events • 3.6 glossary of terms • Y.1–Y.6
for Define events • 3.7 guard patrol groups
for Disable commands • 4.14 defined and illustrated • 2.8
for Enable commands • 4.16 in Offguard commands • 4.39
for Monitor events • 3.9 in Onguard commands • 4.42
for Off commands • 4.37 GuardPatrolAlarm • 2.8, 2.11
for On commands • 4.40
for Restore commands • 4.45 H
for Supervisory events • 3.10
for TestActive events • 3.11
for TestTrouble events • 3.13
for Trouble events • 3.15 I
dialer groups • 2.7 inputs. See specific entries under events
Disable command • 4.14–4.15 input-to-output matrix • 1.19
documentation
EST2 • iv
L
related • v
Drill • 2.9 labels
characteristics of • 1.7
E developing a plan for • 1.12–1.17
LampTest • 2.9
Enable command • 4.16–4.17 latching supervisory devices
equipment, optional • vii in Active events • 3.2
EST2 documentation • iv in Disable commands • 4.14
Evacuation • 2.9 in Enable commands • 4.16
events in Supervisory events • 3.10
Active • 3.2–3.3 in TestActive events • 3.11
Alarm • 3.4 in TestTrouble events • 3.13
CallIn • 3.5 in Trouble events • 3.15
Confirmation • 3.6 LEDOff command • 4.21
Define • 3.7–3.8 LEDOn command • 4.22
listed by device • A.6–A.9 limit in rules editor, memory • 1.8
Monitor • 3.9 logic groups • 2.7
Supervisory • 3.10 L-variable • 2.3
TestActive • 3.11–3.12
TestTrouble • 3.13–3.14
M
TimeControl • 2.13
Trouble • 3.15–3.16 mathematical operators • 2.4
examples, programming. See under sample matrix, input-to-output • 1.19
command rules; sample event rules memory limit, rules editor • 1.8
exceeding rules editor memory limits • 1.8 modifiers, label • 1.14–1.15
Z.2 EST2 Installation and Service Manual

Index
Monitor event • 3.9 programming examples. See under sample

command rules; sample event rules
N
Q
NetworkClassAFault • 2.11
non-latching monitor devices quick reference • A.1–A.21
in Active events • 3.2
in Disable commands • 4.14 R
in Enable commands • 4.16
in Monitor events • 3.9 readers, bar code • vii
in TestActive events • 3.11 related documentation • v
in TestTrouble events • 3.13 ReleaseDoor command • 4.44
in Trouble events • 3.15 requirements, minimum equipment • vi
non-latching supervisory devices • 3.2 Restore command • 4.45
nonsupervised output devices rules
in Off commands • 4.37 examples of. See under sample
in On commands • 4.40 command rules; sample event rules
in Trouble events • 3.15 factors affecting compile speed of • 1.11
NSClose command • 4.23 memory limit for in rules editor • 1.8
NSCommonAlarmOff command • 4.24 using L-variables in • 2.3
NSCommonAlarmOn command • 4.25 using mathematical operators in • 2.4
NSCommonMonitorOff command • 4.26 using N-variables in • 2.2
NSCommonMonitorOn command • 4.27 using wildcards in • 2.2
NSCommonSupervisoryOn command • 4.29 S
sample command rules
Activate • 4.2
Cancel • 4.3
Close • 4.4
CommonAlarmOff • 4.5
CommonAlarmOn • 4.6
CommonMonitorOff • 4.7
numbers and unique labels • 1.16
CommonMonitorOn • 4.8
N-variable • 2.2
CommonSupervisoryOff • 4.9
CommonSupervisoryOn • 4.10
O CommonTroubleOff • 4.11
objects CommonTroubleOn • 4.12
defined • 1.6 Delay • 4.13
identification of by groups • 1.18 Disable • 4.15
Off command • 4.37–4.38 Enable • 4.17
OffGuard command • 4.39 FanOff • 4.18
On command • 4.40–4.41 FanOn • 4.19
OnGuard command • 4.42 HoldDoor • 4.20
Open command • 4.43 LEDOff • 4.21
operators, mathematical • 2.4 LEDOn • 4.22
output commands. See specific entries NSClose • 4.23
under commands NSCommonAlarmOff • 4.24
NSCommonAlarmOn • 4.25
NSCommonMonitorOff • 4.26
P
NSCommonMonitorOn • 4.27
plan, label • 1.12–1.17 NSCommonSupervisoryOff • 4.28
predefined actions • 2.9 NSCommonSupervisoryOn • 4.29
priorities • 2.5 NSCommonTroubleOff • 4.30
NSCommonTroubleOn • 4.31

Index
sample command rules (continued) syntax, command (continued)

NSFanOff • 4.32 CommonAlarmOn • 4.6
NSFanOn • 4.33 CommonMonitorOff • 4.7
NSHoldDoor • 4.34 CommonMonitorOn • 4.8
NSOpen • 4.35 CommonSupervisoryOff • 4.9
NSReleaseDoor • 4.36 CommonSupervisoryOn • 4.10
Off • 4.38 CommonTroubleOff • 4.11
OffGuard • 4.39 CommonTroubleOn • 4.12
On • 4.41 Delay • 4.13
OnGuard • 4.42 Disable • 4.14
Open • 4.43 Enable • 4.16
ReleaseDoor • 4.44 FanOff • 4.18
Restore • 4.45 FanOn • 4.19
sample event rules HoldDoor • 4.20
Active • 3.3 LEDOff • 4.21
Alarm • 3.4 LEDOn • 4.22
CallIn • 3.5 NSClose • 4.23
Confirmation • 3.6 NSCommonAlarmOff • 4.24
Define • 3.7–3.8 NSCommonAlarmOn • 4.25
Monitor • 3.9 NSCommonMonitorOff • 4.26
Supervisory • 3.10 NSCommonMonitorOn • 4.27
TestActive • 3.12 NSCommonSupervisoryOff • 4.28
TestTrouble • 3.14 NSCommonSupervisoryOn • 4.29
Trouble • 3.16 NSCommonTroubleOff • 4.30
sequences NSCommonTroubleOn • 4.31
described • 2.11–2.12 NSFanOff • 4.32
in Activate commands • 4.2 NSFanOn • 4.33
in Define events • 3.7 NSHoldDoor • 4.34
in Disable commands • 4.14 NSOpen • 4.35
in Enable commands • 4.16 NSReleaseDoor • 4.36
StartAction • 2.10 Off • 4.37
StartSequence • 2.12 Offguard • 4.39
summaries On • 4.40
command specification • A.10–A.16 Onguard • 4.42
event specification • A.2–A.5 Open • 4.43
supervised output devices ReleaseDoor • 4.44
in Confirmation events • 3.6 Restore • 4.45
in Off commands • 4.37 syntax, event
in On commands • 4.40 Active • 3.2
in TestTrouble events • 3.13–3.14 Alarm • 3.4
in Trouble events • 3.16 CallIn • 3.5
Supervisory event • 3.10 Confirmation • 3.6
switches Define • 3.7
in Active events • 3.2 Monitor • 3.9
in Disable commands • 4.15 Supervisory • 3.10
in Enable commands • 4.17 TestActive • 3.11
syntax, basic TestTrouble • 3.13
for every rule • 1.3 Trouble • 3.15
for input statements • 1.4 SysReset • 2.9
for output statements • 1.5–1.6 Systems Definition Utility (SDU) • vi
syntax, command
Activate • 4.2 T
Cancel • 4.3
Close • 4.4 Telephone
CommonAlarmOff • 4.5 in Callin events • 3.5

Index
Telephone (continued) user-defined LEDs (continued)

in disable commands • 4.15 in Off commands • 4.37
in Enable commands • 4.17 in On commands • 4.40
in Off commands • 4.37 user-defined switch
in On commands • 4.40 in Disable commands • 4.15
TestActive event • 3.11–3.12 in Enable commands • 4.17
TestTrouble event • 3.13–3.14 using labels as messages • 1.17
time controls
in Activate commands • 4.2 V
in Define events • 3.7
programming of • 2.13 variables, L • 2.3
Trouble event • 3.15–3.16 variables, N • 2.2
U W
user-defined LEDs wildcards (*) • 1.10, 1.16, 2.2
in LEDOff command • 4.21 writing comments about rules • 1.4
in LEDOn command • 4.22

Index

EST EST2 v5.0 System Programming Manual

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

EST EST2 v5.0 System Programming Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

EST EST2 v5.0 System Programming Manual

Uploaded by

Copyright:

Available Formats

EST2

System Programming Manual

P/N 270187 • Rev 5.0 • 18AUG00

Technical Manuals Online! - http://www.tech-man.com

Technical Manuals Online! - http://www.tech-man.com

Important information • iii

Chapter 1 Overview • 1.1

Chapter 2 Advanced programming features • 2.1

Chapter 3 Input events • 3.1

Chapter 4 Output commands • 4.1

EST2 System Programming Manual i

Technical Manuals Online! - http://www.tech-man.com

HoldDoor command • 4.20

Appendix A Quick reference • A.1

ii EST2 System Programming Manual

Technical Manuals Online! - http://www.tech-man.com

EST2 System Programming Manual iii

Technical Manuals Online! - http://www.tech-man.com

Getting the most out of this manual

Finding EST2 documentation

iv EST2 System Programming Manual

Technical Manuals Online! - http://www.tech-man.com

Finding related documentation

EST2 System Programming Manual v

Technical Manuals Online! - http://www.tech-man.com

About the Systems Definition Utility

Minimum equipment requirements

vi EST2 System Programming Manual

Technical Manuals Online! - http://www.tech-man.com

EST2 System Programming Manual vii

Technical Manuals Online! - http://www.tech-man.com

viii EST2 System Programming Manual

Technical Manuals Online! - http://www.tech-man.com

EST2 System Programming Manual 1.1

Technical Manuals Online! - http://www.tech-man.com

1.2 EST2 System Programming Manual

Technical Manuals Online! - http://www.tech-man.com

Programming using rules and objects

EST2 System Programming Manual 1.3

Technical Manuals Online! - http://www.tech-man.com

the operations performed by the rule will automatically restore

Writing comments about rules

event_type Specifies the type of input event required for the

Note: When the device_type and 'object_label' parameters are

1.4 EST2 System Programming Manual

Technical Manuals Online! - http://www.tech-man.com

command Specifies the required final state of the output

EST2 System Programming Manual 1.5

Technical Manuals Online! - http://www.tech-man.com

'routing_label' Specifies the label of the network routing group

1.6 EST2 System Programming Manual

Technical Manuals Online! - http://www.tech-man.com

Character substitution table

EST2 System Programming Manual 1.7

Technical Manuals Online! - http://www.tech-man.com

Creating a rules file

To use a text editor that can exceed the 32K limit:

1. Enter the rules in the text editor (MS Word®, Wordpad®, or