Welcome

Welcome to SDU Help. This information is provided to support you while you configure,
program, and test your life safety system.
If you are new to using Help, see Finding topics in Help.
The Engineering software release notes contain important information that you should read
before using this application. See Software release notes.
In order for this product to comply with the requirements in UL 864 Standard for Control
Units and Accessories for Fire Alarm Systems and CAN/ULC-S527 Standard for Control
Units for Fire Alarm Systems, certain programming features or options must be limited to
specific values or not used at all. For more information, see UL 864 and ULC-S527
programming requirements.

3-SDU V5.40 Help

P/N 180653-EN • R016 • ISS 06OCT17
© 2017 United Technologies Corporation. All rights reserved.
Finding topics in Help
This Help system includes a table of contents, an index, and a search utility for finding the
information you need. Each is located on a separate tab.
Note: To quickly access information about a dialog box that you are working in, you can
press F1 to open a context-sensitive Help topic that describes the objects in the dialog box.
Using the Contents tab
Click the Contents tab in the navigation pane. The Contents tab provides a list of Help
topics categorized by subject. Use this tab for a systematic study of a particular subject.

Each folder identifies a general

category of help topics. Double-click
the folder icon to display the topics it
contains. Double-click it again to
close the folder.

Each document icon identifies a

page, or topic, containing
information. Click the document icon
to display the topic.
Using the Index tab
Click the Index tab. The index provides an alphabetical list of keywords and phrases linked
to related information. Use this tab to find information by entering a keyword, just as you
would use the index of a book.
To find information using the Index tab:
1. Use the scroll bar to browse the keyword list.
— or —
In the box above the list, type a keyword or phrase. This causes the list to scroll
automatically.
2. If you find a word or phrase that interests you, select it, then click Display.
If a single topic is linked to the keyword, the topic is displayed in the right pane.
If multiple topics are linked the keyword, a Topics Found dialog box is displayed.
Select a topic to display it in the right pane.
3. If you cannot find what you are looking for in the index, try a different keyword, or
use the Search tab.
Using the Search tab
Click the Search tab. The Search tab allows you to find any instance of a specific word or
phrase, wherever it may occur in the help system.

To find information using the Search tab:

1. In the box at the top of the tab, enter the word or phrase that you want to find.
Enclose phrases in quotes.
2. Click the button labeled List Topics. All topics containing the search term are listed.
3. Select the topic that interests you, then click Display. The help topic is displayed in
the right pane. Each occurrence of the search term is highlighted.
4. To turn off the highlighting, right-click the topic, and On the menu that appears click
Refresh.
Tip: You can search for multiple keywords or phrases simultaneously by separating them
with a space.
Software release notes
The software release notes contain valuable information specific to this software release
that may not be included in the technical documentation or this Help file. Please read this
documentation to become familiar with any new features provided in the system software or
in the SDU.

To print a copy of the software release notes:

1. On the Windows task bar, click Start.
2. Click Programs, and then click Walter Kidde Portable Equipment, Inc.
3. Click 3-SDU, and then click Release Notes.
The Release Notes are in PDF format and require Adobe Reader. The Release Notes are
located in C:\FAST\3-SDU\BIN where C: is the letter of the hard drive on which SDU is
installed.
Legal information
Information in this help system is subject to change without notice.
Unauthorized reproduction or distribution of this program, or any portion of it, may result in
severe civil and criminal penalties, and will be prosecuted to the maximum extent possible
under law.
Complying with all applicable copyright laws is your responsibility. Other product and
company names mentioned herein may be the trademarks of their respective owners.
UL 864 and ULC-S527 programming requirements
NOTICE TO USERS, INSTALLERS, AUTHORITIES HAVING JURISDICTION, AND OTHER
INVOLVED PARTIES
This product incorporates field-programmable software. In order for this product to comply
with UL and ULC standards, certain programming features or options must be limited to
specific values or not used at all as indicated below.

Programmable feature Possible Permitted UL 864 Permitted ULC-

or option settings settings S527 settings

Telephone line No Yes Yes

supervision Yes

Second telephone line No No [1] No [1]

Yes Yes [13] Yes [13]

Event Resound 00:00:00 00:00:00 [2] 00:00:00 [2]

to 99:59:59 to 24:00:00 to 24:00:00

AC Power Delay Disabled 01:00 to 03:00 01:00 to 03:00

01:00 to 45:00

Event message routing All Cabinets All Cabinets All Cabinets

No Cabinets No Cabinets [3] No Cabinets [3]
User defined routes User defined User defined
(1 to 15) routes (1 to 15) [4] routes (1 to 15)
[4]

Event message display Enabled Enabled Enabled

filtering: Alarm, Disabled Disabled [5] Disabled [5]
Supervisory, and Trouble
options

Delays (programmed in 0 to 65,535 seconds 0 to 65,535 0 to 65,535

rules) seconds [6] seconds [7]

Alarm verification 0 to 56 seconds 0 to 44 seconds 0 to 44 seconds

Automatic alarm signal 0 to 30 minutes 3 to 30 minutes 5 to 30 minutes

silence for buildings not
equipped with an
annunciator, or
20 to 30 minutes
for buildings
equipped with an
annunciator

CMS event reporting 1 to 255 1 to 255 [8] 1 to 255 [9]

priority (programmed in
rules)

CMS activate and Send on activation Activation and Activation and

restore messages Send on restoration restoration restoration
(programmed in rules) triggers must triggers must
match the match the
message type message type

AND group member GENALARM GENALARM GENALARM

device types, Activation SMOKE SMOKE SMOKE
event: Q1 - Alarm
SMOKEVFY SMOKEVFY [11] SMOKEVFY [11]
HEAT HEAT HEAT
PULL PULL PULL
 STAGEONE STAGEONE [11] STAGEONE [11]
STAGETWO STAGETWO [11] STAGETWO [11]
WATERFLOW WATERFLOW WATERFLOW
COALARM COALARM
COSUPERVISORY COSUPERVISORY

AND group device 1 to 255 1 to 255 [12] 1 to 255 [12]

activation count

Zone group member GENALARM GENALARM GENALARM

device types SMOKE SMOKE SMOKE
SMOKEVFY SMOKEVFY [10] SMOKEVFY [10]
HEAT HEAT HEAT
PULL PULL PULL
STAGEONE STAGEONE [10] STAGEONE [10]
STAGETWO STAGETWO [10] STAGETWO [10]
WATERFLOW WATERFLOW WATERFLOW
COALARM COALARM
COSUPERVISORY COSUPERVISORY

Matrix group member GENALARM GENALARM GENALARM

device types SMOKE SMOKE SMOKE
SMOKEVFY SMOKEVFY [10] SMOKEVFY [10]
HEAT HEAT HEAT
PULL PULL PULL
STAGEONE STAGEONE [10] STAGEONE [10]
STAGETWO STAGETWO [10] STAGETWO [10]
WATERFLOW WATERFLOW WATERFLOW
COALARM COALARM
COSUPERVISORY COSUPERVISORY

Matrix group device 3 to 10 3 to 10 [12] 3 to 10 [12]

activation count

Signature input modules: N/A No No

Personality code 18

SIGA-IO(-MIO) modules: N/A No No

Personality codes 35 and
36

CO Supervisory device Latching N/A N/A

type Nonlatching

CO Monitor device type Latching N/A N/A

Nonlatching

Bypass command N/A N/A N/A

Silence inhibit 0 to 3 minutes 3 minutes 3 minutes

Alarm event indicator Red Red Red

color Green
Yellow

Emergency event Red Green Yellow

indicator color Green Yellow
Yellow
Supervisory event Red Green Yellow
indicator color Green Yellow
Yellow

Building event indicator Red Green Yellow

color Green Yellow
Yellow

Trouble event indicator Red Green Yellow

color Green Yellow
Yellow

Monitor event indicator Red Green Yellow

color Green Yellow
Yellow

Telephone events Yes Monitor, Property and

Supervisory, Building
Property and
Building

Alarm Signal Yes ON ON [14]

OFF

[1] Allowed only when the supervising station supervises the telephone line and
annunciates fault conditions within 200 seconds for UL 864 compliance or within 90
seconds for CAN/ULC-S527 compliance.
[2] Allowed only on control panels that transmit trouble event signals off premises.
[3] Allowed only with monitor device types and switches.
[4] Allowed only if the user route includes the control panel.
[5] Allowed only on nonrequired remote annunciators.
[6] Allowed only when setting does not prevent the activation or transmission of alarm or
supervisory signals within 10 seconds or trouble signals within 200 seconds.
[7] Allowed only when setting does not prevent the activation or transmission of alarm or
supervisory signals within 10 seconds or trouble signals within 90 seconds.
[8] When priorities are used, alarm events must have a higher priority than supervisory
and trouble events.
[9] When priorities are used, fire alarm events must have first priority. Life safety
emergency condition signals are second priority. Fire supervisory signals are third priority.
Property and building safety signals are fourth priority. Trouble signals associated with fire
alarm and life and/or property safety are fifth priority. All others are sixth priority.
[10] Not allowed in Zone groups that are used to initiate the release of extinguishing agent
or water.
[11] Not allowed in AND groups that are used to initiate the release of extinguishing agent
or water.
[12] A minimum device activation count of 2 is required if the AND group or matrix group is
used to initiate the release of extinguishing agent or water.
[13] If only one type of passive communication is available at the protected premises, there
shall be two channels provided. Separate paths throughout the protected premises and
through any common carrier or third party communications network to the fire signal
receiving center shall be provided for each communication channel.
[14] A switch must be programmed for Alarm Signal ON. The switch will activate all
Evacuation output and have a red LED indicating when active. Label the switch Alarm
Signal Activation.
Creating a new project
All that is needed to create a new project is to supply a project name and password. This
creates a blank project database.
Tips
Choose a password that is easy to remember, but difficult to guess.
Write the password down and store it in a secure place. If you forget the password,
you will be unable to open the project again later.
To create a new project:
1. On the Project menu, select New
2. In the Project Name box, enter a unique project name.
The name must contain no more than 8 characters.
3. Enter a password in the Password box.
Project passwords are limited to 8 characters and are not case sensitive.
4. Click OK.
5. Type the password exactly as before and then click OK.
If the password was entered correctly, the SDU opens the project database file and
displays the Project Parameters dialog box.
Opening an existing project
Opening a project begins a programming session and allows the system programmer to
make changes to the project database. Opening a project also gives the system
programmer or service technician access to other functions, such as the rule editor and
diagnostic tools.
Tip: You can customize the SDU to make the default project selection be the last project
that was saved.
To open an existing project:
1. On the Project menu, select Open.
2. In the Project list, select the project you want to work with.
3. In the Version box, select which project version you want to open.
4. In the Password box, type the password for the selected project.
5. Click OK.
Entering a project description
Entering a project description is helpful for maintaining an accurate record of your projects.
The project description is printed as part of SDU Cabinet Report.
To enter a project description:
1. On the Configure menu, choose Project.
2. From the Project tab, type information about the project in the Project Description
box. The text automatically wraps around when you reach the edge of the text
boxes.
3. Click OK.
Saving projects
There are two ways to save the active project. You can save the project as a new revision
or as a different version. Use the Save command to revise the existing version, or use the
Save As command to save the project as a different version.
The Systems Definition Utility automatically stores the data entered during a programming
session into a temporary working directory. You must still save your work before closing or
exiting for the SDU to save your changes.
To save a project as a new revision to the existing version:
1. On the Project menu, select New.
2. In the Save dialog box, type a description of the changes made to the project during
the programming session.
3. Click OK.
To save a project as a different version number:
1. On the Project menu, select Save As.
2. Change the project name and/or version number.
3. Enter a description of changes that were made or the reason for changing the
version number.
4. Click OK.
See also
Tips for saving projects
Tips for saving projects
Here are some tips for saving projects:
Saving projects as a different name or version number before making any changes
lets you retain a "known good" project database in case the changes you made in
the current programming session causes hard-to-find system errors.
Break down the programming session into manageable tasks and save your project
when you reach the end of each task
Save your project after you have entered a large amount of data
Save your project after you have successfully compiled the rules file
Save your project before downloading the project database
Changing project passwords
You can change the password for the active project at any time to prevent unauthorized
access to the project database. At the same time, you can also have the password change
apply to all versions of the active project.
To change the project password:
1. On the Project menu, select Change Password.
2. In the Current Password box, type the password for the active project.
3. In the New Password box, type the new password.
4. In the Verify New Password box, type the new password exactly as before.
5. Select the Change all versions check box only if you want the password change to
apply to all versions of the active project.
6. Click OK.
Converting the project database
Converting the project database creates the binary file used to program the panel. Convert
the project database after successfully compiling the rules file and before downloading.
Tip: You can customize the SDU to automatically start converting the database after it
finishes compiling the rules.

To convert a project database:

1. On the Tools menu, select DB conversion, and then click one of the following:
All Databases: Converts all databases in the network
3-CPU Databases: Converts all 3-CPU databases in the network
Loop Controller Databases: Converts all loop controller databases in the network
3-MODCOM Databases: Converts all 3-MODCOM databases in the network
3-SAC Databases: Converts all 3-SAC databases in the network
Selected Databases: Converts user-selected loop controller, 3-MODCOM, and 3-
SAC databases
2. Click Done.
Deleting a project
Deleting a project permanently removes the project from the SDU database.
Caution: Once you have deleted a project from SDU database it cannot be recovered.
Never delete a project using Windows commands.

To delete a project:
1. From the Project menu, select Delete.
2. In the Project list, select the project you want to deleted.
3. In the Version box, select which project version you delete.
4. In the Password box, type the password for the selected project.
5. Click OK.
6. Click Yes to confirm your selection.
Exporting a project
Export a project and copy it onto a removable media device to:
create backup copies of the project. Projects cannot be restored from the panel, so
you must create backups on other media to be able to restore the project at a later
date if you need to.
create a copy to give to the building owner
create a copy to use for help from technical support.
To export a project database:
1. From the Project menu, select Export.
2. In the Projects list, select the project you want to export.
3. Select the Export with Audio Files check box if you want to export the audio files
along with the project.
4. In the Export to box, choose a destination directory.
Click the folder open icon to browse for another location if the desired destination
directory is not displayed.
5. Click OK.
Importing a project
Importing a project database adds the project to SDU database. To import a project
database you must know the project password.
To import a project database:
1. On the Project menu, select Import.
2. In the Import from box, select the source directory that contains the project you
want to import.
Click the folder open icon to browse for location of the project file you want to
import.
3. On the Select SDU Import File dialog box, locate then select the project.
Select the Open as read only check box if you only want to view the project.
4. Click Open.
5. Click OK.
Customizing SDU operation
You can customize some aspects of the SDU environment. For example, you can set up
automatic database conversions to run each time rules are compiled, provided no errors
are encountered during the rules compile.
To customize SDU operation:
1. On the Options menu, select Customize. This opens the Customize SDU
Environment dialog box.
2. On each of the tabs, make the appropriate selections. The following topics provide
detailed information about the settings found on each tab:
Customize SDU Environment - Behavior tab
Customize SDU Environment - Configuration tab
Customize SDU Environment - Fonts & Languages tab
Configuring alarm silence operation
Configuring the alarm silence operation requires setting properties found on the Operations
tab and Timing tab of the Project Parameters dialog box. You might also have to write a
rule if your application requires system responses unique to the alarm silence function or if
you are required to activate the alarm silence function from a panel that does not have an
LCD module.
Note: To comply with ULC requirements (Canadian marketplace), set the Silence Inhibit
option for at least one minute.
To configure Alarm Silence operation:
1. From the Configure menu, choose Project.
2. Click the Operation tab and perform the following steps:
Under Alarm Silence, click which alarm notification device types the system will
silence when the alarm silence function activates.
Select the Zone Resound Inhibit check box to prohibit the alarm silence function from
restoring when a device in an active zone group changes to the active state.
Select the Water Flow Silence check box to allow the alarm silence function to
silence alarm notification device types when a waterflow device is in the active state.
3. Click the Timing tab and perform the following steps:
Set Auto Signal Silence for the amount of time that notification appliance circuits are
required to remain active before automatically silencing. A setting of 0 minutes
designates that notification appliance circuits are to remain active indefinitely.
Set Silence Inhibit for the amount of time that notification appliance circuits are
required to remain active before they can be silenced manually. A setting of 0
minutes designates that notification appliances can be silenced without any delay.
Set Page Inhibit for the amount of time that notification appliance circuits are
required to remain active before they can be interrupted by the paging function. A
setting of 0 seconds designates that the paging function can be used without any
delay.
Set Alarm Silence Cancel Delay for the amount of time needed for the alarm silence
function to remain in effect in order to prevent notification appliance circuits from
randomly activating during rule restoration.
4. Click OK.
5. From the Rules menu, select Edit Rules, then:
If you want to activate the alarm silence function on panels that do not have an LCD
module, add a rule that executes the AlarmSilence command when an operator
presses a control-display module switch.
 If you want to add other system responses unique to the alarm silence function, add
a rule that activates when the AlarmSilence event changes to the active state.
6. Click OK.
7. Perform a database conversion for all CPUs and loop controllers on the network.
See Converting the project database.
See also
Alarm Silence functional description
AlarmSilence command
AlarmSilence event
Configuring drill operation
Configuring the drill operation requires setting properties found on the Operations tab of the
Project Parameters dialog box. You might also have to write a rule if your application
requires system responses unique to the drill function or if you are required to activate the
drill function from a panel that does not have an LCD module.

To configure Drill operation:

1. From the Configure menu, choose Project.
2. Click the Operation tab.
3. Under Drill, click which alarm notification device types the system will turn on when
the drill function activates.
4. Click OK.
5. From the Rules menu, select Edit Rules, then:
If you want to activate the drill function on panels that do not have an LCD module,
add a rule that executes the Drill command when an operator presses a control-
display module switch.
If you want to add other system responses unique to the drill function, add a rule
that activates when the Drill event changes to the active state.
6. Click OK.
7. Perform a database conversion for all CPUs and loop controllers on the network.
See Converting the project database.
See also
Drill command
Drill event
Drill functional description
Configuring panel display operation
Configuring the LCD panel display operation requires setting properties found on the Project
tab, Operations tab, and Timing tab of the Project Parameters dialog box.
To configure the panel display operation:
1. On the Configure menu, choose Project.
2. On the Project tab, type the banner text you want displayed when the panel is
operating in normal mode. The first line of the banner goes in User Label Line 1 and
the second line goes in User Label Line 2.
3. Click the Operations tab, then:
Set Primary Language for the language that the LCD module normally uses to
display text.
If the project requires bilingual operation, select the Secondary Language check
box, and then choose a second language.
4. Set Date Format for the order in which the LCD module displays the date. MM
stands for the month's number, DD the date, and YYYY the year.
5. Choose the Timing tab and Set User Time Out to the amount of time that an LCD
module can be inactive before returning to the lowest user access level.
6. Click OK.
Configuring common control buttons on an LCD
The Key Functions tab lets you specify which command executes, or the user access level
required to execute the command, when an operator presses a button on the LCD. The
Market Place setting on the Project Parameters - Operations tab determines the default
settings for the buttons.
Note: The button functions must match the label supplied with the LCD module. If you
change a button's function, you must modify the label.
To configure common control buttons:
1. On the Configure menu, click Project.
2. Click the Key Functions tab.
3. Click the Key Functions (C-LCDXL) tab to configure buttons on a CAB6. For each
button, select the access level you want to require to execute the command.
— or —
Click the Key Functions (3-LCD) tab to configure common buttons on all other cabinets.
For each button, select the command and the access level you want to require to
execute the command.
4. Click OK.
See also
Project Parameters - Key Functions (3-LCD) tab
Project Parameters - Key Functions (C-LCDXL) tab
Configuring CPU operation
Configuring CPU operation requires setting properties found on the Operations tab, Timing
tab, and Network tab of the Project Parameters dialog box.
WARNING: Clearing the Standalone Mode check box disables an important life safety
feature of the system and is not recommended except for certain applications.

Caution: Standalone operation must be selected if the panel contains 3-IDC8/4, 3-OPS,
and 3-ZAxx modules using firmware versions earlier than 1.40.

To configure CPU operation:

1. On the Configure menu, choose Project.
2. Click the Operations tab, and then perform the following steps:
Set Market Place for the required market or jurisdiction. Click Market Place
Description to view a list of parameters affected by the Market Place selection.
Clear the Standalone Mode check box only if the project does not require that a rail
module must activate its output in the event that the panel goes into alarm and the
rail module has lost communication with the CPU module.
3. Click the Timing tab, and then perform the following steps:
Set AC Power Delay for the amount of time that the panel is allowed to operate
without AC power before transmitting a trouble signal to a compatible receiver.
Clear the check box if this is not a requirement.
Set Two Stage Time for the amount of time allowed for the panel's two-stage timer
to expire.
Set Test Timeout Period for the amount of time allowed to perform a one-man test.
4. Click the Network tab, and then perform the following steps:
Set Baud Rate for the network data transfer rate. The default setting is 38.4 Kbaud.
Select 19.2 Kbaud only if you experience communication problems between panels.
Set Data Riser for the way the CPU module reestablishes communication with other
panels on the network when a single break or electrical short occurs on the data
riser wiring. This setting must match the physical wiring.
Set Audio Riser for the way the CPU module redistributes the digital audio signals to
other panels on the network when a single break or electrical short occurs on the
audio riser wiring. This setting must match the physical wiring.
5. Click OK.
Configuring the trouble resound timer
When the panel is normal, the panel buzzer is silent. When an event is received by the
panel, the panel buzzer sounds. If the panel is silenced, the panel buzzer stays silent until a
new event is received by the panel or until the trouble resound timer expires.
Note: NFPA 72 requires that an audible trouble signal that has been silenced at the
protected site shall automatically re-activate every 24 hours or less until the active events
are returned to normal. The marketplace setting determines the default trouble reminder
settings.
To configure the trouble resound timer:
1. On the Configure menu, click Project.
2. Click the Timing tab.
3. In the Hour, Minute, and Second boxes, type or select the duration of the trouble
resound timer.
4. Click OK.
Configuring time synchronization
Time synchronization sets the clock time on all systems to one accurate, master time. When
the time is the same on all systems, discrepancies and inaccuracies with events and system
operations are eliminated. With each system using and displaying the same time, history
logs, time stamps, access control systems, etc. all report, store, and use the same time.
This is extremely important for life safety and security system operations. Without
synchronization, logs would report different times for events taking place and access control
systems would allow entry or deny entry at wrong times of the day, which can introduce
doubt with respect to system operation.
To configure time synchronization:
1. On the Configure menu, click Project.
2. Click the Time Synchronization tab.
3. Select the System Time Source that is responsible for controlling the system's
master time. See Project Parameters - Time Synchronization tab for more
information.
4. If you selected "gateway" as your system time source, you must select the port to
which the time synchronization device is connected. Select the port from the drop-
down box that is displayed.
5. Clear the "Check time after each network connection" check box if you do not want
the SDU to check the panel's time after each communication.
Note: This cannot be "cleared" when LCD user interface is selected as the time
synchronization source. See Project Parameters - Time Synchronization tab for
more information.
6. Select the Time Zone that the system (not the computer) is in.
7. Enter the "Ignore time differences less than" time in seconds, minutes, or hours.
Thirty seconds is the default time period. See Project Parameters - Time
Synchronization tab for more information.
8. Click OK.
Configuring the trouble reminder tone
When an operator silences a panel, the system can generate unique tone that only silences
when all troubles are clear. The Trouble Reminder tab lets you specify the length of the tone
(seconds on and off each cycle).
For example, the trouble reminder tone could be set to sound for 0.2 seconds (On = 2) and
pause for 24.8 seconds (Off = 248) each cycle. The default is always off (On = 0 and Off =
255).
The SDU lets you test these settings from your PC by clicking the Test button.
To configure the trouble reminder:
1. From the Configure menu, click Project.
2. Click the Trouble Reminder tab.
3. In the On box, type or select the tenths of seconds for the panel buzzer to sound.
4. In the Off box, type or select the tenths of seconds for the panel buzzer to not
sound.
To test the trouble reminder configuration:
1. Select the Play Tone Continuously During Test check box to have the test pattern
repeat.
2. Click the Test button.
Imposing a delay on off-site reporting of AC power failures
AC power fail delay is a project setting used to delay the messages normally sent to off-
site monitoring stations to report AC power failure. Under normal circumstances, an AC
power failure would be reported immediately. Applying an AC an power fail delay, however,
results in the following change: When AC power is lost, the system waits for a specified
time. Then, if the power remains off when the preset time ends, an AC fail message is sent
to the off-site monitoring station. This scenario may be preferred in areas where brief
power failures occur frequently.
Specific effects of the delay are as follows:
3-OPS off-premises signaling module: When an AC power fail delay is imposed,
3-OPS trouble signaling is automatically delayed.
CPU central processor: The setting does not affect the trouble contacts on the
CPU, however: AC power losses will continue to generate a FirstTrouble event
regardless of whether an AC power fail delay is set.
3-MODCOM AND 3-MODCOMP modem communicators: The AC power fail
delay setting does not directly affect modem transmissions to off-site monitoring
stations, because 3-MODCOM transmissions are controlled through rules
programming. When writing rules for delayed reporting to off-site monitoring
stations, use the CMSFirstTrouble event. For more information on programming 3-
MODCOM transmissions, see CMSFirstTrouble event and 3-MODCOM
programming.
To set or change the delay:
1. On the Configure menu, select Project. This opens the Project Parameters dialog
box.
2. Select the Timing tab.
3. On the Timing tab, check the AC Power Delay check box.
4. Use the hours and minutes boxes to indicate how long to delay reporting of AC
power failures. You can type directly into the boxes or click the arrow buttons to
increase or decrease the values entered.
5. When you have finished setting project parameters, click OK.
To remove the delay:
1. On the Configure menu, select Project. This opens the Project Parameters dialog
box.
2. Select the Timing tab.
3. Clear the AC Power Delay check box.
4. When you have finished setting project parameters, click OK.
See also
ACFail event
Programming a 3-MODCOM
Adding cabinets to the database
Adding a cabinet creates an empty record in the cabinet configuration table that is used for
defining the hardware in each panel in the system. A project database can contain a total of
64 control panels and remote annunciator panels. Each cabinet represents one panel in the
system.
Caution: Inserting cabinets changes the panel address of existing cabinets. If you have
already exported the project database to Gateway-type equipment, your system will not
work as designed. You must re-export the project database.

To add a cabinet to the database:

1. On the Configure menu, click Cabinet.
2. Click Add to create an empty record at the bottom of the cabinet configuration table.
— or —
Click insert to create an empty record in the cabinet configuration table immediately
following the selected cabinet.
3. Change the cabinet label, if required.
4. Select the model of the cabinet used for the panel.
5. Specify the chassis installed for Rail 1, Rail 2, and Rail 3.
6. Click Close.
See also
Cabinet Configuration - Cabinet tab
Customizing SDU operation
Tips for configuring cabinets
Obtain the project's as-built documents, riser diagrams, and any other detail drawings or
engineering documentation that can tell you:
The cabinets and chassis assemblies that make up a panel and their labels
The rail modules that are installed in the cabinets, where they are installed, and their
labels
The control-display modules that are installed in the cabinets, where they are
installed, and their labels
If a networked system, the network routing groups with which a cabinet shares
events and commands
The panel connections to ancillary devices or external command and control
equipment
The battery sizes used for battery backup
Adding cabinets
Add cabinets to the database in the same order that they are connected on the network
data riser. For Class B networks, add the cabinet designated for downloading data over the
network first.
Chassis and rail module configuration
Enter the chassis configuration for each cabinet enclosure before adding any rail modules.
Delay adding any modules until all chassis configurations have been added and you have
saved your work.
Adding rail modules
Add all rail modules and control-display modules in one cabinet before moving on to the next
cabinet. Delay configuring any rail modules until all rail modules have been added and you
have saved your work.
Checking your work
Periodically compare the data you are entering in the database against available
engineering drawings. It is very important that the data you enter reflects the as-built
configuration of the system.
Always double check to make sure you are configuring the correct cabinet. You wouldn't
want to configure a large number of rail modules just to find out later that you didn't add
them to the correct cabinet.
Adding control-display modules
Control-display modules provide operator interfaces for accessory devices. Control-display
modules are added to the database according to the rail-slot position of the rail module on
which they are mounted.
To add a control-display module:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the rail module.
3. Click the Modules tab, and then click the Operator Layer tab.
4. Locate the control-display module's rail-slot position, select the corresponding LRM
Type list, and then click the required model.
Click 12SW/12LED if the control-display module has twelve LED-switches with one
LED per switch.
Click 12SW/24LED if the control-display module has twelve LED-switches with two
LEDs per switch.
Click 3SW/3LEDx6 if the control-display module has six groups of three LED-
switches with one LED per switch.
Click 3SW/4LEDx4 if the control-display module has four groups of three LED-
switches with one LED on the top and bottom switches and two LEDs on the middle
switch.
5. In the adjacent LRM Label boxes, type the name given to the control-display
module.
6. Click Close to apply the changes and close the Cabinet Configuration dialog box.
Adding rail modules
Rail modules plug directly into the rail chassis and provide the hardware interface to the
boxes devices. Rail modules are added to the database according to their rail-slot position.
To add a rail module:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the rail module.
3. Click the Modules tab, and then click the Hardware Layer tab.
4. Locate the rail module's rail-slot position, select the corresponding LRM Type list,
and click the required model.
5. In the adjacent LRM Label box, type the name given to the rail module.
6. Click Close.
CAB6 IP configuration settings
When a new CAB6 is added to the SDU, IP services automatically become available. The
SDU assigns default values to the services, which can be customized later.
When an ETH series Ethernet card is installed on the panel's CPU, you can configure the
panel for communication with central monitoring stations, FireWorks UL Listed workstations,
and email servers through the IP services. The type of Ethernet card that is installed
determines which IP services are supported.
Prerequisite
Before starting to configure the IP configuration settings, you will need to gather the
settings from the local IT administrator. Through the My-Eddie website, you can download
the EST3X IP Dialer-Email Configuration Worksheet (P/N 3102338-EN) that will guide you
through the information to gather. To access the website, enter my-eddie.com in your web
browser, and then locate the worksheet in Media Type > Installation Sheets.

To configure the IP configuration settings:

1. After gathering the prerequisite information, on the Configure menu, click Cabinet.
2. Select a CAB6 cabinet, and then click the IP Dialer - Email tab. Note that this tab
appears only when you select a CAB6 cabinet.
3. Click the IP Configuration tab.
4. Configure the DHCP settings using one of the following methods:
To automatically assign an IP address, select the Obtain an IP Address Automatically
radio button.
— or —
To assign a static IP address, select the Use the Following IP Address radio button, and
then enter:
IP address: 192.168.1.3
Subnet Mask: 255.255.255.0
Default gateway: 0.0.0.0
5. If you chose to automatically assign the IP address, you can check the Supervise
DHCP check box to supervise connectivity with the DHCP server. The panel
generates a trouble after 60 minutes if connectivity is lost.
6. Configure the DNS server address using one of the following methods:
To automatically assign a DNS address, select the Obtain DNS Server Address
Automatically radio button.
— or —
To assign a static DNS address, select the Use the Following DNS Server Addresses,
and then enter:
Preferred DNS Server: 0.0.0.0
Alternate DNS Server (optional): 0.0.0.0 (if the panel fails to connect to the
preferred DNS server, it attempts to connect to the alternate server)
If you chose to automatically assign the DNS server address, you can check the
Supervise DNS check box to supervise connectivity with the DNS server. The panel
generates a trouble after 90 minutes if connectivity is lost.
7. In the C-CPU Ethernet Card list, select the Ethernet card type installed in the
 cabinet.
Prog/Diag/ECP: Select this when an ETH1 card is installed. It supports panel
programming, and communication with FireWorks UL Listed workstations.
Prog/Diag/ECP/IPDialer: Select this when an ETH2 card is installed. It supports
ETH1 features plus communication with central monitoring stations.
Prog/Diag/ECP/IPDialer/Email: Select this when an ETH3 card is installed. It
supports ETH1 and ETH2 features plus communication with email servers.
9. In the Port box, enter the port number used for SDU communication with the panel
for programming and diagnostics. The default setting is 2501.
10. Click Close.
See also
Ethernet terminology
Basic network addressing
Subnet masks
Deleting cabinets from the database
Deleting cabinets from the cabinet configuration table removes the cabinet and any objects
associated with the cabinet from the project database. After deleting a cabinet, the SDU
adjusts the cabinet numbers of the remaining cabinets accordingly.
Caution: Deleting cabinets changes the panel address of existing cabinets. If you have
already exported the project database to Gateway-type equipment, your system will not
work as designed. You must re-export the project database.
Note: Depending on the size of the database, you might experience a short delay before
the cabinet is deleted.
To delete a cabinet from the database:
1. From the Configure menu, click Cabinet.
2. Select the cabinet you want to delete.
3. Click Delete.
The SDU displays a confirmation box asking you if the cabinet you selected is
indeed the cabinet you want deleted. If you are sure of your selection, click OK.
4. Click Close.
Configuring the battery charging circuit
Batteries are required to provide standby power to the panel when AC power is removed
from the primary and booster power supplies. To configure the battery charging circuit you
set the Battery Type option for setting closest to the total capacity of the batteries installed
in the cabinet.
Caution: The total capacity of standby batteries installed in a single cabinet cannot exceed
60 Ah. Standby battery capacities greater than 60 Ah will damage the battery charging
circuit.

To configure the battery charging circuit:

1. From the Configure menu, click Cabinet.
2. Select the cabinet.
3. Click the Option tab.
4. Set the Battery Type option according to the capacity of the battery installed in the
cabinet.
5. Click Close.
Selecting module firmware versions
When you select firmware versions on the MicroCode tab, the SDU uses the versions you
select to compile the database and download it to the rail modules when you initiate
communications.
Caution: Before downloading the database, be sure to first select the version of firmware
you want to use for each rail module.
Tip: For optimal system performance always use the latest version of firmware.
To designate the version of microcode used:
1. On the Configure menu, click Project.
2. Click the MicroCode tab.
3. For each component in the selected cabinet, select the Microcode Type and then
select the version of code you want to use in Available Versions.
Note: The selected application and bootloader versions apply to all cabinets in the
project.
4. Click OK.
Sending events to a CDR-3 Bell Coder
A panel's serial port can serve as a connection for sending events to a CDR-3 Bell Coder.
Events sent to the CDR-3 are selected by their event type. Only events generated from
eligible panels specified in the State property setting are able to be sent to the CDR-3.
Notes
If a printer is connected to the same serial port as the CDR-3 then Baud Rate must
be set for the baud rate selected on the CDR-3. You must also change the printer's
baud rate settings to match the CDR-3.
A serial port set for CDR3/Printer cannot be used as a download connection. The
modular phone jack, however, can still be used to download data files.
To send events to a CDR-3 Bell Coder:
1. From the Configure menu, click Cabinet.
2. Select the cabinet that connects to the printer.
3. Click the Ports tab, and then click the tab for the serial port used for the coder
connection.
4. Perform the following steps:
Set Port Type for CDR-3/Printer or CDR-3/Supervised Printer, depending on the
application.
Set Baud Rate for the baud rate required by the CDR-3. Refer to the technical
documentation supplied with the CDR-3.
Select the check box next to the events you want sent to the coder.
5. Click Close.
See also
Cabinet Configuration - Ports tab
Sending events to an ancillary printer
A panel's serial port can serve as a printer connection for making a hard copy listing of
system activity. Events sent to the printer are selected by their event type. Only events
generated from eligible panels specified in the State property setting are able to be sent to
the printer.
Note: If a CDR-3 Bell Coder is connected to the same serial port as the printer then Port
Type must be set for CDR3/Printer. You must also change the printer's parity setting to
even parity.
To send events to an ancillary printer:
1. From the Configure menu, click Cabinet.
2. Select the cabinet that connects to the printer.
3. Click the Ports tab, and then click the tab for the serial port used for the printer
connection.
4. Perform the following steps:
Set Port Type for Printer or Supervised Printer, depending on the application.
Set Baud Rate for the baud rate required by the printer. Refer to the technical
documentation supplied with the printer.
Select the check box next to the events you want sent to the printer.
5. Click Close.
See also
Sending events to a CDR-3 Bell coder
Cabinet Configuration - Ports tab
Sending events to an external interface
A panel's serial port can serve as a gateway for sending events to external interfaces, such
as command and control equipment or remote diagnostic devices. Events sent to external
interfaces are selected using network routing groups. All events generated by the selected
group of panels will be routed through the gateway to the external interface equipment.

To send events to an external interface:

1. On the Configure menu, click Cabinet.
2. Select the cabinet that connects to the external interface.
3. Click the Ports tab, and then click the tab for the serial port used for the gateway
connection.
4. Perform the following steps:
Set Port Type for the gateway type required by the external interface equipment.
Refer to the technical documentation supplied with the external interface equipment.
Set Baud Rate for the baud rate required by the external interface equipment. Refer
to the technical documentation supplied with the external interface equipment.
Set Primary for the network route whose events are primarily routed to the external
interface equipment.
Set Alternate for the network route whose events are routed to the external
interface equipment as an alternate to the primary setting.
5. Click Close.
See also
Cabinet Configuration - Ports tab
Creating a partition route
A partition route contains a group of partitions. It is used at the following times:
When configuring cabinets, in order to indicate whose location messages will be
displayed or printed by the local panel
When configuring keypad display modules, to indicate the partitions whose location
messages they will display
When configuring printer ports, to indicate the partitions whose location messages
they will display
Tip: You can access the Partition Routing dialog box from the Network Routing tab of the
Cabinet Configuration dialog box, or from the KPDISP Filtering tab of the 3-SAC and SPUR
Configuration dialog box.

To create a partition route:

1. From the Configure menu, click Cabinet. This opens the Cabinet Configuration dialog
box.
2. Select the Network Routing tab.
3. Click the Partition Routing button. This opens the Partition Routing dialog box.
4. Click New.
5. Enter a label for the new partition route, then click OK.
By default all partitions are included in the group.
6. In the right pane, clear the partitions you want to exclude from this route.
7. When you have finished, click Close.
Displaying location messages
To set a panel's message display options:
1. On the Configure menu, click Cabinet. This opens the Cabinet Configuration dialog
to the Cabinet tab.
2. Select the cabinet from the table.
3. Click the Options tab.
4. Under Display Enabled, select the appropriate check boxes.
5. Click Close.
See also
Cabinet Configuration - Options tab
Configuring control-display modules
Control-display modules form the operator layer to the optional supplementary control
circuits installed in the system.
Note: When setting control-display module properties, the index numbers on the left side of
the dialog correspond to the reference designations given the control-display module
components. Switches and LEDs (light-emitting diodes) start with SW1 and LED1 at the
top, respectively, and continue in consecutive order until reaching the bottom.
To configure a control-display module:
1. On the Configure menu, click Cabinet.
2. On the Cabinet tab, select the panel that contains the control-display module.
3. On the Modules tab, select the module on the Operator Layer tab and click LRM
Config.
4. In the dialog box, type a name in the label boxes that corresponds to the control-
display module switch or LED.
5. If a switch, set the Switch Type boxes for the type of switch operation desired.
6. Click OK.
See also
Control-display Module Configuration
Configuring a 3-FTCU
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-FTCU being configured and then click the
Modules tab.
3. On the Hardware Layer tab, select the 3-FTCU, and then click LRM Config.
4. Set the Off Hook Timer box for the amount of time that the phone handset is allowed
to remain off-hook and not used before the 3-FTCU signals a trouble.
5. Set the Scroll Timer box for the amount of time that the display cursor highlights
calls on the calls pending list.
6. Set the Inactivity Timer box for the amount of time that must pass before the 3-
FTCU resumes scrolling through the calls pending list after an operator presses the
Review Pending switch.
7. Under Comm Class, click Class A or Class B depending on the telephone riser
circuit performance requirement.
8. In Telephone Call In Route, select the network routing that reflects how the riser is
wired.
Configuring a 3-IDC8/4 module
The 3-IDC8/4 has eight dedicated Class B circuits whose properties can be individually set
for connecting traditional (non-addressable) 2-wire and dry contact initiating devices. Four
of the circuits (1, 2, 5, and 6) can also be configured for connecting supervised output
devices.
Note: The numbers on the left side of the 3-IDC8/4 Configuration dialog correspond to the
circuit numbers referenced on the 3-IDC8/4 boxes wiring connector. For example, 1
corresponds to IDC/NAC 1.
To configure a 3-IDC8/4 module:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-IDC8/4 being configured and then click the
Modules tab.
3. On the Hardware Layer tab, select the 3-IDC8/4, and then click LRM Config.
4. For each circuit number, click the Hard Zone Type, select the circuit application, and
then click the required device type.
5. Click OK.
See also
3-IDC8/4 jumper settings
3-IDC8/4 Configuration
Configuring a 3-OPS module
You can configure the 3-OPS for three different types of off-site signaling circuit
applications.
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-OPS you are configuring, and then click the
Modules tab.
3. On the Hardware Layer tab, select the 3-OPS, and then click LRM Config.
4. Under 3-OPS Type, click the required circuit application.
Click Local Energy Municipal Box to provide a single alarm output signal for
connecting to a local energy municipal box.
Click Three Reverse Polarity Circuit to provide three independent reverse polarity
circuits for transmitting alarm, trouble, and supervisory signals to a compatible
receiver.
Click Single Reverse Polarity Circuit to provide a single reverse polarity circuit for
transmitting an alarm signal to a compatible receiver.
5. Click Close.
Configuring a 3-ZAxx amplifier module
The 3-ZA15, 3-ZA20, 3-ZA30 and 3-ZA40/xx amplifier modules provide a speaker circuit
and a 24 VDC notification appliance circuit. The 3-ZA90/xx provides only a speaker circuit.
Any model amplifier can be designated as a backup amplifier.
Caution: The backup amplifier's output rating must be equal to or greater than the largest
amplifier in the cabinet.
Note: A jumper setting on the amplifier module determines the output signal voltage that the
amplifier produces, not the amplifier selection in the SDU.
To configure the 3-ZAxx amplifier module:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the amplifier module being configured and then click
the Modules tab.
3. On the Hardware Layer tab, select the amplifier module, and then click LRM Config.
4. If the amplifier module is a 3-ZA20/xx or 3-ZA40/xx, in the Amplifier Output list,
select the required device type.
If strobes are connected to the amplifier's 24 VDC NAC output circuit, click
VISIBLE.
If horns are connected, click AUDIBLE.
If you want to automatically activate the connected devices on the first alarm, click
COMMONALARMOUTPUT.
5. In the Assigned to ASU in cabinet list, click the 3-ASU that is the source of the
network audio riser connected to the amplifier.
6. Select the Backup Amplifier check box if the amplifier's function is to back up the
other amplifiers in the same cabinet.
7. Click OK.
See also
3-ZAxx Amplifier Configuration
Configuring a 3-MODCOM module
This topic provides instructions for configuring a 3-MODCOM or 3-MODCOMP module. You
can configure a new device by performing all procedures in the order in which they are
presented. If you are making limited changes to an existing device, use the links below to
quickly access the procedure that you need.
Content
Access the Configure 3-MODCOM
Configure public service telephone network settings
Configure line properties
Enter or change the dial-in telephone number
Configure counters and timers
Add a new digital alarm communications receiver
Configure an existing digital alarm communications receiver
Add a new account
Configure an existing account

To access the Configure 3-MODCOM dialog box:

1. Click Configure, and then select Cabinet.
2. Select the cabinet that contains the 3-MODCOM to be configured, then click the
Modules tab.
3. On the Hardware Layer tab, select the 3-MODCOM, and then click the LRM Config
button. The Configure 3-MODCOM dialog box opens to the General tab.
4. Configure the General, Receivers, and Accounts properties as described below.
General properties
Note: If you need additional information while configuring the general properties of the 3-
MODCOM, see Configure 3-MODCOM - General tab

To configure the public service telephone network properties:

1. In the Configure 3-MODCOM dialog box, click the General tab.
2. In the DACT Settings list, select the 3-MODCOM properties as Fully Programmable
or NFPA 72 Central Station, Remote Station.
3. If you selected 72 NFPA Central Station, Remote Station go to step 5
4. If you selected Fully Programmable, check the Line 1 Installed and Line 2 Installed
check boxes if phone lines are connected to the lines.
5. Check the Enable Supervision check box to indicate whether Line 1 and Line 2 (if
installed) are supervised.
6. Check the Enable Force Dial check box if you want to enable the module to dial the
off-site monitoring station without waiting for a dial tone. This setting affects both
Line 1 and Line 2.
This is used when the protected site is located in an area where telephone dial
tones are irregular or nonexistent.
Note: Refer also to the configuring counters and timers section. Wait Time Before
Force Dialing property controls how long the 3-MODCOM will wait for a dial tone
before initiating a call.
7. Check the Ignore monitor events when determining system status check box if you
want to suppress abnormal condition reports in response to monitor events. This
might be necessary if monitor events occur frequently as part of normal system
operation. Do not check the check box if you want to allow the MODCOM to report
monitor events as abnormal.
Back to top
To configure the line properties:
1. In the Configure 3-MODCOM dialog box, click the General tab.
2. From the Default Dialing Method list, select whether the public telephone system
requires tone or pulse dialing.
3. From the Ring Cycle Type to Detect list, select the ring pattern to which the module
should respond.
Back to top
To enter or change the dial in telephone number:
1. In the Configure 3-MODCOM dialog box, click the General tab.
 2. In the Dial In Phone Number boxes, enter the country code, area code, and
telephone number of the telephone line to which Line 1 is connected.
Back to top

To configure counters and timers:

1. In the Configure 3-MODCOM dialog box, click the General tab.
2. Enter the Auto-Answer Ring Cycle Count value to indicate how many ring cycles
must occur before the module responds.
3. Enter the Wait Time to Detect Dial Tone value to indicate how long the module
should wait for a dial tone when attempting to make a call. The value should be at
least 20.
The module's response when this wait time elapses depends on how it is configured.
For example, the module could switch over and attempt the call on the second line.
4. Enter the Wait Time for Calling Party Disconnect value to indicate how long the
module should wait before disconnecting an ongoing incoming call.
5. Enter the Wait Time for Line Cut Monitor Sensing value to indicate how long the
module should wait before annunciating a line fault.
6. If the module is enabled for force dialing, indicate in the Wait Time Before Force
Dialing box how long the module should wait for a dial tone before force dialing.
Notes
If force dialing is enabled, set Wait Time Before Force Dialing to at
least 1.
If force dialing is not enabled, force dialing will be used only if all
calling attempts have failed. In this case, the module will attempt to
complete the call using force dialing, just as it would if force dialing
were enabled.
7. To set up digital alarm communications receivers at the central monitoring station,
continue with the next section. If you have finished configuring the MODCOM, click
OK to close the dialog box.
Back to top
Receiver properties
Note: If you need additional information while configuring receiver properties, see Configure
3-MODCOM - Receivers tab and Receiver Properties.

To add a new receiver:

1. In the Configure 3-MODCOM dialog box, click the Receivers tab.
2. Click insert. The Receiver Properties dialog box opens.
3. In the Receiver box, enter a Receiver Label that will identify the receiver in the SDU.
4. Enter a description.
5. Enter the receiver's primary (Phone Number 1) and secondary (Phone Number 2)
telephone numbers.
6. From the Receiver Protocol list, select the protocol that is required by this receiver.
7. In the Counters and Timers box, enter the Max Dial Attempts value to indicate how
many times the module should try to connect before switching to the other line.
8. Enter the Wait Time On-Hook Between Attempts To Same Number value to indicates
how long the module should wait before trying to connect to the other line.
9. In the Receiver Default Messages box, enter message text for each event type. To
set all event messages to the default code for the selected protocol, click Set
Messages to Default Settings.
10. Click OK to close the Receiver Properties dialog box.
11. Click OK to close the Configure MODCOM dialog box.
Back to top
To configure an existing receiver:
1. In the Configure 3-MODCOM dialog box, click the Receivers tab.
2. Click Edit. The Receiver Properties dialog box opens.
3. Make any changes needed, and then click OK to close the Receiver Properties
dialog box.
4. Click OK to close the Configure MODCOM dialog box.
Back to top
Account properties
Note: If you need additional information while configuring account properties, see Configure
3-MODCOM - Accounts tab and Account Properties.

To add a new account:

1. In the Configure 3-MODCOM dialog box, click the Accounts tab.
2. Click insert. This Account Properties dialog box opens.
3. In the Account Name box, enter an Account Label that will identify the account in the
SDU.
4. Enter a description.
5. From the Receiver Label list, select the receiver associated with this account.
6. Enter the CMS Account Number for the central monitoring station, which identifies
the protected site.
7. Check the Auto Generate Events check box to let the SDU automatically generate
your Contact ID strings for each object.
8. In the Dial Test Timers box, check the Enable Dial Test Timers check box to apply a
schedule for sending test messages.
9. Enter the Dial Test Interval value to indicate how frequently test messages should be
sent..
10. Check the Dial Test Time Of Day check box if you want to schedule a specific time
of day for test messages, and then enter the time of day. For example, 01:00 AM.
11. Click OK to close the Account Properties dialog box.
12. Click OK to close the Configure MODCOM dialog box
Back to top
To configure an existing account:
1. In the Configure 3-MODCOM dialog box, click the Accounts tab.
2. Click Edit. The Account Properties dialog box opens.
3. Make any changes needed, and then click OK to close the Account Properties
dialog box.
4. Click OK to close the Configure 3-MODCOM dialog box.
Back to top
Configuring a 3-SAC module
This topic shows you how to configure a 3-SAC bus module and the devices connected to
it. You can configure devices immediately after adding them to the SAC bus configuration
table, or you can wait until you have finished adding devices.
To configure a 3-SAC module:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-SAC, then click the Modules tab.
3. Select the 3-SAC module to be configured, then click LRM Config. This dialog box is
used to configure both the 3-SAC module and the devices that are added to it.
4. Click 3-SAC Communication Class and, from the list that appears, indicate whether
the SAC bus is wired as Class A or Class B.
5. Click 3-SAC Baud Rate, and choose the baud rate that the 3-SAC uses to
communicate with other devices on the SAC bus.
6. Add devices to the SAC bus, as follows:
In the first available row in the configuration table, select the Device Type boxes,
then choose the device to be added.
Tip: If you want to add more than one device type at a time, check Add Multiple. Then
when you choose a device type from the drop-down, the system displays a Number to
Add popup that allows you to specify how many of that device type you want to add.
After you select the number and click OK, the system adds that number of devices to the
table. This functionality is available for the CRC, CRCXM, and KPDISP device types.
7. In the Device Label boxes, enter the name used to identify the device in the
database.
Repeat for all devices to be added to the 3-SAC.
8. If you have finished configuring the 3-SAC and the devices connected to it, click OK.
Otherwise, continue with the next procedure.
To configure the devices connected to the 3-SAC module:
1. In the 3-SAC and SPUR Configuration dialog box, select the device you want to
configure.
2. If the device is a CRC or CRCXM, the system adds the following tabs to the dialog
box:

If the device is a KPDISP, the system adds these tabs:

3. Supply values for the options on each tab. Click any link below for specific
information.
For configuring a CRC or CRCXM:
3-SAC and SPUR Configuration - CRC Cmd Lists tab
3-SAC and SPUR Configuration - CRC Config tab
3-SAC and SPUR Configuration - CRC Input Circuits tab
For configuring a KPDISP:
3-SAC and SPUR Configuration - KPDISP Config tab
3-SAC and SPUR Configuration - KPDISP Filtering tab
4. When you have finished, click OK.
See also
Defining an object's message annunciation routes
Configuring a CRC module
Most card reader controller settings are configured in the SDU. Door schedules and timers,
however, are set using the ACDB. For information on creating and configuring access
schedules and door timers, see the ACDB online help. For other configuration tasks, use
the procedures and links below.

To configure a CRC:
1. On the Configure menu, choose Cabinet.
2. Select the cabinet that contains the 3-SAC, then click the Modules tab.
3. On the Modules tab, select the 3-SAC, then click the LRM Config button. This opens
the 3-SAC and SPUR Configuration dialog box.
4. Select the CRC from the table on the left.
5. Set the configuration options on each of the tabs. Click the links below for
information specific to each tab.
6. When you have finished configuring the CRC, click OK to close the 3-SAC and
SPUR Configuration dialog box. Click Close to close the Cabinet Configuration dialog
box.
To restore a CRC to its initial factory condition:
1. When downloading the 3-SAC database, click the Remove from 3-SAC button,.
This action returns all SDU and ACDB settings to the factory defaults, and clears all
cardholders, schedules, and holidays. The construction card will work again, but no other
cardholders will be able to gain access.
See also
3-SAC and SPUR Configuration - CRC Config tab
3-SAC and SPUR Configuration - CRC Cmd Lists tab
3-SAC and SPUR Configuration - CRC Input Circuits tab
Configuring a KPDISP Keypad Display module
This topic provides background material and instructions for configuring a Keypad Display. If
you are configuring a new device, perform all procedures in the order in which they are
presented. Otherwise, click any link below to go directly to the procedure that you need.
Setting up the general properties
Configuring keypad display alert signals
Filtering the display of event messages
Restoring default settings and removing users from a keypad display
Configuring a Signature loop controller module
To configure a Signature loop controller module:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the loop controller being configured and then click
the Modules tab.
3. On the Hardware Layer tab, select the loop controller, and then click LRM Config.
4. Under Loop 1, perform the following steps:
Select the Enable Mapping check box.
Set the signaling line circuit supervision for Class A or Class B circuit performance
depending on the actual wiring configuration of the signaling line circuit.
5. Under Default Values, for each type of detector specify the attribute values to use
when adding the detector to the signaling line circuit.
6. Click Loop1 Detectors tab, then click Add Detectors.
7. In row 1, perform the following steps:
Click the Model box, and then click the model name of the device being added.
Click the Base box, and then click the type of base that provides the mounting for
the detector.
Click the Personality Code box, and then click the appropriate personality code for
the application (3-SDDC1 and 3-SSDC1 only).
In the Quantity box, type the number of identical detector/base combinations
connected to the signaling line circuit.
8. In subsequent rows, add different detector/base combinations or click OK to add
the devices to the configuration table. When you are done, click OK. The SDU
automatically enters the device's current default attributes to the configuration table
as specified on the Parameters tab.
9. For each detector, enter its Serial Number and location Label Text.
10. Click Loop1 Modules tab, then click Add Modules.
11. In row 1, perform the following steps:
Click the Device Type box, click the circuit application, and then click the appropriate
device type for the device you are adding.
Click the adjacent Model box, and then click the model name of the device.
Click the adjacent Personality Code box, and then click the appropriate personality
code for the application.
In the Quantity box, type the number modules connected to the signaling line circuit
that have the same attributes.
12. In subsequent rows, add modules as needed. When you are done, click OK. The
SDU automatically enters the module's current default attributes to the configuration
table as specified on the Parameters tab.
13. For each module, enter its Serial Number and location Label Text.
14. If you are configuring a dual loop controller, repeat steps 4 through 13 for Loop 2.
15. Click Close.
See also
Signature Series Configuration - Detectors tab
Signature Series Configuration - Modules tab
Adding Signature detectors to the database
To add Signature detectors to the database, you must specify their descriptive name or
model number, the type of base on which they are mounted, and the quantity.
To add detectors to the Signature database:
1. On the Tools menu, select Signature Series, then click Configure.
2. On the Select a Signature Loop Controller for Configuration dialog box, select the
cabinet and the loop controller card, then click OK.
3. In the Signature Series Configuration dialog box, click Loop 1 Detectors tab, then
click Add Detectors.
4. In the Add Detectors to Loop dialog box, click the Model box in row 1 , and then
click the model name of the device being added.
5. Click the Base box, and then click the type of base that provides the mounting for
the detector.
6. Click the Personality Code box, and then click the appropriate personality code for
the application.
7. In the Quantity box, type the number of identical detector/base combinations
connected to the signaling line circuit.
8. In subsequent rows, add different detector/base combinations or click OK to add
the devices to the configuration table.
When you click OK, the SDU automatically enters the default attributes of the
current device in the configuration table as specified on the Parameters tab.
9. For each detector, enter the serial number in the Serial Number box, and the
location in the Label Text box.
10. If you are configuring a dual loop controller, repeat steps 3 through 9 for Loop 2.
11. Click OK.
See also
Programming Signature detector bases
Adding Signature modules to the database
To add Signature modules to the database, you must specify their device type, model, and
personality code. The module's device type is determined by the circuit application.
Note: SIGA-IM modules are added to the detector configuration table instead of the
module configuration table.

To add Signature modules to the database:

1. On the Tools menu, select Signature Series, then click Configure.
2. On the Select a Signature Loop Controller for Configuration dialog box, select the
cabinet and the loop controller card, then click OK.
3. Click Loop 1 Modules tab, then click Add Modules.
4. In row 1, click the Device Type box, click the circuit application, and then click the
appropriate device type for the device being added.
5. Click the adjacent Model box, and then click the model name of the device.
If the model requires two address, "X2" appears at the end of the row.
6. Click the adjacent Personality Code box, and then click the appropriate personality
code for the application.
7. In the Quantity box, type the number modules connected to the signaling line circuit
that have the same attributes.
8. In subsequent rows, add different modules or click OK to add the devices to the
configuration table.
When you click OK, the SDU automatically enters the device's current default attributes
to the configuration table as specified on the Parameters tab.
9. If you are configuring a dual loop controller, repeat steps 3 through 8 for Loop 2.
10. Click OK.
See also
Device types used with active latching input circuits: Gatevalve, Power, Security,
Supervisory, Tamper, Temperature
Device types used with alarm input circuits: GenAlarm, Heat, Pull, Smoke, SmokeVfy,
StageOne, Waterflow
Device types used with non-latching input circuits: 24VRiser, AudioRiser,
AuxPowerSupply, DamperFeedback, DoorFeedback, FanFeedback, Guard, Monitor,
PhoneRiser
Device types used with nonsupervised output circuits: NonsupervisedOutput,
NSCommonAlarmOutput, NSCommonMonitorOutput, NSCommonSupervisoryOutput,
NSCommonTroubleOutput
Device types used with security input circuits: Security24Hour, SecurityDay,
SecurityIMonitor, SecurityInterior, SecurityPerimeter, SecurityPMonitor
Device types used with supervised output circuits: Audible, CommonAlarmOutput,
CommonMonitorOutput, CommonSupervisoryOutput, DamperControl, DoorControl,
FanControl, Firephone, SupervisedOutput, Visible
Understanding SIGA2 devices
The following SIGA2 intelligent analog devices can detect CO (carbon monoxide) levels
within a controlled area.
COS: Uses a CO sensor to detect carbon monoxide from any source of combustion
and analyzes the sensor data to determine when to initiate a CO life-safety alarm.
It is not intended to detect fire, smoke, or any other gas.
HCOS: Contains a fixed-temperature heat sensor to detect heat from fire, and a CO
sensor to detect carbon monoxide from any source of combustion. The detector
analyzes the heat and CO sensors independently to determine whether to initiate a
heat/fire alarm, a CO life-safely alarm, or both. It is not intended to detect smoke,
or any other gas. It does not by itself provide smoke or fire protection. For life
safety situations, use ionization or photoelectric smoke detectors or a combination
of these along with the SIGA2-HCOS.
PCOS: Uses an optical sensing chamber to detect smoke, and a CO sensor to
detect carbon monoxide. The detector analyzes the smoke and CO sensors
independently to determine whether to initiate smoke/fire alarm, a CO life-safely
alarm, or both. The SIGA2-PCOS detects carbon monoxide gas from any source of
combustion. It is not intended to detect any other gas.
PHCOS: Contains a photoelectric smoke sensor, a fixed-temperature heat sensor,
and a carbon monoxide sensor. The detector analyzes the smoke and heat sensors
independently from the CO sensor to determine whether to initiate a smoke/fire
alarm, a CO life-safety alarm, or both. The SIGA2-PHCOS is designed to detect
carbon monoxide gas from any source of combustion. It is not intended to detect
any other gas.
In addition to the CO devices, the SIGA2 version of the PHS adds functionality:
PHS: Contains a photoelectric smoke sensor and fixed-temperature heat sensors.
The detector analyzes the data from each sensor to determine whether to initiate an
alarm. Unlike the original Signature series PHS, the SIGA2 series PHS can report
the heat and photo elements as separate event types (independent - latched, or
independent - nonlatched), or together (combo alarm - latched); select this setting
using the personality code for the device. The SIGA2-PHS operates in either
primary or alternate mode, allowing you to change the detectors from
supervisory/alarm to alarm/alarm and vice-versa based on alternate sensing mode
settings.
A Temporal Pattern Generator module and sounder base are also available:
TCDR: An addressable device that generates sound patterns for CO and fire
signals for the Signature AB4GT sounder base.
AB4GT: The sounder base required to support CO sound patterns.
SIGA2 devices also provide a form redesign of the following intelligent analog devices,
without affecting function.
HFS: Contains a fixed-temperature heat sensor to detect heat from fire.
HRS: Contains rate-of-rise and fixed-temperature heat sensors to detect fire.
PS: Uses an photoelectric smoke sensor to detect smoke.
See also
Configuring CO Devices
Configuring CO devices
The SDU supports the following CO features:
You can set the SIGA2 CO personality codes to COAlarm (latching), COSupervisory
(latching or nonlatching), or COMonitor (nonlatching).
You can write a rule using the CO device type (COAlarm, COSupervisory,
COMonitor).
You can disable devices containing CO sensors by disabling the entire detector, just
like any other device.
You can put the CO detector in a service group. You can also write commands that
use an accelerated mode when testing a CO device, to allow a faster CO detection
for the test (GasAcceleratedResponseOn, GasAcceleratedResponseOff).
You can write a rule that programs the correct audio tone for CO device activations
in the US and Canadian Marketplaces. For details, see Programming a TCDR for
CO.
CO detectors have a lifespan of six years. They report the number of months left
until end of life (EOL) on the LCD and in maintenance reports. When CO detector
has less than six months until EOL, the LCD displays a maintenance alert. When the
months until EOL reaches zero, the LCD restores the maintenance alert and issues
an EOL trouble for the device. For combination detectors, the system detects and
reports dirtiness levels independently of the CO number of months until EOL.
Notes
For SIGA2 devices you must use a 3-SSDC1 or 3-SDDC1 loop controller running
application code version 04.00.00 and bootloader code version 04.00.00, or later.
In the Canadian Local and Proprietary marketplace, do not add CO devices to a
AND, Matrix, or Zone group. When the group activates, CO devices in the group
would not be correctly prioritized.
To configure a CO device:
1. In the Cabinet Configuration dialog box, select the cabinet, and then click the
Modules tab.
2. Select the 3-SxDC1 loop controller where the SIGA2 device resides, and then click
the LRM Config button.
3. For CO detectors, click the Loop Detectors tab.
4. Click the Add Detectors button.
5. In the Model column, select the CO detector you are adding from the drop-down list.
The SDU fills in the corresponding Detector Type, Base, and Personality Code.
Change the base or personality code as necessary, and then click OK.
 6. On the Loop Detectors tab, scroll to the right and in CO Setting set the device to
COAlarm, COMonitor, or COSupervisory.
7. For the TCDR, click the Loop Modules tab.
8. Click the Add Modules button. In Device Type, select Supervised Output > Audible.
9. In the Model column, select TCDR from the drop-down list. The SDU fills in the
corresponding Personality Code 70. Click OK.
10. Click Close in the Signature Series Configuration dialog box.
See also
Understanding SIGA2 devices
Programming a Signature TCDR for CO
COAlarm event
COMonitor event
COSupervisory event
Programming Signature detector bases
Configuring a SIGA2-PHS device
The SIGA2-PHS lets you set the photo and heat sensors to activate individually, or together
in combination. Note that you cannot use the sensors independently on the original SIGA-
PHS device, or with a loop controller using microcode/bootloader versions earlier than 4.0.
To configure a SIGA2-PHS:
1. In the Cabinet Configuration dialog box, select the cabinet and click the Modules tab.
2. Select the 3-SxDC1 loop controller where the SIGA2 device resides and click the
LRM Config button.
3. Click the Loop Detectors tab.
4. Click the Add Detectors button.
5. In Model, select PHS from the drop-down list. The SDU fills in the corresponding
Detector Type, Base, and default Personality Code. Click the Personality drop-down
to change the default if needed. Click OK.
6. On the Loop Detectors tab, scroll to the right and set the Operation option, which is
the primary or default behavior of the system. Valid options include:
Photo/Heat is Alarm (for both sensors)
Photo is Supervisory and Heat is AlarmHeat
Photo is AlarmSmoke and Heat is AlarmHeat
The following table shows the different events the system generates upon sensor
activation, based on the settings for the primary Operation option.

Table 1: SIGA2-PHS Operation configuration settings and event activation

Operation set to Device type Photo event Heat event
Photo/Heat is Alarm Smoke Alarm Alarm
(combined configuration)

Photo is Supervisory | Heat is Supervisory Supervisory AlarmHeat

AlarmHeat
(split configuration)
Photo is AlarmSmoke | Heat is Smoke AlarmSmoke AlarmHeat
AlarmHeat
(split configuration)

Note: If you assign the PHS a split configuration in the SDU, but your physical device is
actually the original SIGA-PHS, when you map the Signature loop, the loop controller
resets the device to SIGA-PHS attributes, flags it as an error on the map, and
annunciates a "bad type" trouble to the panel that includes the device address.
7. Set the Alternate Operation option, which takes effect when a rule you
program using the Alternate Sensing or Alternate Sensitivity command executes, or
 when the user issues the Alternate Sensing command through the front panel. Valid
options include:
Photo/Heat is Alarm (for both sensors; available only when the primary
Operation option is set to "Photo/Heat is Alarm")
Photo is Supervisory and Heat is AlarmHeat (available only when the primary
Operation option is set to "Photo is Supervisory | Heat is AlarmHeat")
Photo/Heat is AlarmSmoke (for both sensors; available only when the
primary Operation option is set to "Photo is Supervisory | Heat is
AlarmHeat")
Photo is AlarmSmoke and Heat is AlarmHeat (available only when primary
Operation is set to "Photo is AlarmSmoke | Heat is AlarmHeat")
The following table shows the different events the system generates upon sensor
activation, based on the settings for the Alternate Operation option.

Table 2: SIGA2-PHS Alternate Operation configuration settings and event

activation
Operation set to Device type Photo event Heat event
Photo/Heat is Alarm Smoke Alarm Alarm
(combined configuration)
Photo is Supervisory | Heat is Supervisory Supervisory AlarmHeat
AlarmHeat
(split configuration)
Photo/Heat is AlarmSmoke Supervisory AlarmSmoke AlarmSmoke
(split configuration)
Photo is Supervisory | Heat is Smoke AlarmSmoke AlarmHeat
AlarmHeat
(split configuration)

Note: If you assign the PHS a split configuration in the SDU, but your physical device is
actually the original SIGA-PHS, when you map the Signature loop, the loop controller
resets the device to the original SIGA-PHS attributes, flags it as an error on the map,
and annunciates a "bad type" trouble to the panel that includes the device address.
8. If you are using the split configuration of the SIGA2-PHS, and you want to use a
latching personality code, click Personality and chose the latching option. The default
setting is a nonlatching personality code.
9. Click Close in the Signature Series Configuration dialog box to save your settings.

See also
Understanding SIGA2 devices
SensorBypassOn command
SensorBypassOff command
Programming a Signature TCDR for CO
The Signature Series TCDR Temporal Pattern Generator generates sound patterns for
carbon monoxide (CO) and fire signals for the Signature AB4GT sounder bases. The TCDR
uses personality code 70 — Unsupervised Relay Output, which tells the TCDR to select the
desired sound pattern based on the activated channel. The TCDR supports the following
two temporal patterns:
TC3, NFPA 72 code for fire, pattern length 4 seconds
TC4, NFPA 720 code for CO, pattern length 5.8 seconds
The TCDR module uses two addresses: address 1 is tied to pattern 1, address 2 is tied to
pattern 2. If both channels are activated, channel 1 takes priority. Patterns and channel
configurations are driven by the marketplace. For example, in the US marketplace channel 1
is TC3 and channel 2 is TC4. During system initialization, the loop controller tells the TCDR
which pattern to play on channel 1 and channel 2. The TCDR then generates the pattern
and synchronizes all the Signature AB4GTs on a single loop.
Example Rule
The following rules are for the US marketplace.
Alarm '*' : ON 'TCDR Address 001' ;
COAlarm '*' : ON 'TCDR Address 002' ;
When an Alarm activates, the AB4GT sounder bases plays the TC3 pattern.
When a COAlarm activates, the AB4GT sounder bases plays the TC4 pattern.
When both are active at the same time, the AB4GT sounder bases play channel 1 (TC3
pattern), because in the US marketplace a fire alarm takes priority over a CO alarm.

See also
Understanding SIGA2 devices
Configuring CO devices
Changing Signature detector sensitivity levels
Signature detectors can be programmed to operate using multiple sensitivity levels.
Sensitivity is programmed as the primary (usual) operating condition while Alternate
Sensitivity is programmed as the secondary. A typical application might be to use the first
setting when the protected site is occupied and the alternate when the protected site is
unoccupied.

To change Signature detector sensitivity levels:

1. On the Tools menu, select Signature Series, then click Configure.
2. In the Select a Signature Loop Controller for Configuration dialog box, select the
cabinet and the loop controller card, then click OK.
3. Click the Loop 1 Detectors or Loop 2 Detectors tab.
4. In the configuration table, find the row containing the detector.
5. In the Sensitivity list, click the required sensitivity setting.
6. In the Alt. Sensitivity list, click the alternate sensitivity setting.
7. Click Close.
Changing Signature detector alarm verification times
Changing the alarm verification time adjusts the retard-reset period of the alarm verification
cycle. Signature detectors can be programmed to operate using two separate verification
times.
To change Signature detector alarm verification times:
1. On the Tools menu, select Signature Series, then click Configure.
2. In the Select a Signature Loop Controller for Configuration dialog box, select the
cabinet and the loop controller card, then click OK.
3. Click the Loop 1 Detectors or Loop 2 Detectors tab.
4. In the detector configuration table, find the row containing the detector.
5. In the Alarm Vfy list, click the time to use as the normal (usual) operating setting.
6. In the Alt. Alarm Vfy list, click the time to use as an alternate operating setting.
7. Click Close.
Programming Signature detector bases
Signature standard bases, relay or remote LED bases, isolator bases, and sounder bases
can operate as follows:
They can follow the state of the device they support
They can be configured in the SDU
They can be controlled by program rules you write
To configure individual bases, use the check boxes on the Detectors tab of the Signature
Series Configuration dialog box.
You can write rules to control individual bases by using the labels of the detectors. You can
also write rules for predefined or user-defined Signature groups. (Signature groups are also
referred to as relay/sounder groups or RSGs.)
You create or edit Signature groups using the Signature Group Assignment dialog box. This
dialog box also lets you create, edit, or delete user-defined groups. To access the
Signature Group Assignment dialog box, assign a sounder or relay base to a detector and
click the Assign Group button.
Note: If you assign a relay/sounder to a group, be aware that sounder bases do not
activate as a group when in stand-alone mode.
The system supports a maximum of 32 Signature groups. There are 5 predefined groups,
leaving 27 user-defined groups you can create. The predefined groups include:
None: The base follows the detector. Configuration check boxes have no effect.
Programming rules have no effect.
Individual control: Bases in this group are programmed individually. There is no label
for the group, so rules cannot be written for the entire group.
RSG nonsupervised common alarm: This group has the CommonAlarmOutput device
type. Bases in this group function as common alarm output devices.
RSG nonsupervised audible: This group has the Audible device type. Rules written
for Audible device types control these bases.
RSG nonsupervised visible: This group has the Visible device type. Rules written for
Visible device types control these bases.
For user-defined groups: The default device type for groups you define is None, but you can
change this when creating a new group or editing your group. Rules written for the assigned
device type control the bases in the group. The output devices types available in the New
Signature Group dialog box are:
NONE: The default device type assigned to groups. Assign this device type when
configuring a dual address module and the second address is unused.
NONSUPERVISEDOUTPUT: Assign this device type to nonsupervised, dry contact
output circuits.
 NSAUDIBLEOUTPUT: Assign this device type to a relay/sounder group.
NSVISIBLEOUTPUT: Assign this device type to a relay/sounder group.
NSCOMMONALARMOUTPUT: Assign this device type to a nonsupervised, dry
contact output circuit that requires automatic activation when a panel's FirstAlarm
event occurs.
NSCOMMONMONITOROUTPUT: Assign this device type to a nonsupervised, dry
contact output circuit that requires automatic activation when a panel's FirstMonitor
event occurs.
NSCOMMONSUPERVISORYOUTPUT: Assign this device type to a nonsupervised,
dry contact output circuit that requires automatic activation when a panel's
FirstSupervisory event occurs.
NWCOMMONTROUBLEOUTPUT: Assign this device type to a nonsupervised, dry
contact output circuit that requires automatic activation when a panel's FirstTrouble
event occurs.
For all groups except None, the following points apply:
Configuration check boxes control the individual bases
You can write rules to control individual bases by using the detector labels
You can write rules to control all bases in the group by using the group label
Both configuration check boxes and rules control the operation of the bases
Detector bases and CO devices
When configuring detector bases for CO devices, the following points apply:
For Signature PCOS, COS, PHCOS, and HCOS devices, if you set the Group Name
to None, then when the CO element activates it does not automatically control the
relay/sounder base.
When the CO element activates it does not affect the device's "Follow" settings. For
example, if you set the CO element to COALARM, the sounder/relay does not
activate when the CO element activates, even if you have checked the Follow Alarm
option.
If you must control the sounder/relay base when a CO element activates, set the
Group Name to a different group than None, and use rules to program the base.
See also
Signature Series Configuration - Detectors tab
Signature Group Assignment
Reconciling the Signature database
Reconciling the Signature database clears any inconsistencies between the configured map
and the current map. Inconsistencies can result from such things as devices being installed
in the wrong locations or serial numbers scanned in incorrectly.
Note: Always verify the installation against the system design documentation before making
any changes to the database.
See also
Mapping a Signature data circuit
Uploading the current map from the loop controller
Matching actual data with expected data
Scanning Signature devices into the database
Scanning is the quickest, most accurate method for entering device serial numbers into the
database. To use this method, the bar code reader must be properly installed and the
device serial number bar code labels correctly attached to the bar code report.
To scan detector serial numbers into the database:
1. On the Tools menu, select Signature Series, then click Configure.
2. On the Select a Signature Loop Controller for Configuration dialog box, select the
cabinet and loop controller , then click OK.
3. Click the data sheet tab matching the type of devices being scanned (detectors or
modules) to display the device configuration table.
The computer will beep when the bar code is read successfully.
4. On the device Serial Number Worksheet, scan the device address bar code to
advance the cursor to the correct record in the configuration table.
5. Scan the corresponding device serial number bar code.
The serial number will appear in the configuration table under the serial number
column next to the device database address.
6. Continue alternately scanning addresses and serial numbers from the worksheet
until all the devices have been scanned in.
7. Click Close.
Setting up Class A operation on the Signature loop
controller
The Signature controller card should be set for Class A operation only when the connected
data circuit is in a Class A wiring configuration. Initially, the Signature controller card is
configured for Class B operation.

To configure a Signature data circuit controller:

1. From the Tools menu, select Signature Series, then click Configure.
2. In the Select a Signature Loop Controller for Configuration dialog box, select the
cabinet and loop controller, then click OK.
3. On the Signature Series Parameters tab, select the Class A radio button.
Specifying default values for Signature devices
Default values for Signature devices are automatically entered in the detector configuration
table as the devices are added to the controller's database. Changing default values does
not affect the operating settings for devices already added.
To set the SIGA device default parameters
1. On the Tools menu, select Signature Series, then click Configure.
2. In the Select a Signature Loop Controller for Configuration dialog box, select the
cabinet and loop controller, then click OK.
3. On the Signature Series Parameters data sheet, select the Class A or Class B radio
button for Loop1 and Loop2.
4. Use the list boxes to set the default Alarm Verification and Alternate Alarm
Verification times, if required, for the selected model.
5. Use the list boxes to select the CO Setting for each of the selected CO model.
6. Use the list boxes to select Sensitivity and Alternate Sensitivity levels for each of the
selected model.
Setting up circuit mapping
Circuit mapping is used to provide placement supervision of Signature devices. Initially, the
Signature controller card is configured with the mapping function disabled.
To set up circuit mapping:
1. From the Tools menu, select Signature Series, then click Configure.
2. In the Select a Signature Loop Controller for Configuration dialog box, select the
cabinet and loop controller, then click OK.
3. On the Signature Series Parameters tab, click the Enable Mapping check box.
See Also
Mapping a Signature data circuit
Mapping a Signature data circuit
Mapping a Signature data circuit provides useful information about the circuit you can use
for troubleshooting or documenting the electrical positions of devices on the system.
Note: If the database for a particular controller has never been converted, checking status
on that controller causes an error. To prevent this, convert the Signature database once
you have added the controller to the cabinet configuration.
To map the data circuit:
1. Connect the download cable assembly from SDU computer to the controller card.
2. Select Tools > Signature Series > Status/Diagnostics.
3. On the Functions/Settings tab, click Mapping Enable for each loop you want to map.
Click the Perform Functions/Set Settings button.
4. Disconnect the download cable from the controller card.
See Also
Setting up circuit mapping
Uploading the current map from the loop controller
In order to display the current map, you must first upload it into SDU computer. Any time a
data circuit has changed you should upload the resulting map into the SDU computer and
save it in the database.
When you upload a map you can do so by using single step or network modes. Network
mode lets you upload a map over the rail bus from rail modules in a single panel or from
any panel on the network data riser. Single step mode lets you upload a map from rail
modules individually through a direct connection to the rail module.
To upload the current map into SDU computer:
1. Connect the download cable assembly from SDU computer to the controller
containing the current map you want to upload.
2. On the Tools menu, select Signature Series, then click Mapping.
SDU launches the Select a Signature Loop for Mapping dialog box.
3. Click the Connection Type you are using, and then select Single Step or Download.
4. Select the communication port and baud rate for the upload.
5. In the Cabinet list, select the cabinet connected to SDU computer.
6. In the Loop Controller list, click the data circuit whose current map you want to
upload.
7. Check Upload Loop.
8. Click OK.
9. In the LRM Communications dialog box, click Start.
10. After the download has finished, click Close.
Using the mapping interface
Mapping a Signature data circuit provides useful information about the circuit that you can
use for troubleshooting or documenting the electrical positions of devices on the system.
To use the mapping interface, first enable mapping (Setting up circuit mapping), and then
generate the Actual Data Wiring Diagram map. If there have been any changes to the data
circuit, upload the new mapping information from the loop controller first (Uploading the
current map from the loop controller).
The following graphic shows the general layout of the Actual Data Wiring Diagram map.

In the wiring diagram, if the actual and expected device data matches, the device displays
in white and an = symbol displays before and after the information. For example, = 24=. If
the data does not match, the device changes to red, yellow, or purple and the data shows
the actual and expected values separated by < > symbols. For example, 24 < > 27. In this
example, the device turned red and the actual device address is showing 24 but the
expected address is 27.
Device detail
Beneath each device the SDU can list up to six lines of data for the device: the address,
serial number (4 to 10 digits), model, base or personality, label, and device type. To select
the data and the order in which it displays, as well as the mapping diagram's position on the
screen see Accompany Data dialog box.
You can also view more details about any given device. To do so, point to the device to
display a popup containing the following:
Designation
 Device Address
Short Address
Serial Number
Model
Base/Personality
Additional device options, such as Alarm Verify, Sensitivity, Pre-Alarm, etc. This list
varies based on the device type and its configuration.
Viewing actual vs. expected data for a device
You can view both the actual data and the expected data for any given device on the map.
To do this, click the device icon. The SDU then displays the Actual vs. Expected dialog box.
From this dialog box you can direct the system to use either the actual data (Accept Actual)
or the expected data (Commit Expected). For further details, see Matching actual data with
expected data.
Note: If you do not see a Close button on the toolbar, resize the dialog box horizontally.

Identifying T-taps and balanced maps

The map shows T-taps horizontally to the right of the main branch.
Notes
Star-taps are not allowed.
The map shows the parent-child relationship between branches only; it does not
represent the physical location of the devices. Since star-taps are not allowed, we
assume that the correct T-tap connections have been made.
You may need to be aware of balanced map situations. The vertical grid position numbers
on the map help you to easily identify this condition. For example, you can see how many
branches contain five devices by locating the number "5" on the grid and then visually
scanning across horizontally to see how many branches show their last device on this line.
Those branches with the same number of devices are balanced. To prevent the possibility
of map faults after swapping devices, we recommend that you avoid using balanced
circuits.
See Also
Matching actual data with expected data
Resolving map faults using Device Chains
Matching actual data with expected data
Matching actual data with expected data removes any conflicts between the configured
map and the current map. Icons with red backgrounds indicate major conflicts that might
be causing map faults. Icons with yellow backgrounds indicate conflicts affecting device
operation.
Note: If you click Accept Actual for a device that does not have a matching serial number,
the SDU automatically adds that device to the database. Whenever a device cannot be
matched using the device's serial number, try matching by device address before deciding
to accept or commit.
To match actual data with expected data:
1. Upload the current map into SDU computer.
2. On the Actual Wiring Diagram toolbar, click the Error or Warning tab to select the
device indicating a conflict. Then click on that device's icon. The Actual vs. Expected
Data dialog displays the programming data for the selected device and indicates
which data is causing the conflict using colored backgrounds.
3. Determine which data in the Actual vs. Expected Data dialog is correct, the actual or
expected. Verify against available system design documentation. Then do one of the
following:
If the actual data is correct, click Accept Actual.
If the expected data is correct, click Commit Expected. Incorrect actual data
indicates an installation error, and can only be corrected by changing the device in
the boxes.
4. Repeat for each conflicting device.
See Also
Using the mapping interface
Resolving map faults using Device Chains
Use the Device Chains tab to help resolve map faults caused by chain processing errors. A
device chain consists of all the devices on the same electrical path, and starts at the loop
controller. The last device is called the end of path device.
A chain processing error occurs when the loop controller receives conflicting data about
device's position on the chain. As an example, suppose you have four detectors on a chain
and the loop controller has successfully mapped the first three. While mapping the fourth
detector the second detector doesn't respond when it should. The loop controller sees this
as an error.
Chain processing errors may be the result of, but are not limited to:
A problem with the device being polled.
A device the loop controller determines to be part of a chain once but not a second
time.
A device the loop controller determines to be part of a chain when it isn't.
Faulty signaling line circuit wiring or connections.
Understanding DS and DH detectors
The DS (photoelectric smoke) and DH (fixed temperature rate-of-rise heat) detectors are
only available in these marketplaces: Arabic, Asia, China, International, and Middle East.
These models are similar to other Signature series detectors, except:
1. You cannot map a Signature data circuit that contains either of these devices
2. They provide an inhibit normal flash mode
3. They support three prealarm or alternate prealarm thresholds: None, 50%, or 75%
4. The DS supports two sensitivity or alternate sensitivity levels: least and normal
5. In the China marketplaces, the panel turns on the LED to a steady red pattern for
the first 32 active/alarm state activations; for subsequent activations it turns on the
LED to a flashing red pattern
Notes
To support DS or DH devices in an EST3 cabinet, the 3-SSDC1(C) or 3-SDDC1(C)
loop controller must be running application and bootloader code version 04.10 or
later. To support DS or DH devices in an EST3X cabinet, the C-CPU firmware
version must be 1.20 or later.
When configuring a DS or DH detector, you must select the appropriate marketplace
on the Project Parameters – Operations tab before the SDU makes them available
in the Add Detectors to Loop dialog box.
The DH and DS detectors are nonmapping devices; you cannot mix mapping and
nonmapping devices on a mapped loop. When you add a nonmapping device, the
SDU classifies the entire loop as nonmapped. If you eliminate the nonmapping
devices, the SDU reclassifies the loop as mapped. Thus, when you add a DS or DH
detector, the SDU removes the Enable Mapping check box from the Signature
Series Configuration – Signature Series Parameters tab and replaces it with the
Inhibit Normal Flash check box. If you later remove all of the DS or DH detectors
from the loop, the SDU displays the Enable Mapping check box again and removes
the Inhibit Normal Flash check box.
Inhibit normal flash mode
The normal operation of the LEDs on the DS and DH is set to a flashing green pattern. In
some environments, you may not want to see a flashing LED on a normal basis. The inhibit
normal flash (INF) mode lets you turn off the LEDs on all DS and DH devices in a single
loop, during normal operation only.
Note: During off-normal operation, the DS and DH LEDs operate identically regardless of
the INF mode setting.
The SDU disables the inhibit normal flash mode by default. To turn on the inhibit normal
flash mode, click Tools > Signature Series Configure > OK > Signature Series Parameters.
Check the Inhibit Normal Flash check box.
The SDU reports the current status of the INF mode on the Signature Series Status /
Diagnostics – Current Status tab
Once you turn on the INF mode, the SDU lets you bypass it on a temporary basis when
needed. To do so, the SDU includes the Inhibit Normal Flash Mode Clear and Bypass radio
buttons on the Functions / Settings tab.
Inhibit normal flash mode bypass
You can bypass the inhibit normal flash mode temporarily, for example, to allow
maintenance or installation personnel to easily see that the devices are operational. To
bypass the INF mode, go to the Signature Series Status / Diagnostics – Functions/Settings
tab under Inhibit Normal Flash Mode, and click Bypass. Since the bypass is meant to be
temporary, the panel reports a trouble and continues to do so while the bypass mode is on.
Once the inspection is done, you can disable the bypass, return to the inhibit normal flash
mode, and stop the panel from reporting bypass troubles by clicking Clear on the Signature
Series Status / Diagnostics – Functions/Settings tab.
See Also
Configuring detectors on a nonmapping loop
Signature Diagnostics - Device Troubles tab
Use the Device Troubles tab to get more information on what may have caused a device to
signal a trouble.
Latching Troubles by Device Address
Display Devices as Serial Numbers
Display Devices as Device Address
New Data from Loop Controller button
See also
Configuring a Signature loop controller module
Signature Diagnostics - Device Chains tab
Use the Device Chains tab to examine device chains when resolving map errors. The
display shows four lists of devices; each list shows the serial number or device address of
the devices in the chain.
Current Chain
Chain Response
Device Response
Communicating
Display Devices as Serial Numbers
Display Devices as Device Address
New Data from Loop Controller button
See also
Resolving map faults using Device Chains
Configuring a Signature loop controller module
Signature Diagnostics - Function/Settings tab
Use the Function/Settings tab to change the operation of the loop controller.
Note: Some of these options may not apply to the marketplace you are using; if so the
system does not show the corresponding fields on the Options tab. Thus, there may be
some fields described here that you cannot see or use.
Functions
Reinitialize Loop
Settings
Mapping
Inhibit Normal Flash Mode Bypass
Inhibit Normal Flash Mode Clear
Class
Perform Functions/Set Settings button
See also
Configuring a Signature loop controller module
Understanding DS and DH detectors
Configuring detectors on a nonmapping loop
Signature Diagnostics - Mapping Errors tab
Use the Mapping Errors tab to view information as to why the loop controller failed to
successfully map the devices on the signaling line circuit.
Map Error History
Troubleshooting Tips
Display Devices as Serial Numbers
Display Devices as Device Address
New Data from Loop Controller button
See also
Configuring a Signature loop controller module
Signature Diagnostics - Mapping Progress tab
The Mapping Progress tab shows a real-time graph of the loop controller's progress
through its initialization process. Use this display to determine an overall understanding of
what the loop controller is doing. Note the key at the bottom of the graph that shows the
color for actual device data and the color for the expected device data.
Serial Numbers Found
Communicating
Mapping
Checking EOL
Programming
Pattern
See also
Configuring a Signature loop controller module
Signature Diagnostics - Message Counters tab
Use the Message Counters tab to check the loop controller's message error rate. During
normal operation, the loop controller issues command messages to the devices on the
signaling line circuit. The message counters show how many times the loop controller sent a
command message and the number of successful return messages.
The dialog box shows the command message in the left column, followed by the number of
times the loop controller sent it, the number of errors the loop controller received after
issuing the message, and the percentage of correct responses.
During normal operation, the percentage of messages received correctly should exceed
99%. Intermittent device or wiring problems are indicated by a low successful message
rate.
Display Devices as Serial Numbers
Display Devices as Device Address
New Data from Loop Controller button
See also
Configuring a Signature loop controller module
Signature Diagnostics - Status Log tab
The Status Log tab shows a real-time list of events that have occurred since the system
last established a connection to the loop controller. The system time stamps each event.
See also
Configuring a Signature loop controller module
Understanding DS and DH detectors
Configuring detectors on a nonmapping loop
Signature Diagnostics - Trouble Tables tab
Use the Trouble Tables tab to resolve device troubles. The system identities each device in
the table by serial number, device address, loop number, and label.
Internal Fault
Type Fault
Personality Fault
Unexpected Fault
Communications Fault
Open Fault
Ground Fault
Short Fault
Compatibility Fault
Dirty Head
Maint Alert
Percent Dirty
Production Date
Maintenance Date
Base Type Fault SA
Configuration Fault SA
Device Init Fault SA
Duplicate Fault SA
IL Feedback SA
Invalid Address SA
Riser Fault SA
Sensitivity Fault SA
Retry Counters 1 Hr
Retry Counters 24 Hr
CO Days Running
Display Devices as Serial Numbers
Display Devices as Device Address
New Data from Loop Controller button
See also
Configuring a Signature loop controller module
Configuring a 3-AADC1 module
The 3-AADC1 loop controller supports up to 99 sensors and 99 modules. To make
configuring a 3-AADC1 module easier, you can set default values for each type of
addressable analog device. As you add each device, the system automatically enters
default values into the configuration table.
You can also add more than one device at one time. When you add multiple devices, the
devices are assigned a contiguous block of addresses starting at the selected (lowest)
address.
Notes
The 3-AADC and 3-AADC1 loop controllers have nearly identical functionality, and
you can use the following procedure to configure either model. The 3-AADC1
contains extended memory for improved performance and is fully backward
compatible.
Several devices are compatible with model 3-AADC1 loop controller, but not with
model 3-AADC. (Devices incompatible with 3-AADC)
Installing either the UIO-12 or the RZB series module, follow the instructions
provided in the topic Adding a UIO-12 to a 3-AADC1 loop controller or Adding an
RZB series module to a 3-AADC1 loop controller, respectively.
To configure a 3-AADC1 loop controller:
1. From the Configure menu, click Cabinet.
2. Select the cabinet to be configured, then click the Modules tab.
3. From the list of installed modules, select the 3-AADC1, then click LRM Config. By
default the Card Parameters tab is displayed.
4. On the Card Parameters tab, perform the following steps:
Under Wiring Class, click Class A or Class B depending on the required
performance of the loop controller's signaling line circuit.
Under Device Series, click A Series or B Series depending on the type of devices
connected to the signaling line circuit.
Under Polling LED Action, click Blink or No Blink depending on the required action of
the device's light-emitting diode while the loop controller polls the device.
Under Supervisory, click Latching or Non Latching depending on whether supervisory
states are latched on the loop controller.
5. Click the Sensors tab, and for each alarm initiating device that is connected to the 3-
AADC1, assign a device address, as follows:
Locate the device's assigned address in the configuration table. If addresses have
not been assigned, go to the first available address.
 Click the cell in the Model column of the address you selected.
From the list that appears, select the device type that is appropriate for the device
and the way it functions in the system. If you need help deciding which device type
to use, see Device types.
6. In the Label column, enter a label for the device.
7. When you have finished assigning device addresses, device types, and labels for
each alarm initiating device connected to the 3-AADC1, click the Modules tab. Add
modules in the same way that you added devices on the Sensors tab.
8. When you have finished, click OK, then close the Cabinet Configuration dialog box.
See also
Changing addresses on addressable analog devices
Setting default properties for addressable analog devices
3-AADC1 device default settings
Tips for configuring a 3-AADC1 loop controller
AADC Configuration - Card Parameters tab
Changing addresses on addressable analog devices
While configuring addressable analog devices, you might find it necessary to change the
address of a device already in the configuration table. If the new address location is empty,
the device is moved to the new address and the old address number is left empty. If the
new address location is occupied by another device the device addresses are swapped.

To change the address of addressable analog devices:

1. Select the device in the configuration table.
2. Click Change Address. The SDU displays the New Address dialog box.
3. Type the new address or select the new address.
4. Click OK.
Setting default properties for addressable analog devices
The Card Parameters tab on the 3-AADC Configuration dialog provides separate property
sheets for each type of addressable analog device. The 3-AADC Configuration dialog
provides a command button for copying the device default settings from another controller
card.
Note: The 3-AADC and 3-AADC1 modules have similar functionality and are configured
using the same method. The 3-AADC1 contains extended memory for improved
performance and is fully backward compatible.
To set default properties for addressable analog devices:
1. From the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-AADC1 being configured and then click the
Modules tab.
3. On the Hardware Layer tab, select the 3-AADC1, and then click LRM Config.
4. On the Card Parameters tab, select the Default Settings sheet for the addressable
analog device and set each of the properties. For information on specific properties,
see 3-AADC1 device default settings.
5. Click OK.
To copy default values from another 3-AADC1:
1. From the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-AADC1 being configured and then click the
Modules tab.
3. On the Hardware Layer tab, select the 3-AADC1, and then click LRM Config.
4. Click Copy Defaults
5. Select the 3-AADC1 module whose default values you want to copy.
6. Click OK.
Tips for configuring a 3-AADC1 loop controller
Here are some tips for configuring a 3-AADC1 module:
Before adding any devices, make sure that the device default settings are set for
the correct values.
If you need to add devices with different default settings, arrange them in blocks,
change the default value settings on the Card Parameters tab, and add them using
the Add Multiple option.
When adding multiple devices, make sure the number of devices does not exceed
the number of free contiguous addresses. If the block size overlaps existing devices
in the configuration table, the existing devices will be overwritten with the new
devices.
Adding a UIO-12 to a 3-AADC1 loop controller
This topic shows you how to add a UIO-12 module to a 3- AADC1 loop controller using the
SDU. If you are new to this process, you might find it helpful to read the following topics
before starting:
For an overview of the UIO-12, see About the UIO-12 universal input-output module
For an overview of the 3- AADC1, see Configuring a 3-AADC1 module
For tips on making the process go smoothly, see Tips for Configuring a 3-AADC1
loop controller
Notes
If the device was configured during hardware installation, be sure the settings that
you assign through the SDU match those already assigned.
The UIO-12 universal input-output module is compatible with model 3-AADC1
running version 3.6 application code. The UIO-12 is not compatible with model 3-
AADC.
To add a UIO-12 module to a 3-AADC1 loop controller:
1. On the configure menu, click Cabinet.
2. On the Cabinet tab, select the cabinet with the 3-AADC1 module, and then click the
Modules tab.
3. On the Modules tab, select the 3-AADC1 module, and then click LRM Config.
4. In the AADC Configuration dialog box, click the Modules tab.
5. On the Modules tab, click the Model box that corresponds to the UIO-12 module's
base address. The base address is determined by rotary switches S1 and S2 on
the UIO-12 module.
The UIO-12 module requires 12 consecutive module addresses. If any other device
already occupies an address in the targeted block of addresses, the SDU lets you
choose to delete the existing devices or use the next available block of empty
addresses.
6. For each circuit on the Modules tab, enter a label and select a device type. The
device type settings in the SDU must match the UIO module's hardware
configuration.
Adding an RZB series module to a 3-AADC1 loop controller
This topic shows you how to add an RZB series module to a 3- AADC1 loop controller using
the SDU. If you are new to this process, you might find it helpful to read the following topics
before starting:
For an overview of the RZB series module, see About the RZB series remote zone
interface module
For an overview of the 3- AADC1, see Configuring a 3- AADC1 module
For tips on making the process go smoothly, see Tips for configuring a 3- AADC1
module
Notes
If module settings have been assigned during installation, be sure the settings that
you assign through the SDU match those already assigned. For more information,
see Matching hardware settings and device types for the RZB module.
RZB series remote zone interface modules are compatible with model 3-AADC1
running version 3.6 application code. RZB series remote zone interface modules are
not compatible with model 3-AADC
To add an RZB series module to a 3-AADC1 loop controller:
1. On the configure menu, click Cabinet.
2. On the Cabinet tab, select the cabinet with the 3-AADC1 module, and then click the
Modules tab.
3. On the Modules tab, select the 3-AADC1 module, and then click LRM Config.
4. In the AADC Configuration dialog box, click the Modules tab.
5. On the Modules tab, click the Model box that corresponds to the address for circuit
I/O1 on the RZB module, then click RZB12-6 On the list.
To determine the address for circuit I/O1, take the RZB module's start address and
add 100. The start address is determined by the HIGH ADD and LOW ADD
switches on the RZB module.
The RZB module requires eight consecutive sensor addresses and eight consecutive
module addresses. If any other device already occupies an address in the targeted
block of addresses, the SDU lets you choose to delete the existing devices or use
the next available block of empty addresses.
6. For each circuit on the Modules tab, enter a label and select a device type. The
device type settings in the SDU must match the RZB module's hardware
configuration.
Note: K5 and the PWR SUPV circuit (TB3-11 and TB3-12) share the same address.
If you are using the PWR SUPV circuit to monitor an external power supply,
 configure K5 as a SUPERVISEDOUTPUT device type. K5 is always an
unsupervised output regardless of the device type setting
7. For each circuit on the Sensors tab, enter a label and select a device type. The
device type settings in the SDU must match the RZB module's hardware
configuration.
Selecting device link graphics for AADC Configuration

What is the device link graphic?

The AADC Configuration dialog uses graphics to distinguish between single-address and
multiple address modules, as shown below.

Modules tab of the AADC Configuration dialog box, showing two single-address modules
(M500RF and M500MFB) and a multiple-address module (RZB series module).
To select an alternate device link graphic:
1. On the Card Parameters tab of the AADC Configuration dialog box, click the Device
Link Graphics box.
2. From the list that appears, select a graphic. The new selection is displayed on the
right.
3. When you have finished, click OK to close the dialog box.
Configuring a 3-ASU Audio Source Unit
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
To configure a 3-ASU:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-ASU being configured and then click the
Modules tab.
3. The cabinet must have a 3-ASU assigned to it.
4. On the Hardware Layer tab, select the 3-ASU, and then click LRM Config.
5. On the Channels tab, assign channel types and label to the unused channels, if
required.
6. Click the Options tab.
7. In the Memory list, click the amount of memory installed on the 3-ASU controller
board.
8. In the Page Deactivation box, type or select the number of seconds that must pass
before the system will turn off the paging function if an operator fails to maintain
pressure on the microphone push-to-talk switch.
9. In the Page Cancel box, type or select the number of seconds that must pass
before the system will cancel the selected paging function if the operator fails to
press the microphone push-to-talk switch after pressing a paging function switch.
10. In the Phone Page Trouble box, type or select the number of seconds allowed for
the handset on the 3-FTCU to remain off-hook before the 3-ASU reports a system
trouble.
11. Under Remote Microphone, select the Connected check box if a remote microphone
is connected to the 3-ASU.
12. Under Preannounce Tone, select when the 3-ASU should insert a message before
paging operators (always, on alarm, or never).
13. Click the Messages tab.
14. If necessary, click Add to add messages to the 3-ASU.
15. Click the Message Label cell for each new record in the message table and enter a
label.
To record a message refer to Recording the audio message content.
See also
Creating message records in the 3-ASU database
ASU Configuration - Channels tab
ASU Configuration - Options tab
Creating message records in the 3-ASU database
Adding custom messages to the 3-ASU database expands the capabilities of the
Emergency Voice/Alarm Communication System. The SDU automatically creates four
message records when the 3-ASU is added to the cabinet configuration table; a default
normal message, alert message, evacuation message, and preannounce message.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
Notes
The number of custom messages that a 3-ASU can store depends on the run length
of all the messages added together and the amount of memory installed on the 3-
ASU.
You cannot record a message beyond 35 seconds. A single message, including the
recorded message, the pre-clip, and the post-clip, cannot be longer than 40
seconds independent of memory size.
Tip: Enter the text of the audio message as the object message to use as a script when
recording the message content.
To create a message record in the 3-ASU database:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-ASU being configured and then click the
Modules tab.
The cabinet must have a 3-ASU assigned to it.
3. On the Hardware Layer tab, select the 3-ASU, and then click LRM Config.
4. Click the Message tab.
5. Click the Add button. An empty record is displayed in the message table.
6. Enter a label for each message in the message table.
7. After you have finished creating messages, click the OK button to close the dialog
box.
To record a message refer to Recording the audio message content.
When you create a message in the audio source unit, an MSG object is also created in the
object configuration table. By default, the text in the object message boxes is the same as
the object label. If you choose, you can change this text to be that of the recorded
message.
Configuring an Edwards analog loop controller module
The Edwards analog loop controller module comes in two types: a single loop module (3-
EASC) and a dual loop module (3-EADC). You can configure each module with up to 127
devices per loop. To make configuring the module easier, you can set default values for
each type of device. As you add each device, the default values are automatically entered
into the configuration table.
You can also add more than one device at one time. When you add multiple devices, the
devices are assigned a contiguous block of addresses starting at the selected (lowest)
address.
To configure an Edwards analog loop controller module:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-EADC or 3-EASC being configured and then
click the Modules tab.
3. On the Hardware Layer tab, select the 3-EADC or 3-EASC, and then click LRM
Config.
4. On the Card Parameters tab, perform the following steps:
Under Supervisory, click Latching or Non Latching depending on whether supervisory
states are latched on the loop controller.
Under Wiring Class, click Class A or Class B depending on the required performance of
the loop controller's signaling line circuit.
Under Polling LED Action, click Blink or No Blink depending on the required action of the
device's light-emitting diode when the loop controller polls the device.
5. Click the Loop1 tab, to add the devices that are connected to the Loop1 circuit.
6. Select the row for the device's assigned address in the configuration table. If
addresses have not been assigned, go to the first available address.
7. Double-click the Model list box for the desired address then click the model name of
the device being added. The SDU adds the devices to the configuration table and
automatically enters the default values for the device properties.
8. If you are configuring a dual loop controller, repeat steps 5 through 7 for Loop2.
9. Click OK.
See also
Changing addresses on a Edwards analog devices
Setting default properties for Edwards analog devices
Specifying Edwards analog device default settings
Tips for configuring a 3-EASC module or a 3-EADC module
Tips for configuring a 3-EASC module or a 3-EADC module
Here are some tips for configuring a 3-EASC module or a 3-EADC module:
Before adding any devices, make sure that the device default settings are set for
the correct values.
If you need to add devices with different default settings, arrange them in blocks,
change the default value settings on the Card Parameters tab, and add them using
the Add Multiple option.
When adding multiple devices, make sure the number of devices does not exceed
the number of free contiguous addresses. If the block size overlaps existing devices
in the configuration table, the existing devices will be overwritten with the new
devices.
Changing addresses of Edwards analog devices
When configuring Edwards analog devices, you might find it necessary to change the
address of a device already in the configuration table. If the new address location is empty,
the device is moved to the new address and the old address number becomes empty. If the
new address location is occupied by another device the device addresses are swapped.

To change the address of Edwards analog devices:

1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-EADC or 3-EASC being configured and then
click the Modules tab.
3. On the Hardware Layer tab, select the 3-EADC or 3-EASC, and then click LRM
Config.
4. Click the Loop tab that contains the device (Loop1 or Loop2).
5. Select the device in the configuration table.
6. Click Change Address button. The SDU displays the New Address dialog box.
7. Type or select the new address.
8. Click OK.
Setting default properties for Edwards analog devices
The Card Parameters tab on the Edwards Analog Loop Controller Configuration dialog
provides separate property sheets for each type of Edwards analog device. The Edwards
Analog Loop Controller Configuration dialog box provides a command button for copying the
device default settings from another controller card.

To set default properties for addressable analog devices:

1. From the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-EADC or 3-EASC being configured and then
click the Modules tab.
3. On the Hardware Layer tab, select the 3-EADC or 3-EASC, and then click LRM
Config.
4. On the Card Parameters tab, select the Default Settings sheet for the Edwards
analog device and set each of the properties.
5. Click OK.
To copy default values from another 3-EASC or 3-EADC:
1. From the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-EADC or 3-EASC being configured and then
click the Modules tab.
3. On the Hardware Layer tab, select the 3-EADC or 3-EASC, and then click LRM
Config.
4. On the Card Parameters tab, click Copy Defaults button.
5. Select the 3-EASC or 3-EADC module whose default values you want to copy.
6. Click OK.
Note: You must have more than one Edwards Analog Loop Controller to copy default
values.
Specifying Edwards analog device default settings
You specify the device default settings described below on the Card Parameters tab of the
Edwards Analog Loop Controller Configuration dialog box. The SDU automatically enters
these settings as you add devices to the controller database.
Note: Changing the default values does not affect the operating settings for devices already
added to the controller database. To avoid programming errors, make sure the default
settings are correct before adding multiple devices.
Object Label: Use this boxes to specify a label modifier that is common to all devices on
the circuit.
Note: Including the # character in the label automatically inserts the device address.
Including the % character in the label automatically inserts the cabinet number.
Device Type: Use this boxes to specify a particular device type.
Stand Alone: If set to True, allows the device to function in a common alarm mode if
communication with the CPU fails.
Heat: Use this box to specify the heat detector type (fixed or rate of rise) and temperature
(58 or 75 degrees Celsius) at which the heat detector activates.
Alternate Heat: Use this box to specify an alternate heat setting.
Sensitivity: Use this boxes to specify one of four sensor sensitivity level settings: More,
Normal, Less, or Least.
Alternate Sensitivity: Use this box to specify an alternate sensitivity level setting.
What are objects?
Objects are database entities that represent points in the system. SDU creates an object in
the project database for each addressable input and output point defined in the system,
including:
Hardware components (rail modules, switches, light-emitting diodes, and
addressable detectors and modules)
Traditional zone circuits
Groupings of database objects (AND Groups, Zone Groups, Matrix Groups, and
others)
Prerecorded voice messages used in an emergency voice/alarm communication
systems
Artificial points [pseudo points] used to signal circuit card malfunctions
For example, the Signature controller module is an object, as are any Signature devices
connected to it. In contrast, the 3-IDC8/4 module is an object, each of its eight circuits are
objects, but two-wire smokes connected to the circuits are not.
See also
Object Configuration - Object Configuration tab
Using the Prefabricated Text Editor
The Prefabricated Text Editor allows you to create and maintain a library of labels,
messages, and abbreviation modifiers to use when defining system components in the
Object Configurations dialog box. It also allows you to set up a labeling scheme that you
can use across projects to ensure consistency. All of these label types can consist of text,
wildcards, or both.
If you use the wildcard characters, the system automatically assigns numbers, addresses,
or slot locations for you based on the layout you assign. For example, you can use the %
wildcard to add the cabinet or node address to the label; ANN% produces a label of ANN2
for annunciators located in cabinet two, ANN3 for annunciators located in cabinet three, etc.
For more details, see Using wildcards in labels, messages, and abbreviations.
WARNING: If you have existing rules that use the current prefabricated text definitions, and
you change that text using the Prefabricated Text Editor, those rules will no longer work.
You would then have to change the text in the rules as well.
Label Text
Use the Label Text tab to specify a standard label. For example, you could define a
prefabricated label for smoke detectors as SMK*.
For more details, see Prefabricated Text Editor - Label Text tab.
To create a label:
1. Select one or more devices in the Object Configuration dialog box, and then click the
Prefab Labels button.
2. In Line 1, enter the text for the label you are defining. The bar to the right of this field
keeps track of how much of the available space you are using.
If you are using a wild card in your label, you can direct the editor to either increment or
decrement the number in the Wild Cards section. You can also specify a starting point for
the wildcard, and define the width of the wildcard field.
3. Click Add. The editor adds the label to the Prefab Label area.
Message Text
Use the Message Text tab to specify a standard two-line message that displays to the front
panel for specific device types. For example, you could define a prefabricated message for
smoke detectors on the first floor to read "First Floor Smoke".
For more details, see Prefabricated Text Editor - Message Text tab.

To create a message:
1. Select one or more devices in Object Configuration dialog box, and then click the
Prefab Labels button.
2. Click the Message Text tab.
3. In Line 1, enter the first line of the message. The bar to the right of this field keeps
track of how much of the available space you are using.
If you are using a wild card in your label, you can direct the editor to either increment or
decrement the number in the Wild Cards section.
4. In the same manner, enter the second line of the message in Line 2.
5. Click Add. The editor adds the two-line message you just created to the Prefab Line
1 and Prefab Line 2 areas.
Abbreviation Text
Use the Abbreviation Text tab to specify standard abbreviations you want to use in your
project.
For more details, see Prefabricated Text Editor - Abbreviation Text tab.
To create abbreviation text:
1. Select one or more devices in Object Configuration dialog box, and then click the
Prefab Labels button.
2. Click the Abbreviation Text tab.
3. In Line 1, enter the abbreviation. The bar to the right of this field keeps track of how
much of the available space you are using.
If you are using a wild card in your label, you direct the editor to either increment or
decrement the number in the Wild Cards section.
4. Click Add. The editor adds the abbreviation you just created to the Abbreviation Text
area.
Device Types
Use the Device Types tab to change the substitution value for the device type wildcard (<).
For example, the default substitution value for the 12SW/12LED device type is 12S12L, but
you could change this to 12SW/12LED.
For more details, see Prefabricated Text Editor - Device Types tab.
Note: To return device types back to their default values, click the Assign Default Device
Type Abbreviations button.
To change the substitution value:
1. Click the Prefab Messages button, and then click the Device Types tab.
2. Select the device type in the device table.
3. In the Substitution Value box, type the new value.
4. Click Change.
Substitution Legend
This tab provides a quick reference of the substitution characters allowed in the
Prefabricated Text Editor.
For more details, see Prefabricated Text Editor - Substitution Legend tab.
See also
Adding a number reference to object labels
Entering location message text
Labeling database objects
Using wildcards in labels, messages, and abbreviations
You can use the following wildcards in the Prefabricated Text Editor to make entering
labels, messages, and abbreviations easier:
Asterisk (*)
Number sign (#)
Percent sign (%)
Greater than sign (>)
Less than sign (<)
Asterisk (*)
Use the asterisk (*) to automatically insert a number. The following options control how the
number is inserted:
Start * Value: Determines the number inserted in place of the asterisk. When more than
one device is selected in the object configuration table, this number is inserted for the first
device (the device closest to the top of the table).
Increment *: Determines if the numbers inserted count up when more than one device is
selected in the object configuration table.
Decrement *: Determines if the numbers inserted count down when more than one device
is selected in the object configuration table.
*Width: Determines the number of digits used to represent the number. Leading zeros are
automatically added only if the number of digits in the inserted number is less than the width
setting. For example, if the width were set for 2, the number 1 would be 01, the number 10
would be 10, and 100 would be 100.
Back to top
Number sign (#)
Use the number sign (#) to automatically insert the selected object's device address. The #
Width setting determines the width of the inserted device address. Leading zeros are
added if the device address is less than the # Width setting as described above.
Back to top
Percent sign (%)
Use the percent sign (%) to automatically insert the selected object's cabinet address. The
% Width setting determines the width of the inserted cabinet address. Leading zeros are
added if the cabinet address is less than the %Width setting as described above.
Back to top
Greater than sign (>)
Use the greater than sign (>) to automatically insert the selected object's slot position in the
cabinet. The > Width setting determines the width of the inserted slot position. Leading
zeros are added if the slot position is less than the >Width setting as described above.
Back to top
Less than sign (<)
Use the less than sign (>) to automatically insert the selected object's device type.
Back to top
Adding a number reference to object labels
Adding a number reference to object labels is useful when you want to associate a device
with a particular numbered area, floor, or room. Doing so also lets you use some of the
advanced programming features of the rule editor when writing rules for those devices.
Note: If numbered referencing is part of the labeling plan, include the asterisk in the label
modifier when building the label library. Only 1 asterisk per label modifier placed at the end
of the modifier.
To add a number reference to a group of objects:
1. On the Configure menu, select Objects
2. On the Object Configuration tab, select the objects.
3. Click Prefab Labels.
4. Type an asterisk character in the label text boxes.
5. In the Start * Value boxes, select the number for the first object in the group.
6. Select Increment for the numbers to count up one at a time or Decrement for the
numbers to count down.
7. Click After.
Defining an object's network routes
Note: This topic describes features available in 3-CPU1 application code version 3.5 or
earlier. If you are using version 3.6 or later, see Defining an object's message annunciation
routes, instead.
To define an object's Routing Label and Alt Routing Label properties:
1. On the Configure menu, select Objects. This opens the Object Configuration dialog
box. The Object Configuration tab is selected by default.
2. Click the device's Routing Label to activate the pull-down button.
3. Click the pull-down button, and from the list that appears, select the network route
to be used when the protected site is occupied.
4. Repeat steps 2 and 3 for the Alt Routing Label. This network route will be used
when the protected site is unoccupied.
5. When you have finished, click Close.
Tips:
Use the display filters to limit the number of devices displayed in the configuration
table
You can set message routing options for more than one device by selecting the Pick
check box for each device then changing one of them
Defining an object's message annunciation routes
Note: This topic describes features available with application code version 3.6 or later of
the 3-CPU1. If you are using an earlier version of this application code, see Defining an
object's network routes instead.
You will assign two message annunciation routes to each object. The first will be used
during times when the building (or other protected site) is occupied, and the other will be
used only when the building is unoccupied.
To define network routes for an object's event messages:
1. On the Configure menu, select Objects. The Object Configuration dialog box opens.
2. In the table, check the Pick check boxes of any objects to be assigned the same
message route.
3. Scroll right, if necessary, to display the Msg Annunciation Route Label column.
4. Click the Msg Annunciation Route Label cell, then click the pull-down button and
select the route to be used when the protected site is occupied.
5. Click the Alt Msg Annunciation Route Label cell, and select the route to be used
when the protected site is unoccupied.
6. Repeat steps 2 through 5 for any other objects to be configured.
7. When you have finished, click Close.
See also
Overview of message annunciation routing
Create a message annunciation route
Entering location message text
Location messages are included as part of the data that is routed to a panel when a device
changes to an active state. Location messages, sometimes called object messages or
event messages, when properly constructed work in conjunction with the displayed event to
identify the active device.
Using object labels as message text
If the device label contains sufficient information to identify the device, you can use the label
as the device location message.

To assign the device label as the message:

1. On the Configure menu, select Objects.
2. On the Object Configuration tab, select the object.
3. Click the Msg=Label button.
4. Click Close.
Using the Object Message Editor
When identifying the active device requires more information than that provided by the
device label, you can use the Object Message Editor to enter a device location message.

To enter a location message using the Message Editor:

1. On the Configure menu, select Objects
2. On the Object Configuration tab, select the object, and then click Edit Message. The
Object Message Editor dialog box appears.
3. In the Location Message box, perform the following steps:
Note: When a CDR-3 coder is used, do not use the # symbol in the Location
Message.
Enter a description of where the device is located, such as, 'FLOOR 2 LOB' As you
enter characters, the SDU keeps track of how many pixels you have remaining in the
Percentage of used pixel width field.
For a two-line LCD, you can click the 1<->2 button to the right of the Location Message
text box and enter the second line of text in the Location Message box. Toggle back to
the first line by clicking this button again.
4. In the Abbreviation box, type a short form of the device label to refer to the device in
the LCD command menu.
5. Check the Coder check box if using a coder, and then select or enter the numeric
command string that is sent to the coder when the device goes active. To clear the
command string, click Clear Coder Command.
6. Click Save.
Using the Prefabricated Text Editor
When multiple device messages contain the same message text, a quick way to enter the
text is to use the Prefabricated Text Editor. Text strings can consist of up to 30 characters,
including spaces, and saved in the library just like prefabricated labels.
To enter location messages using the Prefabricated Text Editor:
1. On the Configure menu, select Objects
2. On the Object Configuration tab, select the object whose message you want to add
to or replace.
3. Click Prefab Labels.
4. Click the Message Text tab.
5. In the Line 1 box, type the first line of the device location message. The status bar
indicates the percentage of pixels used to display the message.
6. In the Line 2 box, type the second line of the device location message. Click Add.
7. Do one of the following:
To add the selected text string to the beginning of any existing message text, click
Before.
To add the selected text string to the end of any existing message text, click After.
To substitute the entire existing message text with the text string, click Replace.
Labeling database objects
Devices in the system are given unique labels that can be used in writing rules. Object
labels can be created one at a time by typing directly into the object configuration table.
This is convenient for labeling individual objects or making quick corrections. When labeling
groups of similar objects, however, it is quicker to use the Prefabricated Label editor. Both
labeling methods are explained below.
Note: Duplicate labels generate errors and prevent the database from compiling. Unlabeled
objects generate warning messages but won't stop the compile process.
Labeling_single_objects_or_making_quick_corrections
Using the Prefabricated Label editor
Labeling for reporting to off-site monitoring stations
Tip: Once you are in the edit mode, pressing the up and down arrows on the computer
keyboard will position the text cursor to the next boxes without exiting the edit mode.
Labeling single objects or making quick corrections
To label single objects or make quick corrections:
1. From the Configure menu, select Objects
2. In the object configuration table, locate the object to be labeled, and click the Label
Text boxes. The mouse pointer changes to a text cursor to indicate that you are in
edit mode.
3. Type the object label.
4. To label another object, repeat steps 2 and 3.
5. When you have finished labeling objects, click the Close button to close the Object
Configuration dialog box.
Back to top
Using the Prefabricated Label editor
The Prefabricated Text editor lets you create a library of labels and label modifiers to be
used in labeling groups of similar objects. The Prefabricated Text editor also lets you create
and assign location messages and abbreviations. Use the Prefabricated Text editor to label
large groups of similar objects or to modify several objects at once.

To label groups of similar objects:

1. From the Configure menu, select Objects
2. On the Object Configuration tab, select the objects to be labeled.
3. Click the Prefab Labels button.
4. Type the label text in the text boxes or select a label from the list of prefabricated
labels.
5. To add the selected label to the beginning of any existing label text, click Before.
6. To add the selected label to the end of any existing label text, click After.
7. To substitute the entire existing label text with the selected label, click Replace.
Back to top
Labeling for reporting to off-site monitoring stations
If your project uses a 3-MODCOM to report events to a central monitoring station (CMS),
the protocol used can affect your labeling scheme.
Contact ID, SIA P2, and SIA P3 formats make use of a special telco version of hexadecimal
coding. In this version, 0 and A are equivalent, both representing the decimal value 10. In
practice, hex A is not used.
For example, say the site has a basement and twelve floors. You decide to label the floors
by using 0 for the basement, and 1 through 12 for the floors. Using Contact ID protocol, the
following rule would transmit identical event messages for the basement and for floor 10,
identifying the area as the basement in both cases.
[CMS Alarm Report]
ALARM 'Floor_<n:0-12>_Smoke':
+Send 'Account_Label' MSG "111000<h:3>",
-Send 'Account_Label' MSG "311000<h:3>";
The SDU automatically converts hex A to hex 0 when compiling rules for projects using
these protocols. It generates a warning message when this causes different events to
generate the same CMS message. Use these warnings to resolve labeling problems.
The CMS Messaging Report always shows the exact message that will be sent for every
event. You can use this report to ensure that your rules are creating the messages you
intend.
Back to top
Setting message routing options
To assign message annunciation routes to objects
1. From the Configure menu, select Objects. The Object Configuration dialog opens.
2. In the table, check the check boxes of all objects to be assigned the same message
route.
3. Scroll right, if necessary, to display the Msg Annunciation Route Label column.
4. Click the Msg Annunciation Route Label cell, then click the pull-down button and
select the route to be used when the protected site is occupied..
5. Click the Alt Msg Annunciation Route Label cell, and select the route to be used
when the protected site is unoccupied.
6. Repeat steps 2 through 5 for any other objects to be configured.
7. When you have finished, click Close.
See also
Overview of message annunciation routing
Creating a message annunciation route
Setting object configuration table filter properties
Setting object configuration table filter properties limits the number of object records
displayed in the table. Each object record represents an addressable point in the system.
The table only lists the object records whose properties match all four filter settings.
Tips
In large multi-cabinet systems, setting the Cabinet filter first will make it easier to
locate a specific rail module by reducing the number of selections listed in the LRM
filter.
By locking the Device Type filter setting, you can label all objects with the specified
device type on separate rail modules by changing the LRM Type filter setting.
Cabinet: The Cabinet filter setting limits the records to only those objects associated with
the selected panel.
LRM: The LRM filter setting limits the records to only those objects associated with the
selected rail module.
Device Type: The Device Type filter setting limits the records displayed in the object
configuration table to only those objects associated with the selected device type. The
Device Type filter can be locked to prevent the filter from resetting when a new panel or rail
module is selected.
Address Range: The Address Range filter setting limits the records to only those objects
having a device address that falls within a selected range. The address range filter can be
locked to prevent the filter from resetting when a new panel or rail module is selected.
Overview of network routing

What is network routing?

Network routing is a means of controlling how individual cabinets handle state changes,
system commands, and event messages that are broadcast across the network. The
following sections introduce the basic concepts of network routing.
Network routes
State changes
System commands
Location messages
Display and printer partition event messages
Links to step-by-step instructions
Network routes
Network routes are groups of cabinets. They are used to designate the group of cabinets
whose state changes and location messages will be accepted by a cabinet, and to
designate the cabinets that will accept and respond to commands issued from a cabinet's
common control switches.
A network route can include every cabinet on the network, no cabinets, or any number in
between. A single cabinet can belong to multiple network routes. A single project can have
up to 256 network routes.
Back to top
State changes
When one cabinet changes state, the state change is sent to other cabinets on the network.
Each cabinet checks its State network route to determine whether the route includes the
panel whose state has changed. If it does, the cabinet changes state accordingly. If it does
not, the cabinet ignores the state change.
If you want Panel B to go in to alarm when Panel A goes into alarm, then panel B's State
network routing group must include Panel A.
Back to top
System commands
Each cabinet has five network routes that indicate which cabinets will respond when an
operator presses the Reset button or other common control switch on its LCD module.
There are separate network routes for each of the five common control switches: Reset,
Alarm Silence, Panel/Trouble Silence, Drill, and Alternate Sensitivity.
If you want to reset Panel B when you press the Reset button on Panel A, then Panel A's
Reset network routing group must include Panel B.
Back to top
Location messages
When a device connected to a cabinet changes state, the location message of the device
that originated the state change is sent to other cabinets on the network. Each cabinet
checks its State network route, as described above, and its Display Enabled setting. This
setting designates the types of messages it will accept for display or printing. Types of
messages include alarm, supervisory, trouble, monitor, service group, and service device
messages.
If the State network route includes the cabinet that issued the state change, and the
location message type is included in the Display Enabled settings, the cabinet displays or
prints the message. If either condition is not met, the message is ignored.
Prior to application code version 3.6 of the 3-CPU1: Every object in the database has a
Routing Label property and an Alternate Routing Label property. These properties hold the
network route to which its location message will be sent if it changes state. Use the Routing
Label property to specify where you want to send location messages when the protected
site is occupied. Use the Alt. Routing Label property to specify where to send the object's
location message if it changes state when the protected site is not occupied.
If you want the location message for a device connected to Panel A to be displayed at
Panel B, then the device's Routing Label property must include Panel B and Panel B's
State network routing group must include Panel A.
Starting with application code version 3.6 of the 3-CPU1 and later: Every object in the
database has a Message Annunciation Route Label, and an Alternate Message
Annunciation Route Label. These properties replace the Routing Label and Alt. Routing
Label properties of earlier versions.
Back to top
Display and printer partition event messages
Each panel can be set to display or print partition state change messages. Routing of
partition messages depends on partition routes that you define. By selecting a partition
route, you can specify the partitions whose event messages will be displayed or printed by
this panel. For in depth information on message annunciation routes, see Overview of
message annunciation routing.
Back to top
For step-by-step instructions see
Setting a panel's state processing options
Setting a panel's message display options
Setting a panel's partition routing options
Setting up network routing properties of common controls
Setting a panel's state processing options
The state processing settings let you specify the panels whose state change messages this
panel will display or print. State change messages occur when a device or panel goes into
alarm or changes to another state.
Note: This alone does not determine whether state change messages from other panels
will be displayed on the LCD module. For that you must also set the panel's message
display options.
To set a panel's state processing options:
1. From the Configure menu, click Cabinet. This opens the Cabinet Configuration dialog
to the Cabinet tab.
2. Select the cabinet from the table.
3. Click the Network Routing tab.
4. Click State and select the appropriate cabinet route.
5. Click Close.
See also
Overview of network routing
Setting a panel's message display options
Setting a panel's partition routing options
Setting up network routing properties of common controls
Setting a panel's message display options
Settings in the Display Enabled section of the Cabinet Configuration dialog specify which
types of event messages the panel will display.
This alone does not determine whether event messages from other panels will be displayed
on the LCD module. For that you must also set the panel's state change options.

To set a panel's message display options:

1. From the Configure menu, click Cabinet. This opens the Cabinet Configuration dialog
to the Cabinet tab.
2. Select the cabinet from the table.
3. Click the Options tab.
4. Under Display Enabled, select the appropriate check boxes.
5. Click Close.
See also
Overview of network routing
Setting a panel's state processing options
Setting a panel's partition routing options
Setting up network routing properties of common controls
Setting a panel's partition routing options
The partition routing setting specifies the group of partitions whose event messages will be
displayed and printed by this cabinet.
To set a panel's partition routing options:
1. On the Configure menu, click Cabinet. This opens the Cabinet Configuration dialog
to the Cabinet tab.
2. Select the cabinet from the table.
3. Click the Network Routing tab.
4. Click Partition and select the appropriate partition route.
5. Click Close.
See also
Overview of network routing
Setting a panel's state processing options
Setting a panel's message display options
Setting the network routing properties for a panel's common controls
Setting up network routing properties of common controls
Network routing settings let you specify the group of panels that will respond when any of
the common control switches on this panel's LCD module is pressed.
To set up network routing properties of a panel's common controls:
1. From the Configure menu, click Cabinet. This opens the Cabinet Configuration dialog
to the Cabinet tab.
2. Select the cabinet from the table.
3. Click the Network Routing tab.
4. The settings listed in this section represent the common control switches on an LCD
module.
5. For each setting, click the drop-down arrow and select the panels that should
respond to this panel's common control switches.
6. Click Close.
See also
Overview of network routing
Set a panel's state processing options
Set a panel's message display options
Set a panel's partition routing options
How network routing settings affect event message
handling
Consider a network with four panels, A, B, C, and D. Each is equipped with an LCD and is
programmed to display location messages from devices that are in alarm. Panel B and
Panel C are programmed to process state changes from Panel A. Panel D is programmed
to process state changes from no cabinets. All device location messages are programmed
to go to Panel B only.
A smoke detector on Panel A signals that it is in alarm and puts Panel A into alarm. Panel A
sends a message across the network saying that "Panel A changed to the alarm state".
Panel B and Panel C are programmed to accept state changes from Panel A so they both
go into alarm and activate their common alarm outputs; Panel D does not. Only Panel B
turns on its Alarm LED and displays the location message of the device that signaled the
alarm; Panels A, C, and D do not.
If there is a rule that turns on a horn on Panel D when the smoke detector on Panel A
signals an alarm, then the horn will turn on. Rule activation is separate from state change
processing.
Overview of IP services
Network events can be transmitted through any EST3X control panel with an installed
Ethernet card for communication with external devices such as central monitoring stations,
computers, and smartphones. The communication occurs over Ethernet using IP Services
such as email and text messaging, IP Dialer protocols, and the External Command Protocol
(ECP).
Up to eight different IP services may be configured for each Ethernet card. The services
can be any combination of ECP connections, IP dialer accounts, or email accounts (up to
20 email addresses per email account). A network of panels can support up to 10 ECP
connections and 100 email accounts (up to 20 email addresses per email account), and up
to 100 IP Receiver accounts (75 maximum if all are configured to automatically generate
events).
The installed Ethernet card type determines which IP services are supported (see the
compatibility table below).

Required Ethernet card type

Supported communication ETH1 ETH2 ETH3
SDU communication with the panel for
X X X
programming and diagnostics
FireWorks (ECP/IP) gateway communication X X X
IP dialer communication X X
Email and text communication X
ECP over IP
The control panel can be configured to communicate system events to a UL Listed
Fireworks workstation using the Ethernet connection (Gateway III over IP). This connection
may be configured for encrypted or unencrypted communication.
IP Dialer
The control panel may be configured to communicate system events to a central monitoring
station using an Ethernet connection as an alternative to, or in conjunction with, a POTS
dialer such as the MODCOM(P). IP Dialer communications may be configured for
encrypted or unencrypted communication.
Email and text messaging
The control panel may be configured to communicate system events to email or text
addresses through SMTP servers. Email messages allow communication of multiple or
single system events and text messages allow single system events. SMTP connections
may be configured for encrypted or unencrypted communication.
For text messaging, a text message is routed to the recipient's wireless service provider
phone number email address through a configured SMTP server. The wireless service
provider then transmits the message to the recipient’s text account. Check with the wireless
provider for their carrier gateway address and any additional carrier requirements.
See also
Ethernet terminology
Configuring an ECP service type
Configuring an IP receiver service type
Configuring an email service type
Configuring an IP receiver service type
When a new CAB6 is added to the SDU, eight IP services become available. The SDU
automatically names each service type "None" and assigns them default values until you
select a specific service type and configure it. IP Receiver is one of the service types.
The IP receiver service allows TCP/IP transmission of system events to a central
monitoring station (CMS). After adding an IP receiver service type, use the IP Receiver
Configuration dialog box to configure its properties.
Caution: Changing a configured service type to None or to a different service type affects
any rules you have written for the service and any accounts configured for the service.
Notes
This feature is available only for a CAB6 with an ETH2 or ETH3 Ethernet card
installed and the correct C-CPU Ethernet Card type selected in the IP Configuration
dialog box. See CAB6 IP configuration settings for details.
The panel supports up to eight IP services that can be any combination of ECP
connections, IP dialer accounts, or email accounts (up to 20 email addresses per
email account).
A network of panels can support up to 10 ECP connections and 100 email accounts
(up to 20 email addresses per email account), and up to 100 IP Receiver accounts
(75 maximum if all are configured to automatically generate events).
You can refer to IP Receiver Service Configuration for configuration descriptions.
Prerequisite
Before starting to configure the IP Receiver service, you will need to gather configuration
settings from the local IT administrator and the CMS administrator. Through the My-Eddie
website, you can download the EST3X IP Dialer-Email Configuration Worksheet (P/N
3102338-EN) that will guide you through the information to gather. To access the website,
enter my-eddie.com in your web browser, and then locate the worksheet in Media Type >
Installation Sheets.
To add an IP receiver service:
To edit an IP receiver service:
To delete an IP receiver service:
See also
Configuring an email service type
Configuring an ECP service type
Overview of IP services
Configuring an email service type
When a new CAB6 is added to the SDU, eight IP services become available. The SDU
automatically names each service type "None" and assigns them default values until you
select a specific service type and configure it. Email is one of the service types.
The email service allows TCP/IP transmission of system events to an SMTP server for
delivery of custom email messages and SMS text messages to distribution lists. After
adding an email service type, use the Email Configuration dialog box to configure its
properties.
Caution: Changing a configured service type to None or to a different service type affects
any rules you have written for the service and any accounts configured for the service.
Notes
This feature is available only for a CAB6 with an ETH3 Ethernet card installed and
the correct C-CPU Ethernet Card type selected in the IP Configuration dialog box.
See CAB6 IP configuration settings for details.
The panel supports up to eight IP services that can be any combination of ECP
connections, IP dialer accounts, or email accounts (up to 20 email addresses per
email account).
A network of panels can support up to 10 ECP connections and 100 email accounts
(up to 20 email addresses per email account), and up to 100 IP Receiver accounts
(75 maximum if all are configured to automatically generate events).
You can refer to Email Service Configuration for configuration descriptions.
Prerequisite
Before starting to configure the Email service, you will need to gather configuration settings
from the local IT administrator. If no local IT administrator or no local SMTP server is
available and a public email service will be used, you will need to contact the Internet
service provider for configuration settings. Through the My-Eddie website, you can
download the EST3X IP Dialer-Email Configuration Worksheet (P/N 3102338-EN) that will
guide you through the information to gather from the local administrator or Internet service
provider. To access the website, enter my-eddie.com in your web browser, and then locate
the worksheet in Media Type > Installation Sheets.
To add an email service:
To edit an email service:

To delete an email service:

See also
Configuring an IP receiver service type
Configuring an ECP service type
Overview of IP services
Configuring an ECP service type
When a new CAB6 is added to the SDU, eight IP services become available. The SDU
automatically names each service type "None" and assigns them default values until you
select a specific service type and configure it. The External Command Protocol (ECP) is
one of the service types.
The ECP service allows ECP transmission of system events over IP to a UL Listed
FireWorks workstation that supports IP connections. After adding an ECP service type, use
the ECP Configuration dialog box to configure its properties.
Caution: Changing a configured service type to None or to a different service type affects
any rules you have written for the service and any accounts configured for the service.
Notes
This feature is available only for a CAB6 with an ETH series Ethernet card
installed and the C-CPU Ethernet Card type selected in the IP Configuration dialog
box. See CAB6 IP configuration settings for details.
The panel supports up to eight IP services that can be any combination of ECP
connections, IP dialer accounts, or email accounts (up to 20 email addresses per
email account).
A network of panels can support up to 10 ECP connections and 100 email accounts
(up to 20 email addresses per email account), and up to 100 IP Receiver accounts
(75 maximum if all are configured to automatically generate events).
You can refer to ECP Service Configuration for configuration descriptions.
Prerequisite
Before starting to configure the ECP service, you will need to gather configuration settings
from the FireWorks workstation administrator. Through the My-Eddie website, you can
download the EST3X IP Dialer-Email Configuration Worksheet (P/N 3102338-EN) that will
guide you through the information to gather. To access the website, enter my-eddie.com in
your web browser, and then locate the worksheet in Media Type > Installation Sheets.

To add an ECP service:

To edit an ECP service:
To delete an ECP service:
See also
Configuring an Email service type
Configuring an IP receiver service type
Overview of IP services
Configuring receiver accounts
Use the Receiver Accounts Properties dialog box to configure properties that you will assign
to a previously configured IP receiver service.
The IP receiver service allows TCP/IP transmission of system events to a central
monitoring station (CMS). The receiver account defines the properties that are used in the
project database and rules. After configuring the account, use the SendIP command to
write rules that send the system events.
Notes
The Receiver Accounts tab appears only for a CAB6 with an ETH2 or ETH3 card
installed and the C-CPU Ethernet Card type set as Prog/Diag/ECP/IPDialer in the IP
Configuration dialog box.
The IP receiver service associated with the account must be configured before the
account can be added.
The panel supports up to 255 receiver accounts.
You can refer to Receiver Account Properties for configuration descriptions.
To add a receiver account:
Note: A network of panels can support up to 100 IP Receiver accounts (75 maximum if all
are configured to automatically generate events).
To edit a receiver account:
To delete a receiver account:
See also
SendIP command
Configuring email accounts
Use the Email Account Properties dialog box to configure properties that you will assign to
a previously configured email service.
The email service allows TCP/IP transmission of system events to an SMTP server for
delivery of custom email messages or SMS text messages to distribution lists. The email
account defines the properties that are used in the project database and rules. After
configuring the account, use the SendEmail command to write rules that send the system
events.
Click the link below to see examples of an email and text message that can be sent using
the information you enter in the Email Account Properties dialog box. Notice that the content
of the SMS text message is reduced to meet the Global System for Mobile
Communications (GSM) transmission standard that limits SMS text messaging to 160
characters.
See Overview of IP Services for a description of how text messages are routed through
wireless providers. Check with the wireless provider for their carrier gateway address and
any additional carrier requirements.
Email and text message examples
Notes
The Email Accounts tab appears only for a CAB6 with an ETH3 card installed and
the C-CPU Ethernet Card type set as Prog/Diag/ECP/IPDialer/Email in the IP
Configuration dialog box.
The email service associated with the account must be configured before the
account can be added.
Each panel supports up to 100 email accounts. Each account supports sending
messages to up to 20 addresses in an account distribution list.
You can refer to Email Account Properties for configuration descriptions.
Prerequisite
Before starting to configure email account properties, you will need to gather configuration
settings from the authority responsible for deciding who will receive message notifications.
Through the My-Eddie website, you can download the EST3X IP Dialer-Email
Configuration Worksheet (P/N 3102338-EN) that will guide you through the information to
gather. To access the website, enter my-eddie.com in your web browser, and then locate
the worksheet in Media Type > Installation Sheets.
To edit an email account:
To edit an email account:
To delete an email account:
See also
Creating email distribution lists
Adding and deleting email addresses
SendEmail command
Adding and deleting email addresses
In order to create a distribution list for an email account, you must first add message
recipients to the account. The system accepts all valid email domain addresses. For email-
to-text addresses, check with the wireless provider for their carrier gateway address and
any additional carrier requirements.
Note: To use the email feature, an ETH3 Ethernet card must be installed and the C-CPU
Ethernet Card type Prog/Diag/ECP/IPDialer/EMail selected in the IP Configuration dialog
box.
To add addresses to the Available Emails List:
1. On the Configure menu, click Cabinet.
2. Select the desired CAB6 cabinet, and then click the IP Dialer - Email tab.
3. Click the Email Accounts tab, and then do one of the following:
If the email account has already been configured, select the desired account, and then
click Edit.
— or —
If an email account needs to be configured, click Insert to add an account. See
Configuring email accounts.
4. In the Email Account Properties dialog box, click Add.
5. In the Email ID Configuration dialog box, enter the email address or the wireless
provider's email-to-text address, and then click OK. Example, for email
[email protected] or for text messaging [email protected].
6. Click OK.

To delete addresses from the Available Emails List:

Caution: Use care when deleting email addresses; you will not be asked to confirm the
deletion.
1. On the Configure menu, click Cabinet.
2. Select the desired CAB6 cabinet, and then click the IP Dialer - Email tab.
3. Click the Email Accounts tab.
4. Select the desired account, and then click Edit.
5. On the Email Account Properties dialog box, in the Available Emails List, select the
email to be removed, and then click Delete. You can select multiple addresses using
the Ctrl or Shift key on your keyboard.
6. Click OK.
See also
CAB6 IP configuration settings
Creating email distribution lists
Configuring email Accounts
Creating email distribution lists
The email distribution list allows you to send an email or text message to up to 20
addresses at one time.
Note: Before creating a distribution list, email addresses must have been added to the
account. See Adding and deleting email addresses for instructions.

To create a distribution list:

1. On the Configure menu, click Cabinet.
2. Select the desired CAB6 cabinet, and then click the IP Dialer - Email tab.
3. Click the Email Accounts tab, and then select the desired account.
4. Click Edit. The Email Account Properties dialog box opens.
5. Select up to 20 addresses from the Available Emails List, and then move them to
the Distribution List.
To move multiple addresses to the Distribution List, hold down the Shift or Ctrl key on
your keyboard, select the addresses, and then click the single right arrow. To move all
addresses, click the double right arrow.
To remove multiple addresses from the Distribution List, hold down the Shift or Ctrl key,
select the addresses, and then click the single left arrow. To remove all addresses, click
the double left arrow.
6. Click OK.
See also
Adding and deleting email addresses
Configuring email accounts
Overview of message annunciation routing
You can route messages to panels through network annunciating devices using message
annunciation routing. Note that message routing in systems using 3-CPU application code
V3.60 or earlier relies solely on network routing.
Message annunciation devices
Message annunciating devices are devices capable of displaying or printing event
messages. This includes LCD control-display modules, KPDISP keypad displays, remote
annunciators, and 3-CPUx printer ports.
Message annunciation groups
You can create message annunciation groups that contain annunciating devices, and then
use the groups to build message annunciation routes.
A default message annunciation group, labeled Default_Display_Group, initially contains all
annunciating devices in the project. You can add or remove items from this group at any
time. As you add new annunciating devices to the project, the system automatically adds
them to the default display group. You can create new message annunciation groups that
target selected panels, keypad displays, or printers.
Each project accommodates up to 255 message annunciation groups. Each panel, KPDISP
keypad display, remote annunciator, or printer port can belong to only one Message
Annunciation Group.
Message annunciation routes
Message annunciation routes are object properties that direct an object's event messages
to specific devices for display or printing. They are composed of one or more message
annunciation groups. There are two built-in message annunciation routes, labeled
All_Msg_Annunciation_Groups and No_Msg_Annunciation_Groups. You cannot change or
remove these routes. By default, the system sends all event messages to the
All_Msg_Annunciation_Groups route. Although you cannot change these routes, you can
create new message annunciation routes and assign them to objects at any time.
Each object has two different message annunciation route properties. The first,
Msg_Annunciation_Route_Label, contains the route used during times when the protected
site is occupied. The second, Alt Msg Annunciation Route Label, is used for events that
occur while the building is unoccupied.
Note: R-Series remote annunciators configured on an EST3X system using the Message
Annunciation Routing function annunciate certain state changes even though the state
changes are not displayed on the EST3X control panel.
Links to step-by-step instructions
The following topics provide instructions for working with message annunciation routing:
Creating a message annunciation group
Creating a message annunciation route
Defining an object's message annunciation routes
Creating a message annunciation route
Message annunciation routes contain one or more message annunciation groups. Up to 255
message annunciation routes can be created in each project.
To create a message annunciation route:
1. On SDU menu bar, click Configure > Msg Annunciation Routing,
— or—
From the Object Configuration dialog box, click the Msg Annunciation Routing button.
2. Click the Msg Annunciation Routing button. This opens the Message Annunciation
Routing dialog box.
3. Click New.
4. In the dialog that opens, enter a label for the new route.
5. In the table of available groups check the Enabled check box for each group to be
added to the route.
6. Click OK.
See also
Overview of message annunciation routing
Creating a message annunciation group
Defining an object's message annunciation routes
Creating a message annunciation group
Message annunciation groups make it possible to direct an object's event messages to one
or more LCD modules, Keypad Display modules, or printers. For more information on
message annunciation groups, see Overview of message annunciation routing.
To create a message annunciation group:
1. On the Configure menu, select Msg Annunciation Routing,
— or —
From the Object Configuration dialog box, click the Msg Annunciation Routing button.
2. Click the Msg Annunciation Groups button then click New.
3. In the dialog that opens, enter a label for the new group.
4. From the list of annunciating devices, select the items to be included in the group,
then click the Add button to add them to the group.
To select multiple items, press and hold the Ctrl key while selecting with the mouse.
To add all available devices to the group, click the Add All button.
To remove an item from the group, click the Remove button.
To remove all items from the group, click the Remove All button.
5. When you have finished, click OK.
See also
Overview of message annunciation routing
Creating a message annunciation route
Defining an object's message annunciation routes
Overview of logical outputs
Logical outputs are abstract entities that mimic the operation of nonsupervised relays. They
provide a convenient method of developing complex system interactions. Logical outputs
can be activated and restored from front panel menus or through rules programming.
Activating a logical output produces a relay confirmation event (RelayConfirmation or
RLYCFG) that can be incorporated in rules and used to drive further operations.
Note: Each project can contain up to 499 logical outputs.

Sample Rules Notes

[Rule 1] In this project, all smoke detectors, heat detectors, and
Alarm 'Floor*' : pull stations share the label scheme "Floor[floor
#]_[device type]". For example, Floor9_pull or
ON 'Logical_Output_Alarm';
Floor1_heat.
Rule 1 condenses all smoke detector, heat detector, and
pull station activations to a single point — the logical
output labeled Logical_Output_Alarm. Notice that Rule 2
uses the resulting relay confirmation to activate the
AND_Level2 group.
[Rule 2] Rule 2 states that each time the logical output labeled
RLYCFG Logical_Output_Alarm is turned on, one is added to the
'Logical_Output_Alarm' : activation count of the AND group.
ACTIVATE 'AND_Level2';

The following diagram illustrates the interaction between Rule 1 and Rule 2.
See also
Creating a logical output
Reconfiguring a logical output
Deleting a logical output
Changing the configuration of a logical output
This topic shows you how to change the address, object label, description, or custom
message associated with a logical output. If you need help writing rules that incorporate
logical outputs, see Using logical outputs.
To reconfigure a logical output:
1. On the Configure menu, select Logical Outputs. This opens the Logical Output
Manager.
2. Select the logical output to be changed, then click Edit. This opens the Logical
Output Properties dialog box.
3. Make whatever changes are needed to the Device Address, Logical Output Label,
or Description.
4. If you want to change the message associated with the object, click Edit Message
and make the necessary changes.
5. Click Save.
6. Click OK to close the Logical Output Properties dialog box.
7. Click Close to close the Logical Output Manager.
Creating a logical output
If you need background information on logical outputs, see Overview of logical outputs.

To create a logical output

1. On the Configure menu, select Logical Outputs.
2. Click New. The Logical Output Properties dialog box appears.
3. In the Device Address box, select or enter an address for the new logical output, or
keep the default value.
4. In the Logical Output Label box, enter a label to be used when writing rules to
program the logical output.
Tip: If you want to include the address as part of the label, enter the number symbol
(#) where the address is to appear. SDU automatically inserts the address. This is
especially useful for creating multiple logical outputs at once.
5. In the Description box, enter any information that will help to distinguish this logical
output from others in the database.
6. Click Edit Message. The Object Message Editor dialog box appears. Perform the
following steps:
Note: When a CDR-3 coder is used, do not use the # symbol in the Location Message.
In the Location Message box, enter a description of where the device is located. For a
two-line LCD, you can click the 1<->2 button and enter a second line of text.
In the Abbreviation box, enter a short form of the group's label to use when referring to
the group in the LCD command menu.
Check the Coder check box if a CDR-3 is connected to the system, and then select or
enter the numeric command string that you want sent to the coder when the group
changes to its active state. (For more information, see Sending events to a CDR-3 Bell
Coder.)
Click Save.
7. Click OK.
8. Click Close.
See also
Overview of logical outputs
Reconfiguring a logical output
Deleting a logical output
Deleting a logical output
Deleting a logical output removes it from the project database. Any rules that incorporate
the deleted logical output will no longer work.
To delete a logical output:
1. From the Configure menu, select Logical Outputs.
This opens the Logical Output Manager.
2. Select the logical output to be changed, then click Delete. The item is removed.
3. Click Save.
4. Click OK to close the Logical Output Properties dialog box.
5. Click Close to close the Logical Output Manager.
See also
Overview of logical outputs
Creating a logical output
Reconfiguring a logical output
Reconfiguring a logical output
You can change the address, object label, description, or custom message associated with
a logical output.
If you need help writing rules that incorporate logical outputs, see Using logical outputs.
To reconfigure a logical output
1. On the Configure menu, select Logical Outputs.
2. Select the logical output to be changed, then click Edit. This opens the Logical
Output Properties dialog box.
3. Make whatever changes are needed to the Device Address, Logical Output Label,
or Description.
4. If you was to change the message associated with the object, click Edit Message
and make the necessary changes.
5. Click Save.
6. Click OK to close the Logical Output Properties dialog box.
7. Click Close to close the Logical Output Manager.
See also
Overview of logical outputs
Creating a logical output
Deleting a logical output
Using logic groups
Combining devices into a logic groups provides a group response that is separate from
individual device responses. The following types of logic groups can be defined for system
programming.
Nonalarm logic groups (AND, instruction text, matrix)
Alarm logic groups (AND, matrix, zone)
Guard patrol groups
Service groups
AND groups: basic functionality
An AND Group is a collection of devices that provides a group response when a specified
number of members change to specific states — alarm, supervisory, trouble, monitor, or
normal.
For example, you can configure an AND Group with eight smoke detectors (SMK_1 through
SMK_8) that activates when any three go into alarm with the exception of SMK_5 which
can go into alarm or trouble.
An AND Group can be configured to signal an alarm, supervisory, trouble, or monitor
condition. This is configured in the SDU as the Activation Type. For example, you can create
one AND group that produces a trouble event when it activates and a second that produces
an alarm event.
Notes
In addition to the AND group's activation event, state changes by individual members
produce separate events that can be viewed on the LCD.
If a member can have more than one concurrent change in state, for example a
smoke detector that is in trouble and then goes into alarm, each change in state
counts as one activation.
When NA state is selected for a device, the device increments the activation count
when it is in a normal condition. You can also use NA in combination with any active
state such as Q1. When both Q1 and NA are selected for a device, the activation
count decrements when the device goes into alarm.
Back to top
AND groups: advanced functionality
In addition to the basic AND group described above, you can also create virtual AND
groups. This type of AND group has no members. It has an activation number and type, and
its responses are created by means of rules programming. AND groups are activated using
the Activate command.
Each time a rule sends an activation command to the AND group, the group's activation
counter increments by one. When the number stored in the counter equals the Activation
number, the AND group activates.
Back to top
Matrix groups
A matrix group is a collection of devices that are grouped together to provide a unique
response similar to the way an AND group operates. In addition to an activation number, a
matrix group searches the devices that surround the first active device, for a second device
to go active before activating the group. Each device within a matrix group is assigned a set
of x-y coordinates to create a matrix grid corresponding to the mounting locations.
The radius of a matrix specifies the size of the search. The search radius defines the
number of devices away from the first active device that the system searches for a second
device. The activation number of a matrix group specifies the number of device activations
that must occur to turn on the output of the matrix group. Either condition will activate the
output of the matrix group.
A matrix group can be configured to generate any activation type (alarm, supervisory,
trouble, or monitor) and can consist of any of the device types found in an AND group.
Back to top
Instruction text groups
Instruction text groups provide additional, detailed instructions or warnings for any active
device in the group. You can further qualify an active device by its active state. For
example, you can have the instruction text group activate when a device goes into alarm or
into trouble.
When any device in the group goes active, an instruction text active event is sent to the
monitor queue of the LCD module. The message text is automatically routed through the
printer port. The message text can also be reviewed by selecting the instruction text active
event in the monitor queue and pressing the Details switch.
Back to top
Zone groups
A zone group is a collection of input devices that provides a unique response separate from
the individual device responses. When any number of devices in a zone group go into alarm,
a single zone active event is sent to the LCD module. To determine which devices in the
zone are active, select the zone active event and press the Details switch.
You can also configure zone groups to activate when any device in the group goes into
trouble.
With CPU firmware version 1.4 or later, you no longer need to create a zone group or
configure the system for proprietary operation in order to utilize a CDR-3 Zone Coder.
You can place the zone code at the beginning of the message of each individual point used
to activate the CDR-3. There are two advantages to not activating a CDR-3 from a zone
group:
The LCD displays each device activation as a separate alarm event
Subsequent device activations will initialize succeeding alarms
Setting the Zone Group Inhibit option prevents the zone group's response from reactivating
when subsequent members of the group go active after outputs have been silenced.
Back to top
Guard patrol groups
A guard patrol group is a collection of input devices that must be activated in a sequential
order and within specified time constraints. Each defined guard patrol group lists the
devices, and the minimum and maximum times to reach each device. A rule must be written
that defines the actions to be taken in the event of an out of sequence or delinquent patrol.
Back to top
Service groups
A service group is a collection of devices that are grouped together for testing purposes.
When enabled, the service group automatically disables the normal alarm response of the
devices and provides a common alternate test response.
Back to top
Project limits for logic groups and objects in logic groups
The following table provides information that can be used to determine the number of
allotments remaining in a project for specific types of logic groups.

Max single object Max number logic

Group type group groups Max objects per
memberships group
AND 100 999 See note 4
Check-in 1 255 255
Command list N/A 2,000 N/A
Guard patrol 1 255 63
Instruction text 4 999 See note 4
Logical output N/A 499 See note 4
Matrix 100 255 See note 4
Partition 255 255 See note 4
Service 1 255 See note 4
Time Controls N/A 255 N/A
Zone 1 999 See note 4

Notes
1. Max single object group memberships: Specifies how many logic groups of one
type an object can belong to. For example, a smoke detector can belong to five
different AND groups, but only one Zone group.
2. Max objects per group: Specifies how many different objects can be placed in a
single group.
3. Although most objects can belong to multiple partitions, the following Security and
Access Control objects operate differently:
Card reader controller: For each CRC added to a 3-SAC, three objects can be
added to a partition. This includes the CRC itself plus the CRC’s two input circuits.
These three objects can be members of a single partition only.
Keypad display: The KPDISP can belong to multiple partitions.
4. The actual limit depends on the remaining CPU memory for a given project, which is
affected by overall system configuration and programming.
See also
Calculating how many logic group allotments remain
Calculating how many logic group allotments remain
Logic group addresses are assigned sequentially and, for most logic groups, the numbering
remains sequential when groups are added or removed. For example, a project has 100
AND groups, and AND group 50 is deleted. As a result, AND group addresses 51 to 100
become 50 to 99. So for most logic groups, you can calculate the remaining number of
allotments by subtracting the highest address from the maximum allowed allotments for that
type.
Note: This information is not currently available for Time Controls, Command Lists, and
Logical Outputs.
See also
Project limits for logic groups and objects in logic groups
Configuring a guard patrol group
A guard patrol group is a collection of guard station devices that provides a unique system
response when any member of the group fails to change to the active state in the correct
order or in the specified time limits.
Note: Only GUARD device types can be added to a guard patrol group.
The devices in the group can be arranged in one or more sequences or routes. A route can
be started by:
Activating the route through the LCD
Pressing a programmed switch (e.g. via a programmed rule)
Sending a gateway connection command (e.g. via a FireWorks command)
Triggering the first device in a route
Note that different routes can start with the same device. In such a situation, if you start the
guard patrol route by activating the first station, the system assumes you are starting the
route with the lowest number. The other routes that start with that station must be started
by some other method.
To configure a guard patrol group:
1. On the Configure menu, select Objects.
2. On the Object Configuration tab, check the Pick check box for each device that you
want in the group.
Tip: Use the display filters to limit the number of devices displayed in the
configuration table.
3. Click the Guard Patrol tab, and then perform the following steps:
Click New Group or select an existing group from the Available Groups list. When you
click New Group, the SDU creates a new group with a default label. To change the label,
enter a new label in the Label for Guard Patrol Group box.
Click Add Devices.
4. Click Edit Message, and then perform the following steps:
Note: When a CDR-3 coder is used, do not use the # symbol in the Location Message.
In the Location Message box, enter a description of where the device is located. For a
two-line LCD, you can click the 1<->2 button and enter a second line of text.
In the Abbreviation box, enter a short form of the group's label to use when referring to
the group in the LCD command menu
Check the Coder check box if a CDR-3 is connected to the system, and then select or
enter the numeric command string that you want sent to the coder when the group
changes to its active state. (For more information, see Sending events to a CDR-3 Bell
Coder.)
Click Save.
5. Click the Object Configuration tab, and then perform the following steps:
Select the guard patrol group in the object configuration table.
Select the Routing Label for the network route that you want to receive the location
message when the protected site is occupied.
Select the Alt Routing Label for the network route that you want to receive the location
message when the protected site is unoccupied.
6. Click the Guard Patrol tab, and then perform the following steps:
Click New Route to add the number of distinct routes this guard patrol group needs.
Click View Guard Patrol to define each route.
See Defining a guard patrol tour for details on defining routes.
7. Click Close.
See also
Deleting a logic group
Removing devices from a logic group
Deleting a guard patrol tour
Defining a guard patrol tour
Object Configuration - Guard Patrol tab
Project limits for logic groups and objects in logic groups
Configuring a matrix group
A matrix group is a collection of devices that are grouped together in the database in order
to provide a unique system response based on a specified number state changes (a
member's Alarm, Supervisory, Trouble, or Monitor state whose active status serves as an
input for activating the AND Group) similar to the way an AND Group operates.
Matrix groups change to an active state when either of the following two conditions are met:
When the number of qualified state changes equals or exceeds the Activation
Number setting
When more than one device in a search radius changes to a qualified active state.
A matrix group's active state can be configured for Alarm, Supervisory, Trouble, or Monitor.
To configure a matrix group:
1. On the Configure menu, select Objects.
2. On the Object Configuration tab, check the Pick check box for each device that you
want in the group.
Note: In the Canadian Local and Proprietary marketplace, do not add CO devices to a
Matrix group. When the group activates, CO devices in the group would not be correctly
prioritized.
Tip: Use the display filters to limit the number of devices displayed in the configuration
table.
3. Click the Matrix tab, and then perform the following steps:
Click New Group or select an existing group from the Available Groups list. When you
click New Group, the SDU creates a new group with a default label. To change the label,
enter a new label in the Label for Matrix Group box.
Click Add Devices.
In the Activation Number box, select or enter the number of qualified state changes
required to activate the group.
In the Radius box, select or enter the size of the search radius. The search radius is the
area surrounding an active device on the matrix grid in which a second device must
change to a qualified active state before the group changes to an active state.
In the Activation Event box, select the event produced when the group changes to the
active state.
For each member of the group, check the check box for each type of state change that
you want counted as a device activation.
4. Click Edit Message. The Object Message Editor dialog box appears. Perform the
following steps:
Note: When a CDR-3 coder is used, do not use the # symbol in the Location Message.
In the Location Message box, enter a description of where the device is located. For a
two-line LCD, you can click the 1<->2 button and enter a second line of text.
In the Abbreviation box, enter a short form of the group's label to use when referring to
the group in the LCD command menu
Check the Coder check box if a CDR-3 is connected to the system, and then select or
enter the numeric command string that you want sent to the coder when the group
changes to its active state. (For more information, see Sending events to a CDR-3 Bell
Coder.)
Click Save.
5. Click the Object Configuration tab, and then perform the following steps:
Select the matrix group in the object configuration table.
Select the Message Annunciation Route Label or the network route that you want to
receive the location message when the protected site is occupied.
Select the Alternate Message Annunciation Route Label for the network route that you
want to receive the location message when the protected site is unoccupied.
6. Click Close.
See also
Deleting a logic group
Removing devices from a logic group
Defining a matrix grid
Object Configuration - Matrix tab
Project limits for logic groups and objects in logic groups
Configuring a partition group
Note: Partition groups are not supported in a networks consisting only of 3X panels (3X
Only networks).
To configure a partition group:
1. On the Configure menu, select Objects.
2. On the Object Configuration tab, check the Pick check box for each device that you
want in the group.
Tip: Use the display filters to limit the number of devices displayed in the
configuration table.
3. Click the Partitions tab, and then perform the following steps:
Click New Partition or select an existing partition from the Available Groups list. When
you click New Partition, the SDU creates a new partition with a default label. To change
the label, enter a new name in the Label for Partition box.
Click Add Devices.
In the Max Bypassed box, select or enter how many devices in the partition can be
bypassed before the system prohibits arming the partition.
In the Entry Delay Timer box, select or enter the time delay allowed after a perimeter
door is opened before the system activates a security alarm. This delay allows site staff
to enter the site and disarm the partition without activating an alarm.
In the Exit Delay Timer boxes, select or enter the time delay allowed after arming a
partition during which perimeter doors can remain open without activating a security
alarm. This delay allows site staff to arm a partition and exit from the site without
activating an alarm.
For each member of the partition, check the check box for each type of state change
that you want counted as a device activation.
4. Click Edit Message. The Object Message Editor dialog box appears. Perform the
following steps.
Note: When a CDR-3 coder is used, do not use the # symbol in the Location Message.
In the Location Message box, enter a description of where the device is located. For a
two-line LCD, you can click the 1<->2 button and enter a second line of text.
In the Abbreviation box, enter a short form of the group's label to use when referring to
the group in the LCD command menu.
Check the Coder check box if a CDR-3 is connected to the system, and then select or
enter the numeric command string that you want sent to the coder when the group
changes to its active state. (For more information, see Sending events to a CDR-3 Bell
Coder.)
Click Save.
5. Click the Object Configuration tab, and then perform the following steps:
Select the partition group in the object configuration table.
Select the Message Annunciation Route Label for the network route that you want to
receive the location message when the protected site is occupied.
Select the Alternate Message Annunciation Route Label for the network route that you
want to receive the location message when the protected site is unoccupied.
6. Click Close.
See also
Deleting a logic group
Removing devices from a logic group
Object Configuration - Partitions tab
Project limits for logic groups and objects in logic groups
Configuring a service group
A service group is a collection of devices that are grouped together in the database to
provide a unique response for testing purposes. When enabled, the service group
automatically disables the member device's normal alarm response, and provides a
common alternate test response.

To configure a service group:

1. On the Configure menu, select Objects.
2. On the Object Configuration tab, check the Pick check box for each device that you
want in the group.
Tip: Use the display filters to limit the number of devices displayed in the
configuration table.
3. Click the Service tab, and then perform the following steps:
Click New Group or select an existing group from the Available Groups list. When you
click New Group, the SDU creates a new group with a default label. To change the label,
enter a new label in the Label for Service Group box.
Click Add Devices.
4. Click Edit Message. The Object Message Editor dialog box appears. Perform the
following steps:
Note: When a CDR-3 coder is used, do not use the # symbol in the Location Message.
In the Location Message box, enter a description of where the device is located. For a
two-line LCD, you can click the 1<->2 button and enter a second line of text.
In the Abbreviation box, enter a short form of the group's label to use when referring to
the group in the LCD command menu
Check the Coder check box if a CDR-3 is connected to the system, and then select or
enter the numeric command string that you want sent to the coder when the group
changes to its active state. (For more information, see Sending events to a CDR-3 Bell
Coder.)
Click Save.
5. Click the Object Configuration tab, and then perform the following steps:
Select the service group in the object configuration table.
Select the Message Annunciation Route Label for the network route that you want to
receive the location message when the protected site is occupied.
Select the Alternate Message Annunciation Route Label for the network route that you
want to receive the location message when the protected site is unoccupied.
6. Click Close.
See also
Deleting a logic group
Removing devices from a logic group
Object Configuration - Service tab
Project limits for logic groups and objects in logic groups
Configuring a zone group
A zone group is a collection of input devices that are grouped in order to provide a unique
response separate from their individual device responses.
Zone groups go into alarm when any member of the group goes active. Regardless of
which devices in the group go into alarm, only the group's active state is sent to the panel.
Zone groups can also be configured to activate when any device in the group goes into
trouble.
To configure a zone group:
1. On the Configure menu, select Objects.
2. On the Object Configuration tab, check the Pick check box for each device that you
want in the group.
Note: In the Canadian Local and Proprietary marketplace, do not add CO devices to a
Zone group. When the group activates, CO devices in the group would not be correctly
prioritized.
Tip: Use the display filters to limit the number of devices displayed in the configuration
table.
3. Click the Zone tab, and then perform the following steps:
Click New Group or select an existing group from the Available Groups list. When you
click New Group, the SDU creates a new group with a default label. To change the label,
enter a new label in the Label for Zone Group box.
Click Add Devices.
Check the Enable Trouble Zone check box if you want the zone group to change to the
active Trouble state when any of its member devices go into trouble.
4. Click Edit Message. The Object Message Editor dialog box appears. Perform the
following steps:
Note: When a CDR-3 coder is used, do not use the # symbol in the Location Message.
In the Location Message box, enter a description of where the device is located. For a
two-line LCD, you can click the 1<->2 button and enter a second line of text.
In the Abbreviation box, enter a short form of the group's label to use when referring to
the group in the LCD command menu.
Check the Coder check box if a CDR-3 is connected to the system, and then select or
enter the numeric command string that you want sent to the coder when the group
changes to its active state. (For more information, see Sending events to a CDR-3 Bell
Coder.)
Click Save.
5. Click the Object Configuration tab, and then perform the following steps:
Select the zone group in the object configuration table.
Select the Message Annunciation Route Label for the network route that you want to
receive the location message when the protected site is occupied.
Select the Alternate Message Annunciation Route Label for the network route that you
want to receive the location message when the protected site is unoccupied.
6. Click Close.
See also
Deleting a logic group
Removing devices from a logic group
Sending events to a CDR-3 Bell Coder
Configuring CPU operation
Object Configuration - Zone tab
Project limits for logic groups and objects in logic groups
Configuring an AND group
An AND group is a collection of devices that are grouped in the database in order to provide
a group response that is separate from that of its member devices. The AND group
activates when a specified number of devices change to a specified state.
The number of status changes required to produce a group response is call the Activation
Number. The specified state can be alarm, supervisory, trouble, monitor, or not active (NA).
AND groups can be configured to signal an alarm, supervisory, trouble, or monitor condition
upon activation.
Note: When NA is selected, the device increments the activation count when it is in a
normal condition. You can also use NA in combination with any active state such as Q1.
When both Q1 and NA are selected for a device, the activation count decrements when the
device goes into alarm.
Caution: Active alarm inputs from devices in an AND group configured to signal a
supervisory, trouble, or monitor conditions does not put the control panel into alarm. The
common alarm relay on the CPU module, however, will still activate.

To create an AND group:

1. On the Configure menu, select Objects.
2. On the Object Configuration tab, check the Pick check box for each device that you
want in the group.
Note: In the Canadian Local and Proprietary marketplace, do not add CO devices to an
AND group. When the group activates, CO devices in the group would not be correctly
prioritized.
Tip: Use the display filters to limit the number of devices displayed in the configuration
table.
3. Click the AND tab, and then perform the following steps:
Click New Group or select an existing group from the Available Groups list. When you
click New Group, the SDU creates a new group with a default label. To change the label,
enter a new label in the Label for AND Group box.
Click Add Devices.
In the Activation Number box, select or enter the number of qualified state changes
required to activate the group.
In the Activation Event box, select the event to be produced when the group is activated.
For each member, check the check box for each type of state change that you want
counted as a device activation.
4. Click Edit Message. The Object Message Editor appears. Perform the following
steps:
Note: When a CDR-3 coder is used, do not use the # symbol in the Location Message.
In the Location Message box, enter a description of where the device is located. For a
two-line LCD, you can click the 1<->2 button and enter a second line of text.
In the Abbreviation box, enter a short form of the group's label to use when referring to
the group in the LCD command menu
Check the Coder check box if a CDR-3 is connected to the system, and then select or
enter the numeric command string that you want sent to the coder when the group
changes to its active state. (For more information, see Sending events to a CDR-3 Bell
Coder.)
Click Save
5. Click the Object Configuration tab, and then perform the following steps:
Select the AND group in the object configuration table.
Select the Message Annunciation Route Label for the network route that you want to
receive the location message when the protected site is occupied.
Select the Alternate Message Annunciation Route Label for the network route that you
want to receive the location message when the protected site is unoccupied.
6. Click Close.
See also
Deleting a logic group
Removing devices from a logic group
Sending events to a CDR-3 Bell Coder
Object Configuration - AND tab
Creating a message annunciation route
Creating a message annunciation group
Project limits for logic groups and objects in logic groups
Configuring an instruction text group
An instruction text group is a collection of devices that are grouped together in the database
in order to provide additional detailed instructions or warnings when any device in the group
changes to a qualified active state. For example, you can have the instruction text group
activate when a device goes into alarm or into trouble.

To configure an instruction text group.

1. On the Configure menu, select Objects
2. On the Object Configuration tab, check the Pick check box for each device that you
want in the group.
Tip: Use the display filters to limit the number of devices displayed in the
configuration table.
3. Click the Instruction Text tab, and then perform the following steps:
Click New Group or select an existing group from the Available Groups list. When you
click New Group, the SDU creates a new group with a default label. To change the label,
enter a new label in the Label for Instruction Text Group box.
Click Add Devices.
For each member of the group, select the check box for each type of state change
required to activate the group.
4. Click Edit Message. The Object Message Editor appears. Perform the following
steps:
Note: When a CDR-3 coder is used, do not use the # symbol in the Location Message.
In the Location Message box, enter a description of where the device is located. For a
two-line LCD, you can click the 1<->2 button and enter a second line of text.
In the Abbreviation box, enter a short form of the group's label to use when referring to
the group in the LCD command menu.
Check the Coder check box if a CDR-3 is connected to the system, and then select or
enter the numeric command string that you want sent to the coder when the group
changes to its active state. (For more information, see Sending events to a CDR-3 Bell
Coder.)
5. Click the Object Configuration tab, and then perform the following steps:
Select the instruction text group in the object configuration table.
Select the Message Annunciation Route Label for the network route that you want to
receive the location message when the protected site is occupied.
Select the Alternate Message Annunciation Route Label for the network route that you
want to receive the location message when the protected site is unoccupied.
6. Click Close.
See also
Deleting a logic group
Removing devices from a logic group
Sending events to an ancillary printer
Object Configuration - Instruction Text tab
Project limits for logic groups and objects in logic groups
Defining a guard patrol tour
A guard patrol tour or route designates the route that the security guard takes when
activating guard stations. You can define more than one guard patrol tour for each guard
patrol group. Each route can define a different sequence of devices and different limit times
for each device.

To define a guard patrol tour:

1. On the Configure menu, select Objects, and then click the Guard Patrol tab.
2. Select the guard patrol group from the Available Groups list.
3. Click New Route for each tour you want to define for the selected guard patrol
group.
4. Click View Guard Patrol.
Clicking View Guard Patrol opens the Guard Patrol Group Designer dialog with the
controls set for route 1 of the selected guard patrol group.
5. For each Station:
Select a device from the Station Label list.
Set the Minimum Time box to the minimum amount of time it takes to reach the
station from the previous point.
Set the Maximum Time box to the maximum amount of time it takes to reach the
station from the previous point.
Repeat until all the devices are assigned a station number and min/max times.
6. If you are defining more than one route for the guard patrol group, set Route ID for
the next route number and repeat step 5.
7. Click Close.
Defining a matrix grid
Each member of a matrix group must be assigned a set of x-y coordinates in order to form
a grid for the protected area. The system uses the x-y coordinates to determine the search
radius around an active device.
To define a matrix grid:
1. On the Configure menu, select Objects, and then click the MATRIX Groups tab.
2. Select the matrix group in the Available Groups list then click View Matrix.
Clicking View Matrix opens the Matrix Group Designer dialog box. The Matrix Group
Designer has a grid for assigning an x-y coordinate to each member in the group.
3. Double-click the table cell at column x1 and row y1 then click the appropriate device.
4. Repeat until each member of the group is assigned a set of coordinates.
5. Click OK
Deleting a guard patrol tour
After deleting a guard patrol tour (route), the route is removed from the database and the
next route's ID is decremented. For example, if you delete route 2, route 3 then becomes
route 2.
To delete a guard patrol route:
1. From the Configure menu, select Objects
2. Click the Guard Patrol Groups data sheet tab.
3. On the Guard Patrol Groups data sheet, click View Guard Patrol.
4. In the Guard Patrol Group Label list box, select the Guard Patrol group whose route
you are deleting.
5. In the Route ID list box, select the route being deleted.
6. Click Delete Route.
7. Click Close.
Deleting a logic group
Deleting a logic group removes the group and its corresponding object from the project
database.
To delete a logic group:
1. From the Configure menu, select Objects
2. Click the logic group's tab.
3. In the Available Groups list, select the group that you want to delete.
4. Click Delete Group.
Removing devices from a logic group
To remove devices from a logic group:
1. From the Configure menu, select Objects
2. Click the logic group's tab.
3. In the Available Groups list, select the group that contains the devices you want
removed.
4. To remove a single device, select the device in the Devices in Selected Group list,
and then click Remove Device.
To remove all the devices, click Clear Devices.
5. Click Close.
How to use the Audio Message Recorder
The Audio Message Recorder is used to create the message database used by the 3-ASU.
The message database can consist of tones or of dialog for voice messaging applications.
Building the message database is accomplished using the 3-ASU configuration dialog box
and the Audio Message Recorder tool. Messages can be recorded or imported from other
sources to create libraries from which to build the message database. To open the Audio
Message Recorder, select Tools from the menu bar, and then click Audio.
Notes
You must have a 3-ASU defined in the system to use the Audio Message Recorder
tool. The Audio command (Tools > Audio) is unavailable when an audio source unit
has not been defined in the cabinet configuration.
You can check the available memory for the selected 3-ASU by clicking the Audio
Messages tab, selecting the Audio Messages menu, and then clicking Memory
Usage.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
The Audio Message Recorder screen contains two tabs:
Audio Messages tab: Records messages and customizes them by adding prerecorded
sound clips. When you click the Audio Messages tab, the Audio Messages menu and
toolbar provide commands and buttons used to create the message.
Default message records are automatically created for the 3-ASU and EAEC; however,
you must add their audio content. The message record names show in the Messages
box.
Audio Clips tab: Creates libraries of audio clips to use for customizing messages. Clips
can be recorded or imported from other sources. When you click the Audio Clips tab, the
Clip Libraries and Clips menus, and toolbar provide commands and buttons used to
create clips.
The Lib1 Clip Library is automatically created and contains several prerecorded clips.
The clip names show in the Clips box.
Each tab contains four control buttons: Play, Record, Pause, and Stop.
Play button: Click to start the playback of the selected sound file.
Record button: Click to start the record function. The file length counter increments
while recording.
Pause button: Click to temporarily pause the recording function.
Stop button: Click to stop the record/playback function and reset the current position
counter to zero.
Default evacuation and alert messages should be generic. Only the default alert message is
broadcast on the alert channel. The default evacuation message is broadcast when two fire
floors exist to avoid confusion.
See also
Audio Message Configuration - Audio Messages tab
Audio Message Configuration - Audio Clips tab
Adding content to an audio message record
Adding content to an audio message record
You will use the Audio Message Recorder to add content to message records. To open the
Audio Message Recorder, select Tools on the menu bar, and then click Audio.
Add content to a message record by recording a message, adding an audio clip, or
importing a prerecorded message.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
Note: Message content for the default messages must be recorded. Default evacuation
and default alert messages should be generic. Only the default alert message is broadcast
on the alert channel and the default evacuation message is broadcast when two fire floors
exist to avoid confusion.
See also
Recording the audio message content
Adding audio clips to a message
Importing a prerecorded message or prerecorded clip
Adding audio message records
Importing a prerecorded message or prerecorded clip
Adding audio clips to a message
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
Note: A single message, including the recorded message, the pre-clip, and the post-clip,
cannot be longer than 40 seconds independent of memory size.

To add a clip to the end of an audio message:

1. On the Tools menu, click Audio.
2. Click the Audio Messages tab.
3. In the ASU list, click the audio source unit.
4. In the Messages box, click the message record.
5. On the toolbar, click Add a Clip to End of Message.
The Audio Message Recorder switches to the Audio Clips tab.
6. Select a library from the Clip Library list, and then select an audio clip from the Clips
box.
7. Click Add.
The Audio Message Recorder switches back to the Audio Messages tab.
The audio clip is added to the end of the selected message and displays in the Script box.
In addition, the Message Length value increases accordingly. To hear the modified
message, click the Play button.
To add a clip to the beginning of an audio message:
1. On the Tools menu, click Audio.
2. Click the Audio Messages tab.
3. In the ASU list, click the audio source unit.
4. In the Messages box, click the message record.
5. On the toolbar, click Add a Clip to Beginning of Message.
The Audio Message Recorder switches to the Audio Clips tab.
6. Select a library from the Clip Library list, and then select an audio clip from the Clips
box.
7. Click Add.
The Audio Message Recorder switches back to the Audio Messages tab.
The audio clip is added to the beginning of the selected message and displays in the Script
box. In addition, the Message Length value increases accordingly. To hear the modified
message, click the Play button.
See also
Working with audio Clip libraries
Adding new audio clips
Recording the audio clip content
Importing a prerecorded message or prerecorded clip
Recording the audio message content
Recording the audio message using the Audio Message Recorder is one way of adding
content to a message record.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
Notes
Keep message content for the default evacuation and default alert messages as
generic as possible.
When two fire floors exist, the audio source unit broadcasts the default evacuation
message to avoid confusion.
You cannot record a message longer than 35 seconds. A single message, including
the recorded message, the pre-clip, and the post-clip, cannot be longer than 40
seconds independent of memory size.
You can use the Script box as a teleprompter when recording the message, or to
describe the message content.
To record the message content:
1. On the Tools menu, click Audio.
2. Click the Audio Messages tab.
3. In the ASU list, click the audio source unit.
4. In the Messages box, click the message record.
5. Click Record, and then speak slowly and clearly into the microphone. You can pause
and resume recording as needed. When you finish recording the message, click
Stop.
When you click the Stop button, the recording is automatically attached to the selected
message record. You can modify the message content by adding audio clips before and
after the message. If you need to clear the message content and start again, click Clear
Message on the toolbar.
6. You can enter a brief description or the exact text of the recording in the Script box.
See also
Adding audio clips to a message
Importing a prerecorded message or prerecorded clip
Audio Message Configuration - Audio Messages tab
Recording the audio clip content
Recording an audio clip is one way of customizing evacuation and alert signals using a voice
message.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
Notes
Voice message audio clips can only be edited by re-recording them.
The quality of your recorded messages will only be as good as the microphone you
use and the person doing the recording.
You cannot record a clip longer than 35 seconds. A single message, including the
recorded message, the pre-clip, and the post-clip, cannot be longer than 40
seconds independent of memory size.
To record a voice message audio clip:
1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. In the Clip Library list, click the library source or create a new clip library.
4. In the Clips box, click the audio clip or create a new audio clip.
5. Click Record, and then speak slowly and clearly into the microphone.
You can pause and resume recording as needed. When you finish recording the
message, click Stop.
When you click the Stop button, the recording is automatically attached to the selected
clip. If you need to clear the content and start again, click Clear Clip on the toolbar.
6. You can enter a brief description or the exact text of the recording in the Script box.
See also
Working with audio clip libraries
Adding new audio clips
Importing a prerecorded message or prerecorded clip
Importing a prerecorded message is another method of adding content to an audio
message or audio clip record. The system imports the script text for a message along with
the message's recorded audio.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
For import, a message must be in the following format:
Type: Any valid WAV file (conversion to a particular sample rate is not required)
Message length: 39 seconds maximum
Caution: When you import a message the system overwrites the existing message content.
Note: Importing a message or clip that does not meet the specified format can result in a
"Division by 0" error.
To import a prerecorded message to an audio message:
1. On the Tools menu, click Audio.
2. Click the Audio Messages tab.
3. In the ASU list, click the audio source unit.
4. In the Messages box, click the message record.
5. On the toolbar, click Import Message from File.
6. Browse to the message you want to import, and then click Open.
7. You can enter a brief description or the exact text of the imported message in the
Script box.

To import a prerecorded message to an audio clip:

1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. In the Clip Library list, click the library source.
4. In the Clips list, click the audio clip.
5. On the toolbar, click Import Clip from File.
6. Browse to the clip you want to import, and then click Open.
7. You can enter a brief description or the exact text of the imported clip in the Script
box.
See also
Adding audio message records
Adding new audio clips
Exporting audio messages and clips
Exporting audio messages and clips allows you save them to a file directory.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
To export an audio message:
1. On the Tools menu, click Audio.
2. Click the Audio Messages tab.
3. In the ASU list, click the audio source unit.
4. In the Messages box, click the message record.
5. On the toolbar, click Export Message to a File.
6. Browse to the location where you want to save the message, and then click Save.
To export an audio clip:
1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. In the Clip Library list, click the library source.
4. In the Clips box, click the audio clip.
5. On the toolbar, click Export Clip to a File.
6. Browse to the location where you want to save the message, and then click Save.
Adding audio message records
You can create custom audio message records that can be used in addition to the four
default message records.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.

To add an audio message record:

1. On the Tools menu, click Audio.
2. Click the Audio Messages tab.
3. In the ASU list, select the audio source unit.
4. On the toolbar, click New Message.
5. Enter a label (name) for the message record, and then click OK.
To add content to the message, see Adding content to an audio message record.
See also
How to use the Audio Message Recorder
Editing and deleting audio messages
Adding new audio clips
You can create new audio clips that can be used for customized messages.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
To add an audio clip:
1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. In the Clip Library list, click the library source or create a new clip library.
4. On the toolbar, click New Clip.
5. Enter a label (name) for the clip, and then click OK.
6. To add the audio to the clip, see Recording the audio clip content or Importing a
prerecorded message or prerecorded clip.
When you close the Audio Message Recorder, the SDU alphabetizes the clips in the library
by their label name, and consequently changes their index value. Rules using a clip name
are not affected by a change to the index value.
See also
How to use the Audio Message Recorder
Working with audio clip libraries
Editing and deleting audio clips
Working with audio clip libraries
Audio clip libraries store audio clips that can be added to message records. The Lib1 Clip
Library is automatically created and contains several prerecorded clips. You can add and
delete libraries, and change library names from the Clip Libraries menu.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
Creating an audio clip library:
1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. On the Clip Libraries menu, click New Library.
4. Enter a label (name) for the library, and then click OK.
5. To add clips to the library, see Adding new audio clips.
Deleting an audio clip library
Caution: Deleting an audio clip library also deletes any custom clips in it.

To delete an audio clip library:

1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. In the Clip Library list, select the library to be deleted.
4. On the Clip Libraries menu, click Delete Library.
5. Click Yes to delete the library, or No to cancel the action.
Changing an audio clip library name
1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. In the Clip Library list, select the library to be changed.
4. On the Clip Libraries menu, click Edit Library Name.
5. Enter a new label (name) for the library, and then click OK.
See also
Audio Message Configuration - Audio Clips tab
Editing and deleting audio clips
Editing and deleting audio messages
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
To change a message record name:
1. On the Tools menu, click Audio.
2. Click the Audio Messages tab.
3. In the ASU list, click the audio source unit.
4. In the Messages box, click the message record.
5. On the toolbar, click Edit Message.
6. Enter the new label (name) for the message record, and then click OK

To clear message record content:

1. On the Tools menu, click Audio.
2. Click the Audio Messages tab.
3. In the ASU list, click the audio source unit.
4. In the Messages box, click the message record.
5. On the toolbar, click Clear Message.
6. Click Yes to clear the message content, or No to cancel the action.
To replace the content, see Adding content to an audio message record.
To delete a message record:
1. On the Tools menu, click Audio.
2. Click the Audio Messages tab.
3. In the ASU list, click the audio source unit.
4. In the Messages box, click the message record.
5. On the toolbar, click Delete Message.
6. Click Yes to delete the message or No to cancel the action.
See also
Adding audio message records
Editing and deleting audio clips
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
To change a clip name:
1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. In the Clip Library list, click the library source.
4. In the Clips box, click the audio clip.
5. On the toolbar, click Edit Clip.
6. Enter the new label (name) for the clip, and then click OK.

To clear clip content:

1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. In the Clip Library list, click the library source.
4. In the Clips box, click the audio clip.
5. On the toolbar, click Clear Clip.
6. Click Yes to clear the clip content, or No to cancel the action.
To replace the content, see Recording the audio clip content.
To delete a clip:
1. On the Tools menu, click Audio.
2. Click the Audio Clips tab.
3. In the Clip Library list, click the library source.
4. In the Clips box, click the audio clip.
5. On the toolbar, click Delete Clip.
6. Click Yes to delete the clip or No to cancel the action.
See also
Adding new audio clips
Overview of the Resource Profile Manager
The Resource Profile Manager (RPM) is an add-on tool that integrates with the SDU. To
start the RPM, select Resource Profile Manager On the Tools menu.
The RPM lets you:
Create a description of the companies and buildings at a site
Assign security and access control devices to companies and buildings
Specify a primary company (owner) for CRCs
Allocate device resources among companies that share the devices
This information is displayed in a two-pane window that includes a tree structure and a
details pane. The tree structure shows the organization of companies and buildings and the
assignment of partitions and devices to the buildings. The details pane shows the labels,
properties, and allocation numbers for the current tree selection.
The RPM lets you export resource profiles for individual companies. You can later import
these profiles into the Access Control Database (ACDB) and Keypad Display Configuration
(KDC) programs. Once imported, the profiles determine what the users see and control
when creating their portions of the security or access control system.
To create and distribute resource profiles:
1. Enter company and installer contact information.
2. Create buildings and assign them to companies.
3. Assign partitions and devices to the buildings for each company.
4. Allocate device resources to each company.
5. Export a resource profile for each company.
The RPM includes a Mass Assign function to help you establish a uniform baseline
allocation of resources. A summary is available so you can review and print the profile in
several different forms.
See also
RPM mass assign function
RPM Summary report
Entering company and installer information in the RPM
It is important to enter the correct contact information for your company and for all
companies in the project. Information about your company (as the installer) tells the ACDB
or KDC user who to contact for support or enhancements. Project company information
tells you where to send resource profile updates when the project changes.
Start by entering information for your company. The RPM refers to you as the RPM
Operator.
To enter your company information:
1. On the File menu, select RPM Operator - Address and Contact.
2. Complete the boxes in the RPM Operator - Address and Contact Information dialog
box.
3. Click OK to save the information and close the dialog box.
You can repeat this process to revise your company information at any time.
To enter project company information:
1. Select a company from the Company Tree.
2. On the Companies menu, select Address and Contact.
3. Complete the boxes in the Company Address and Contact Information dialog box.
The initial values for Company Name and Description are taken from SDU, but you
can revise them here. This has no impact on SDU definition.
4. Click OK to save the information and close the dialog box.
5. Repeat steps 1 through 4 for all companies in the project.
You can repeat this process to revise the project company information at any time.
Creating and assigning buildings in the RPM
Physical buildings are not defined in the SDU. Since partitions and devices can only be
assigned to buildings, you must create buildings and assign them to companies using the
RPM.
To create a building:
1. On the Buildings menu, select Create.
2. In the Create Buildings dialog box, enter the Building Name and Description.
3. Click OK to save the information and open the Building Selection dialog box.
4. In the Building Selection dialog box, you can click:
Edit to revise the building name
New to create another building
OK to assign any buildings you selected from the list to the current company
Close to close the dialog with no further action
To assign buildings to a company:
1. Select a company.
2. On the Buildings menu, select Assign to open the Building Selection dialog box.
Only buildings not yet assigned to the company appear in the list.
3. Select the buildings you want to assign to the company.
You can make use of the Select All and Clear All buttons.
4. Click OK to assign the buildings and close the Select Building dialog box.

To remove a building from a company:

1. Select the building. (You may need to expand the company to see the assigned
buildings.)
2. On the Buildings menu, select Remove.
Assigning partitions and devices in the RPM

Content
Introduction
Assigning partitions
Assigning card reader controllers
Assigning Keypad Displays
Removing assigned partitions or devices
Introduction
Once you have created buildings and assigned them to companies, you can then assign
partitions and devices to the buildings. The Allocations menu has commands that let you
assign:
Partitions
Card reader controllers
Keypad displays
You can assign an outgoing MODCOM account to a company in the SDU. When a company
has an assigned outgoing MODCOM account, the MODCOM and account are assigned to
the company automatically by the RPM.
Back to top
Assigning partitions
When you select a building, then choose Allocations, then click Assign Partition, the RPM
displays a list of partitions defined for the project. You can assign any partition or group of
partitions to a building as required for the company.
When you assign a partition, the RPM automatically assigns all devices that belong to the
partition. These appear below the partition in the tree structure.
A CRC belongs to the partition you assign when you configure the CRC in the SDU. A
KPDISP belongs to its primary partition and to all partitions in the partition route you assign
when you configure the KPDISP in the SDU.
Back to top

To assign partitions to a building:

1. Select the building.
2. Choose Allocations, then click Assign Partition to open the Partition Selection dialog
box.
3. Select the partitions you want to assign.
4. Click OK to assign the partitions and close the selection dialog box.
Back to top
Assigning card reader controllers
When you select a building, then select Assign Card Reader Controller On the Allocations
menu, the RPM displays a list of CRC devices that are not assigned to a partition. CRCs in
a partition can only be assigned by assigning that partition.

To assign a card reader controller to a building:

1. Select the building.
2. On the Allocations menu, select Assign Card Reader Controller to open the CRC or
CRCMS Selection dialog box.
3. Select the card reader controller you want to assign.
4. Click OK to assign the card reader controller and close the selection dialog box.
Back to top
Assigning Keypad Displays
When you select a building, then On the Allocations menu, select Assign Keypad Display,
the RPM displays a list of all KPDISP devices in the project. You can assign any KPDISP or
group of KPDISPs to a building.
You can control which companies are allowed to execute the following critical fire alarm
system commands:
Disable device
Reset panel
Alarm silence
Panel silence
The RPM lets you set these Keypad Display privileges when you assign the device to a
building.
Back to top
To assign a Keypad Display to a building:
1. Select the building.
2. On the Allocations menu, select Assign Keypad Display to open the Keypad Display
Selection dialog box.
3. Select the Keypad Display you want to assign.
4. Click OK to assign the Keypad Display and close the selection dialog box.
The RPM opens a Set Keypad Display Privileges dialog for each Keypad Display
device you selected.
5. Check the privileges you want to make available to the company using the ACDB or
KDC programs.
Back to top
Removing assigned partitions or devices
If you assign a partition or device in error, simply remove that partition or device from the
building.
To remove partitions or devices from a building:
1. Select the partition or device.
2. On the Allocations menu, select Remove Partition, then click Remove Card Reader
Controller, or Remove Keypad Display.
— or —
Choose Remove On the shortcut menu (right-click menu) for the partition or device.
Note: Individual devices cannot be removed from partitions using the RPM.
Back to top
Allocating device resources in the RPM
Certain features of CRC operation, such as unlock schedules and door timers, can have
only one value. These features should be set by the company that owns the CRC or is the
primary user of the CRC. You must specify which company will be the primary company for
each CRC.
When two or more companies share a device, you must divide the device's storage
capacity among the companies. For example, if two companies share a front door CRC, it
might be reasonable to allocate half the cardholders, schedules, holidays, and access levels
to each company.
You use the RPM to accomplish both these tasks.
Setting the primary company
To specify the primary company for a CRC, right-click the CRC and choose Primary
Company. This command toggles on and off (the Primary check mark appears or
disappears each time you choose it).
Alternately, you can click the Primary check box in the data table pane of the RPM window
for the company you want to set as primary. Again, clicking toggles the check box between
checked and clear.
Only one company can be the primary company for the CRC. Checking Primary for the
CRC under one company clears any other settings for primary company.
Setting resource values
You can use the detail pane of the RPM window to manually set the allocation values for
each company. Or, you can use the Mass Assign function to create and globally apply a
template of assignments. You can also start with the Mass Assign function, then manually
adjust the resource values.
You can lock a value to prevent the Mass Assign function from changing it. To lock a value,
click the User Set check box to check it. Whenever you manually adjust a value, the RPM
checks the User Set check box. You can click the check box to clear it, and allow the Mass
Assign function to overwrite the value again.
Exporting resource profiles in the RPM
You need to export an individual resource profile for each company in the project. The
resource profile can then be imported into the company's ACDB or KDC program.
An exported profile file is saved in compressed (ZIP) format, and can be imported directly
into the ACDB or KDC. We suggest that you export each company resource profile to an
external media storage device.
You can specify the path and file name the RPM uses to create the profile. You can write
the profile directly to an external media storage device, or to your hard drive for later copy
to a storage device.
You can export a single profile or multiple profiles in one session. When you export multiple
profiles, they are created one after another, allowing you to specify a different path or file
name for each profile.

To export a single resource profile:

1. Select the company.
2. On the Companies menu, click Export Selected Company.
3. Use the Select File Destination dialog to set the drive, path, and file name as
required.
4. Click Save to begin the export.
To export all resource profiles:
1. Choose Companies > Export All Companies.
2. Use the Select File Destination dialog to set the drive, path, and file name as
required.
3. Click Save to begin the export.
4. Repeat steps 2 and 3 as the RPM cycles through each company.
Tip: You can also choose List Companies Updated But Not Exported to open the Select
Companies to Export dialog box. You can use this box to choose one or more companies
for profile export. Only those companies you've changed since the last export appear in
this list.
RPM mass assign function
The Mass Assign function of the RPM helps you allocate device resources. It lets you
create a template for automatic division of the resources between all companies in the
project. You can use absolute values or percentages to create the template.
When you select Allocations, then click Mass Assign, the RPM opens the Mass Assign
dialog box. This table includes all the companies in the project. For each company, the table
has a row for each device type, and columns for the number of cardholders, schedules,
holidays, and access levels allocated to each type of device.
Initially, the Mass Assign function is set to distribute 80% of all device resources evenly
across all companies. Each company gets an equal share of each device resource, with
20% held in reserve for future expansion.
You can adjust these figures to suit your actual project situation. You can divide the
resources among the companies according to the actual number of cardholders, or
according to percentages you determine.
When the template is adjusted to your satisfaction, click Apply to apply these settings to the
devices. The RPM will warn you if any devices have been over-allocated.
RPM Summary report
The Summary report is a flexible, report-style view of the overall project resource profile. To
open the Summary view, choose Allocations, then click Summary.
The Summary view is a table of the data in the project resource profile. It contains these
columns:
Company
Building
Partition
Type (device type)
Device (device label)
Cardholders
Holidays
Schedules
Access levels
You can sort the table by any of these columns by clicking the column heading. For
example, to sort the table by buildings, click the Building heading. To reverse the sort order,
click the heading again.
You can arrange the columns in any order from left to right, by simply dragging the column
heading to the desired position. Green arrows indicate the insertion position for the column
you are dragging.
You can group the table by any of the columns, by dragging the column heading into the
area above the column title row. You can perform multiple grouping operations by dragging
a second or third column heading into the same area.
Once the report is in the format you want, click Print to open a Print Preview window that
shows printed report. From the Print Preview window you can review the report, change
your printer setup, print the report, or save the report.
Creating a rules file
The SDU provides a Rules Editor for writing rules. The Rules Editor is limited to editing files
of 32 kilobytes or less. If your rules file exceeds this limit, use a third party text editor such
as Microsoft Notepad.
You can set a default text editor the Rules Editor option from the default editor to another
editing tool (Word, Wordpad, etc.). When you select Edit Rules from the Rules menu, the
SDU will automatically run the third-party editor and load the project rules file.
Note: When using a third-party editor, always save your file before exiting the editor. It is
also a good practice to save your file before compiling and before saving the project.
Tip: Always look for instances where advanced programming techniques can be used to
reduce the size of the rule file.
Rule syntax
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 must be enclosed in brackets. The
rule label can be any ASCII character except:
braces "{ }"
brackets "[ ]" used inside of the rule label (i.e., [Rule[1]_label] is not valid)
the percent symbol "%"
the number symbol "#"
less than and greater than symbols "< >"
asterisks "*"
A rule can 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,
the operations performed by the rule will automatically restore in the reverse order (from
last to first).
Comments can be placed anywhere in the rule and must be enclosed in braces.
Note: Object labels must be enclosed with straight single quotes or the rules file won't
compile. Use the Apostrophe key, not the opening single quote found under the tilde (~)
character on the keyboard next to the number 1 key.
Tips
Add comments to your rules where they can be easily seen. The rules compiler
ignores any characters between opening and closing braces.
Place comments on separate lines and indent them. The rules compiler ignores tabs,
spaces, and line breaks.
Compiling the rules file
The rules file must be compiled before the project database can be converted and
downloaded to the panel. First, the compiler checks for errors in the object configuration
table such as unlabeled objects and duplicate labels. Second, the compiler checks that the
rules file doesn't contain syntax errors, that objects in the rules file match objects in the
object configuration table, and that all alarm input devices are associated with an output.
Note: Compiler errors must be corrected before DB conversion. Warnings don't have to be,
but it is better if you do.
To compile the rules file:
1. Close the Rules Editor
2. On the Rules menu, click Compile.
3. Correct any errors.
Exporting the rules file
SDU rules editor provides an export utility for transferring the rules file to another computer.
The export utility places a copy of the rules file onto a destination drive of your choosing.
The destination drive can be some location on a network or the floppy disk.
To export the rules file:
1. On the Rules menu, select Edit Rules.
2. On the rules editor toolbar, click the Export button.
3. On the rules file dialog box, select the destination drive.
4. Locate the folder in which to place the file.
5. Click OK.
Finding and replacing text in the rules file
To make it easier to edit the rules file, the rules editor includes a find and replace function
which is accessible from the toolbar.
To find text in the rules file:
1. From the Rules menu, select Edit Rules.
2. On the rules editor toolbar, click Find.
3. In the Find what: text box, type the text you want to locate.
4. Select the matching criterion and the search direction.
5. Click Find Next.
To find and replace text in the rules file:
1. From the Rules menu, select Edit Rules.
2. On the rules editor toolbar, click Replace.
3. In the Find what: text box, type the text you want to locate.
4. In the Replace with: text box type the text you want to replace the located text with.
5. Select the matching criteria.
6. Click Find Next.
Importing a rules file
SDU rules editor provides a utility to import a rules file from another computer. The import
utility retrieves the rules file from a source drive of your choosing. The source drive can be
some location on a network or the floppy disk.
To import text into the rules file:
1. From the Rules menu, select Edit Rules.
2. On the rules editor toolbar, click the Import button.
3. On the rules file dialog box, select the source drive.
4. Open the folder from which to import the file and select the file.
5. Click OK.
A confirmation box is displayed to verify if you want the existing file overwritten. If you click
Yes, the file will be overwritten. If you click No, the imported file is attached at the end of
the existing file.
Printing the rules file
The Print dialog contains the following options:
Setup: Click the Setup command to select from a list of available printers, paper
orientations, and paper sizes.
Print Range: This option is always set to print the entire rules file.
Print Quality: Select the desired print quality. This option depends on the printer connected
to SDU computer.
Copies: Select the number of copies you want printed.
To print the rules file:
1. Open the rules editor and click the Print button.
2. Make any adjustments required to the printer setup.
3. Click OK.
Rule editor toolbar functions
The Rules Editor window provides a toolbar containing the following function buttons:
OK: Press this button to close the rules editor and save any changes you made to the rules
file.
Cancel: Press this button to close the rules editor and disregard any changes you made to
the rules file.
Cut: Press this button to remove the selected text from the rules file and place it into the
Windows clipboard. The cut text replaces any previous text already in the clipboard.
Copy: Press this button to copy the selected text from the rules file and place it into the
Windows clipboard.
Paste: Press this button to paste copied or cut text from the Windows clipboard into the
rules file.
Find: Press this button to search the rules file for a specific word or text.
Replace: Press this button to search for a specific word or text in the rules file and
automatically replace it with another.
Import: Press this button to import a rules file written using a third-party ASCII text editor.
You are given the option of appending the imported file to the existing text or replacing the
entire file.
Export: Press this button to export your rules file to another location (removable storage
device or hard disk.) The exported file can then be imported into another SDU or edited
using a separate ASCII text editor.
Fonts: Press this button to change the font size and typeface of the text displayed in the
text window of the editor.
Print: Press this button to print the rules file.
Writing a rule
A rule contains an input (event) statement terminated with a colon and an output (command)
statement terminated 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.

To write a rule:
1. On the Rules menu, select Edit Rules.
2. In the text window, position the mouse pointer where you want to insert the rule.
3. Enter a rule label using the following format: [rule_label].
4. Enter the input (event) statement.
5. Enter the output (command) statements.
6. Click OK.
See also
Rule syntax
12SW/12LED device type

Description
The SDU assigns the 12SW/12LED device type to control-display modules that have 12
switches and 12 indicator lights.
Short form: 12S12L
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
12SW/24LED device type

Description
The SDU assigns the 12SW/24LED device type to control-display modules that have 12
switches and 24 light-emitting diodes.
Short form: 12S24L
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
2StageSignal device type

Description
Assign the 2StageSignal device type to Edwards Analog sounders that sound alert and
evacuation signals.
Short form: 2SSIG
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
SignalAlert
SignalEvacuate
SignalOff
24LED device type

Description
The SDU assigns the 24LED device type to control-display modules that have only 24 light-
emitting diodes.
Short form: 24L
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
24VRiser device type

Description
Assign the 24VRiser device type to a circuit that monitors the integrity of a 24 Vdc riser. A
24 Vdc riser monitor circuit reports a trouble condition when the riser voltage falls below
approximately 50%.
Short form: 24V
Input events
This device type can initiate the following input events:
Acknowledge
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
none
3-AADC device type

Description
The SDU assigns the 3-AADC device type to 3-AADC Addressable Analog Driver Controller
module.
Short form: AADC
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-AADC1 device type

Description
The SDU assigns the 3-AADC1 device type to the 3-AADC1 Addressable Analog Driver
Controller module. The 3-AADC1 contains extended memory for improved performance and
is fully backward compatible.
Short form: AADC1
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-ANNSM device type

Description
The SDU assigns the 3-ANNSM device type to 3-ANNSM Annunciator Support modules.
No events or commands are associated with this device type; however, each 3-ANNSM
module has several pseudo points of the LocalTrouble device type. You can create rules
using these pseudo points.
Short form: ANNSM
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
3-ASU device type

Description
The SDU assigns the 3-ASU device type to 3-ASU Audio Source Unit modules.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
Short form: ASU
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-CPU device type

Description
When you add a cabinet to a project, the SDU assigns a device type of 3-CPU1 to the
central processor module for the panel. You can switch this to 3-CPU if you are using the
earlier model of central processor.
The SDU treats both device types the same. The 3-CPU device type simply lets you identify
these modules.
There are no input events or output commands associated with a 3-CPU device. Each has
several LocalTrouble pseudo points for which you can write rules.
Short form: CPU
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
3-CPU1 device type

Description
When you add a cabinet to a project, the SDU assigns a device type of 3-CPU1 to the
central processor module for the panel.
Note: You can switch this to 3-CPU if you are using the earlier model of central processor.
The SDU treats both device types the same.
There are no input events or output commands associated with a 3-CPU1 device. Each has
several LocalTrouble pseudo points for which you can write rules.
Short form: CPU1
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
3-DSDC device type

Description
The SDU assigns the 3-DSDC device type to Signature controller modules.
Short form: DSDC
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-DSDC1 device type

Description
The SDU assigns the 3-DSDC1 device type to Signature controller modules. The 3-DSDC1
contains extended memory for improved performance and is fully backward compatible.
Short form: DSDC1
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-EADC device type

Description
The SDU assigns the 3-EADC device type to Edwards Analog controller modules that have
two analog loops installed.
Short form: EADC
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Calibrate
Disable
Enable
3-EASC device type

Description
The SDU assigns the 3-EASC device type to Edwards Analog controller modules that have
only one analog loop installed. If a second analog loop is added to a 3-EASC then you must
change the rail module to the 3-EADC device type in the SDU.
Short form: EASC
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Calibrate
Disable
Enable
3-EVDVR device type

Description
The SDU assigns the 3-EVDVR device type to Envoy Driver modules (LED/Switch Driver
module).
There are no input events or output commands associated with 3-EVDVR devices.
However, they have LocalTrouble pseudo-points for which you can write rules.
Short form: EVDVR
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
3-FTCU device type

Description
The SDU assigns the 3-FTCU device type to 3-FTCU Firefighter's Telephone Control Unit
modules.
Short form: FTCU
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-IDC8/4 device type

Description
The SDU assigns the 3-IDC8/4 device type to 3-IDC8/4 Initiating Device Circuit modules.
Short form: IDC
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-LCD device type

Description
When you add a non-CAB6 cabinet to a project, the SDU assigns a device type of 3-LCD to
the Main LCD Display module on the operator layer of the 3-CPU1 module.
There are no input events, output commands, or pseudo points associated with a 3-LCD.
You can write rules for the Annunciator_Supervision_xx_xx LocalTrouble pseudo point of the
3-CPU1 module.
Short form: LCD
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
3-LDSM device type

Description
The SDU assigns the 3-LDSM device type to 3-LDSM LED Display Support modules.
There are no input events or output commands associated with 3-LDSM devices. However,
they have LocalTrouble pseudo points for which you can write rules.
Short form: LDSM
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
3-MODCOM device type

Description
The SDU assigns the 3-MODCOM device type to 3-MODCOM and 3-MODCOMP Modem
Communicator modules.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-OPS device type

Description
The SDU assigns the 3-OPS device type to 3-OPS Off-Premises Signaling modules.
Short form: OPS
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-PS/M device type

Description
When you add a cabinet to a project, the SDU assigns a device type of 3-PS/M to the
Primary Power Supply and Monitor module.
There are no input events or output commands associated with a 3-PS/M device. Each has
several LocalTrouble pseudo points for which you can write rules.
Short form: PS/M
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
3-SAC device type

Description
The SDU assigns the 3-SAC device type to 3-SAC Security Access Control modules.
There are no input events or output commands associated with a 3-SAC device. Each has
several LocalTrouble pseudo points for which you can write rules.
Short form: SAC
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
3-SDDC device type

Description
The SDU assigns the 3-SDDC device type to Signature controller modules that have two
Signature loops installed.
Note: The 3-DSDC device type is used instead of the 3-SSDC device type in limited
versions of the SDU.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-SDDC1 device type

Description
The SDU assigns the 3-SDDC1 device type to Signature controller modules that have two
Signature loops installed. The 3-SDDC1 contains extended memory for improved
performance and is fully backward compatible.
Note: The 3-DSDC1 device type is used instead of the 3-SSDC1 device type in limited
versions of the SDU.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-SSDC device type

Description
The SDU assigns the 3-SSDC device type to Signature controller modules that have only
one Signature loop installed. If a second Signature loop is added to a 3-SSDC then you
must change the rail module to the 3-SDDC device type in the SDU.
Note: The 3-DSDC device type is used instead of the 3-SSDC device type in limited
versions of the SDU.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3-SSDC1 device type

Description
The SDU assigns the 3-SSDC1 device type to Signature controller modules that have only
one Signature loop installed. If a second Signature loop is added to a 3-SSDC1 then you
must change the rail module to the 3-SDDC1 device type in the SDU. The 3-SSDC1
contains extended memory for improved performance and is fully backward compatible.
Note: The 3-DSDC1 device type is used instead of the 3-SSDC1 device type in limited
versions of the SDU.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3SW/3LEDx6 device type

Description
The SDU assigns the 3SW/3LEDX6 device type to control-display modules that have 6
groups of 3 switches and 3 light-emitting diodes.
Short form: 3S3L6
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
3SW/4LEDx4 device type

Description
The SDU assigns the 3SW/4LEDx4 device type to control-display modules that have four
groups of three switches and four LED indicators.
Short form: 3S4L4
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
AccessDoorControl device type
Assign the AccessDoorControl device type to CRC output relays configured for access
door motor control applications.
AccessOutput device type

Description
When you add a CRC to a 3-SAC module, the SDU creates pseudo points for that CRC.
You can use several of these pseudo points in rules to monitor or control the CRC. The
SDU assigns the AccessOutput device type to the following pseudo points:
Inside_Reader_Disable
Outside_Reader_Disable
Relay_Open
Sounder
Task_Supervision_Fault
Unlock
Short form: ACOUT
Input events
This device type can initiate the following input events:
AccessTrouble
Disabled
RelayConfirmation
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
AccessTrouble device type

Description
When you add a CRC to a 3-SAC module, the SDU creates pseudo-points for that CRC.
You can use several of these pseudo points in rules to monitor or control the CRC. The
SDU assigns the AccessTrouble device type to the following pseudo points:
AC_Brownout_01_06_01
Low_Battery_01_06_01
Strike_Fault_01_06_01
Reader_Fault_01_06_01
RAM_Fault_or_Stack_Fault_01_06_01
Code_Supervision_01_06_01
Database_Supervision_01_06_01
Communication_Fault_01_06_01
Short form: ACCTRB
Input events
This device type can initiate the following input events:
AccessTrouble
Output commands
This device type can respond to the following output commands:
none
ACFail device type

Description
Assign the ACFail device type to objects that can detect AC power failure.
Short form: ACF
Input events
This device type can initiate the following input events:
ACFail
Acknowledge
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
Output commands
This device type can respond to the following output commands:
Active1Test
Disable
Enable
Off
On
TroubleTest
AlarmSilence device type

Description
The SDU assigns the AlarmSilence device type to a panel's AlarmSilence pseudo point. The
AlarmSilence pseudo point changes to the active state when:
An operator presses a momentary switch on the local panel that executes the
AlarmSilence command
An operator presses a momentary switch on a remote panel that executes the
AlarmSilence command, and the remote panel is part of the same network route as
the local panel
When the AlarmSilence pseudo point changes to the active state, the panel activates its
automatic Alarm Silence responses and any programmed output responses written for the
AlarmSilence event.
Short form: AS
Input events
This device type can initiate the following input events:
AlarmSilence
Output commands
This device type can respond to the following output commands:
AlarmSilence
AllCall device type

Description
The SDU assigns the AllCall device type to the AllCall event's pseudo point. The AllCall
event's pseudo point changes to the active state when an operator presses the All Call
switch on a 3-ASU.
The AllCall device type is only used to identify the AllCall event's pseudo point in the
database and is not used when writing a rule using the AllCall event.
Input events
This device type can initiate the following input events:
AllCall
Output commands
This device type can respond to the following output commands:
none
AllCallMinus device type

Description
The SDU assigns the AllCallMinus device type to the AllCallMinus event's pseudo point. The
AllCallMinus event's pseudo point changes to the active state when an operator presses the
All Call Minus switch on a 3-ASU.
The AllCallMinus device type is only used to identify the AllCallMinus event's pseudo point in
the database and is not used when writing a rule using the AllCallMinus event.
Input events
This device type can initiate the following input events:
AllCallMinus
Output commands
This device type can respond to the following output commands:
none
AlternateLanguage device type

Description
This device type is for system use only.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
AlternateMsg device type

Description
This device type is for system use only.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
AlternateSensitivity device type

Description
This device type is for system use only.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
AlternateSensitivityMode device type

Description
The SDU assigns the AlternateSensitivityMode device type to the system
AlternateSensitivityMode pseudo point (Alternate_Sensitivity_Mode_00_00) which changes
to the active state when:
An operator activates the Alt Sensitivity command On the LCD command menu
The output side of a rule activates the AlternateSensitivityOn command or the
RemoteAltSensitivityOn command
The output side of a rule activates the AlternateSensingOn command or the
RemoteAltSensingOn command
An operator presses a common control switch on the LCD that is configured to
execute the AlternateSensitivityOn or AlternateSensingOn command
Upon activation, the AlternateSensitivityMode pseudo point initiates the
AlternateSensitivityMode event.
Short form: ALTSMOD
Input events
This device type can initiate the following input events:
AlternateSensitivityMode
Output commands
This device type can respond to the following output commands:
AlternateSensitivityOn
RemoteAltSensitivityOn
AlternateSensingOn
RemoteAlternateSensingOn
Amp device type

Description
The SDU assigns the Amp device type to 3-ZAxx Zoned Amplifier modules.
Note: By default for the Singapore marketplace, any devices or zones configured with this
device type cannot be disabled. If you are using the Singapore marketplace but want to use
the Disable command with this device type, check the Allow Disables check box on the
Project Parameters - Operations tab.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
AmpOff
AmpOn
Disable
Enable
AND device type

Description
The SDU assigns the AND device type to AND groups.
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Monitor
Supervisory
Trouble
Output commands
This device type can respond to the following output commands:
Activate
Disable
Enable
Restore
Audible device type

Description
Assign the Audible device type to notification appliance circuits that produce a signal which
turns off when the user presses Alarm Silence.
Note: By default for the Singapore marketplace, any devices or zones configured with this
device type cannot be disabled. If you are using the Singapore marketplace but want to use
the Disable command with this device type, check the Allow Disables check box on the
Project Parameters - Operations tab.
Short form: AUD
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
TroubleTest
NACCO (for the PS/NAC module only)
AudioRiser device type

Description
Assign the AudioRiser device type to a circuit that monitors the integrity of a 70 VAC or 25
VAC audio riser. An audio riser monitor circuit reports a trouble condition when the riser
voltage falls below approximately 50%.
Short form: AUDRSR
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
none
AuxPowerSupply device type

Description
Assign the AuxPowerSupply device type to a SIGA-APS Auxiliary Power Supply. The
SIGA-APS uses two addresses. The SDU assigns each address the AuxPowerSupply
device type.
The first (lower) address changes to the active state when the SIGA-APS loses AC or
battery power.
The second (higher) address changes to the active state when the SIGA-APS detects an
open circuit or a ground fault on either of its 24 Vdc power outputs.
Short form: AUXPS
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
TroubleTest
C-CPU device type

Description
When you add a CAB6 cabinet to a project, the SDU assigns the C-CPU device type to the
SFS1-CPU central processor module for the panel.
There are no input events or output commands associated with a C-CPU device. Each has
several LocalTrouble pseudo points for which you can write rules.
Short form: none
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
C-LCDXL device type

Description
When you add a CAB6 cabinet to a project, the SDU assigns the C-LCDXL device type to
the 4X-LCD(-LC) Main LCD Display module.
There are no input events, output commands, or pseudo points associated with a C-LCDXL.
You can write rules for the Annunciator_Supervision_xx_xx LocalTrouble pseudo point of the
C-CPU module.
Short form: none
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
CardDBIncompat device type

Description
The SDU assigns the CardDBIncompat device type to a panel's Database Out of Sync with
CPU pseudo points. There are nineteen Database Out of Sync with CPU pseudo points on
a panel; one for each available card position.
A Database Out of Sync with CPU pseudo point changes to the active state when:
There is a conflict between the CPU module's database version and the Signature
loop controller's database version.
A Signature loop controller's actual and expected devices are not the same.
Short form: DBIN
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
none
CfgMismatch device type

Description
The SDU assigns the CfgMismatch device type to a panel's Configuration Mismatch pseudo
points. There are 19 Configuration Mismatch pseudo points on a panel; one for each
available card position.
A Configuration Mismatch pseudo point changes to the active state when the rail module in
the corresponding card position does not support the extended configuration options
selected in the SDU (for example, Standalone Mode operation).
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
none
Channel device type

Description
This device type is for system use only.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
City_Tie device type
Use the City_Tie device type when assigning a city tie module to a NAC circuit on the
PS/NAC card, and you want to output an unsynchronized 24 VDC signal that does not turn
off when an operator presses Alarm Silence.
You can control the city tie module by controlling the NAC circuit feeding it. City_Tie requires
that you write a rule to:
activate the associated NAC circuit during an alarm
activate the associated NAC circuit during a drill
disable the associated NAC circuit to disable the module
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
CmdList device type

Description
SDU assigns the CmdList device type to the command list objects you create.
Short form: CMDLIST
Input events
This device type can initiate the following input events:
Activation
Output commands
This device type can respond to the following output commands:
Activate
Disable
Enable
Restore
CMSFirstTrouble device type

Description
SDU assigns the CMSFirstTrouble device type to a project's CMSFirstTrouble pseudo point.
The CMSFirstTrouble pseudo point changes to the active state the first time that any point
in the project changes to the trouble state, with two exceptions: 3-MODCOM accounts, and
AC Brownout pseudo points. (See the CMSFirstTrouble event for details.)
Short form: CMSFT
Input events
This device type can initiate the following input events:
CMSFirstTrouble
Output commands
This device type can respond to the following output commands:
none
CMSNonsupervisedOutput device type

Description
Assign the CMSNonsupervisedOutput device type to nonsupervised, dry contact output
circuits. Nonsupervised output circuits do not monitor their output for open or shorted
wiring.
Note: This device type is available for the Singapore marketplace, and by default any
devices or zones configured with this device type cannot be disabled using rules or the front
panel (and the system does not contact the Central Monitoring Station).
If you are using the Singapore marketplace but want to use the Disable command with this
device type, check the Allow Disables check box on the Project Parameters - Operations
tab. This option allows you to write a rule to disable this device type; it still cannot be
disabled from the front panel.
If you are not using the Singapore marketplace, instead use the NonsupervisedOutput
device type.
Short form: CMSNSO
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
TroubleTest
CMSSupervisedOutput device type

Description
Assign the CMSSupervisedOutput device type to notification appliance signaling circuits that
monitor their supervised output.
Note: This device type is available for the Singapore marketplace, and by default any
devices or zones configured with this device type cannot be disabled using rules or the front
panel (and the system does not contact the Central Monitoring Station).
If you are using the Singapore marketplace but do want to use the Disable command with
this device type, check the Allow Disables check box on the Project Parameters -
Operations tab. This option allows you to write a rule to disable this device type; it still
cannot be disabled from the front panel.
If you are not using the Singapore marketplace, instead use the SupervisedOutput device
type.
Short form: CMSSUP
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
TroubleTest
COAlarm device type

Description
Assign the COAlarm device type to stand-alone or combination CO detectors that you want
to trigger a COAlarm event when activated.
Note: The default CO setting for the SIGA2 CO detectors is COSupervisory. For more
information on SIGA2 devices, see Understanding SIGA2 devices.
Short form: COALM
Input events
This device type can initiate the following input events:
COAlarm
Disabled
DisabledActive
DisabledTrouble
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
AlarmTest
Disable
Enable
GasAcceleratedResponseOn
GasAcceleratedResponseOff
TroubleTest
COMonitor device type

Description
Assign the COMonitor device type to stand-alone or combination CO detectors that you
want to trigger a COMonitor event when activated.
Note: The default CO setting for the SIGA2 CO detectors is COSupervisory. For more
information on SIGA2 devices, see Understanding SIGA2 devices.
Short form: COMON
Input events
This device type can initiate the following input events:
COMonitor
Disabled
DisabledActive
DisabledTrouble
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
GasAcceleratedResponseOn
GasAcceleratedResponseOff
TroubleTest
COSupervisory device type

Description
Assign the COSupervisory device type to stand-alone or combination CO detectors that you
want to trigger a COSupervisory event when activated.
Note: The default CO setting for the SIGA2 CO detectors is COSupervisory. For more
information on SIGA2 devices, see Understanding SIGA2 devices.
Short form: COSUP
Input events
This device type can initiate the following input events:
COSupervisory
Disabled
DisabledActive
DisabledTrouble
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
GasAcceleratedResponseOn
GasAcceleratedResponseOff
TroubleTest
CommFailure device type

Description
SDU assigns the CommFailure device type to the pseudo point that the system changes to
the active state when a panel loses communication with the other panels on the network.
Short form: CFAIL
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
none
CommonAlarmOutput device type

Description
Assign the CommonAlarmOutput device type to a supervised output circuit that requires
automatic activation when any alarm event occurs. The system restores the output when an
operator presses Alarm Silence.
You do not have to write a rule to activate a CommonAlarmOutput device.
Note: By default for the Singapore marketplace, any devices or zones configured with this
device type cannot be disabled. If you are using the Singapore marketplace but want to use
the Disable command with this device type, check the Allow Disables check box on the
Project Parameters - Operations tab.
Short form: CAO
Input events
This device type can initiate the following input events:
Acknowledge
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
CommonAlarmOff
CommonAlarmOn
Disable
Enable
Off
On
TroubleTest
NACCO (for the PS/NAC module only)
CommonMonitorOutput device type

Description
Assign the CommonMonitorOutput device type to a supervised output circuit that requires
automatic activation when any monitor event occurs.
You do not have to write a rule to activate a CommonMonitorOutput device.
Short form: CMO
Input events
This device type can initiate the following input events:
Acknowledge
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
CommonMonitorOff
CommonMonitorOn
Disable
Enable
Off
On
TroubleTest
CommonSupervisoryOutput device type

Description
Assign the CommonSupervisoryOutput device type to a supervised output circuit that
requires automatic activation when any supervisory event occurs.
You do not have to write a rule to activate a CommonSupervisoryOutput device.
Short form: CSO
Input events
This device type can initiate the following input events:
Acknowledge
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
CommonSupervisoryOff
CommonSupervisoryOn
Disable
Enable
Off
On
TroubleTest
Control_Center_ALO device type

Description
When you configure a control panel as a display control center, the SDU assigns the
Control_Center_ALO access level override device type to the control center and generates
a Ctrl Center Enabled pseudo point. When active, the command overrides the access levels
on the control center.
Short form: ALO
Input events
This device type can initiate the following input events:
LocalMonitor
Output commands
This device type can respond to the following output commands:
Off
On
ControlledAuxOutput device type

Description
Assign the ControlledAuxOutput (Controlled Auxiliary Output) device type to a NAC circuit
that provides auxiliary power, and is on all the time. You must write a rule to activate the
ControlledAuxOutput device type; typically this is a start-up rule.
Short form: CAUX
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
CRC device type

Description
Assign the CRC device type when adding a CRC or CRCXM Card Reader Controller to a 3-
SAC module.
No events or commands are associated with this device type; however, each CRC has
several pseudo points for which you can create rules.
Short form: CRC
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
DamperControl device type

Description
Assign the DamperControl device type to an output circuit that connects to a control
mechanism used for operating a damper. The output circuit can be either supervised or
nonsupervised, depending on the type and placement of the module used for the circuit.
Short form: DAMP
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Close
Disable
Enable
NCClose
NCOpen
Off
On
Open
TroubleTest
DamperFeedback device type

Description
Assign the DamperFeedback device type to non-latching input circuits that monitor the
operation of damper control circuits.
Short form: DAMPFB
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
Monitor
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
DoorControl device type

Description
Assign the DoorControl device type to an output circuit that connects to a control
mechanism used for holding doors in a fixed position. The output circuit can be either
supervised or nonsupervised depending on the type and placement of the module used for
the circuit.
Short form: DOOR
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
HoldDoor
NCHoldDoor
NCReleaseDoor
Off
On
ReleaseDoor
TroubleTest
DoorFeedback device type

Description
Assign the DoorFeedback device type to non-latching input circuits that monitor the
operation of door control circuits.
Short form: DOORFB
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
Monitor
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
Drill device type

Description
SDU assigns the Drill device type to a panel's Drill pseudo point (Drill_Response_00_00).
The Drill pseudo point changes to the active state when:
An operator presses the Drill switch on the local panel
An operator presses the Drill switch on a remote panel that is a member of the
network route designated by the local panel's State option setting. See Setting
network routing properties for common controls.
An operator presses a control-display module switch programmed to execute the
Drill command and the local panel is a member of the network route specified by the
command's routing parameter.
The panel receives a Drill command from equipment connected to a gateway port
When the Drill pseudo point changes to the active state, the panel activates its automatic
Drill responses and any programmed output responses written for the Drill event.
Input events
This device type can initiate the following input events:
Drill event
Output commands
This device type can respond to the following output commands:
Drill command
EMailAccount device type
The SDU assigns the EMailAccount device type to accounts that you create when
configuring an Email Account for an Email Service type.
Input events
This device type can initiate the following input events:
Disable
DisabledTrouble
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
SendEmail
Ethernet_Card device type
The SDU assigns the Ethernet_Card device type to the Ethernet card.

Input events
This device type can initiate the following input events:
N/A
Output commands
This device type can respond to the following output commands:
Disable
Enable
Evacuation device type

Description
SDU assigns the Evacuation device type to a panel's Evacuation pseudo point. The
Evacuation pseudo point changes to the active state when:
An operator presses a momentary switch on the local panel that executes the
Evacuation command
An operator presses a momentary switch on a remote panel that executes the
Evacuation command and the remote panel is part of the same network route as the
local panel
When the Evacuation pseudo point changes to the active state, the panel activates its
automatic Evacuation responses and any programmed output responses written for the
Evacuation event.
Short form: EVAC
Input events
This device type can initiate the following input events:
Evacuation
Output commands
This device type can respond to the following output commands:
Evacuation
ExtDBIncompatibility device type

Description
SDU assigns the ExtDBIncompatibility device type to a panel's ExtDBIncompatibility pseudo
point. The ExtDBIncompatibility pseudo point changes to the active state when a CPU
module's database is not at the same revision level as other CPU modules on the network.
Short form: EXTDBIN
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
none
Failsafe device type

Description
SDU assigns the Failsafe device type to a panel's Failsafe pseudo point. The Failsafe
pseudo point changes to the active state when the panel's Alarm Present signal line
becomes active.
An active Failsafe pseudo point places the panel into alarm or trouble depending on whether
the CPU module can communicate with the other rail modules.
The panel goes into trouble when the Failsafe pseudo point changes to the active
state and the panel can communicate with the other rail modules.
The panel goes into alarm when the Failsafe pseudo point changes to the active
state and the panel cannot communicate with the other rail modules.
Short form: FSAFE
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Trouble
Output commands
This device type can respond to the following output commands:
none
FanControl device type

Description
Assign the FanControl device type to an output circuit that connects to a control mechanism
used for operating a fan. The output circuit can be either supervised or nonsupervised
depending on the type and placement of the module used for the circuit.
Short form: FAN
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
FanOff
FanOn
NCFanOff
NCFanOn
Off
On
TroubleTest
FanFeedback device type

Description
Assign the FanFeedback device type to non-latching input circuits that monitor the operation
of fan control circuits.
Short form: FANFB
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
Monitor
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
Firephone device type

Description
Assign the Firephone device type to supervised signal input circuits used to select telephone
risers.
Short form: FP
Input events
This device type can initiate the following input events:
Acknowledge
CallIn
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
FirstAlarm device type

Description
The SDU assigns the FirstAlarm device type to a panel's FirstAlarm pseudo point. The
FirstAlarm pseudo point changes to the active state:
The first time that any point on the local panel changes to the alarm state.
The first time that any point on a remote panel that is part of the same network
route as the local panel changes to the alarm state.
When the FirstAlarm pseudo point changes to the active state, the panel automatically
activates its common alarm devices.
Input events
This device type can initiate the following input events:
FirstAlarm
Output commands
This device type can respond to the following output commands:
none
FirstDisable device type

Description
The SDU assigns the FirstDisable device type to a panel's FirstDisable pseudo point. The
FirstDisable pseudo point changes to the active state when:
The first time that any point on the local panel changes to the disable state.
The first time that any point on a remote panel that is part of the same network
route as the local panel changes to the disable state.
Input events
This device type can initiate the following input events:
FirstDisable
Output commands
This device type can respond to the following output commands:
none
FirstMonitor device type

Description
The SDU assigns the FirstMonitor device type to a panel's FirstMonitor pseudo point. The
FirstMonitor pseudo point changes to the active state when:
The first time that any point on the local panel changes to the monitor state.
The first time that any point on a remote panel that is part of the same network
route as the local panel changes to the monitor state.
When the FirstMonitor pseudo point changes to the active state, the panel automatically
activates its common monitor devices.
Input events
This device type can initiate the following input events:
FirstMonitor
Output commands
This device type can respond to the following output commands:
none
FirstSupervisory device type

Description
The SDU assigns the FirstSupervisory device type to a panel's FirstSupervisory pseudo
point. The FirstSupervisory pseudo point changes to the active state when:
The first time that any point on the local panel changes to the supervisory state.
The first time that any point on a remote panel that is part of the same network
route as the local panel changes to the supervisory state.
When the FirstSupervisory pseudo point changes to the active state, the panel automatically
activates its common supervisory devices.
Input events
This device type can initiate the following input events:
FirstSupervisory
Output commands
This device type can respond to the following output commands:
none
FirstTrouble device type

Description
The SDU assigns the FirstTrouble device type to a panel's FirstTrouble pseudo point. The
FirstTrouble pseudo point changes to the active state when:
The first time that any point on the local panel changes to the trouble state.
The first time that any point on a remote panel that is part of the same network
route as the local panel changes to the trouble state.
When the FirstTrouble pseudo point changes to the active state, the panel automatically
activates its common trouble devices.
Input events
This device type can initiate the following input events:
FirstTrouble
Output commands
This device type can respond to the following output commands:
none
GAInhibit device type

Description
This device type is for system use only.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
Gatevalve device type

Description
Assign the Gatevalve device type to active-latching input circuits that supervise gate valves
to determine when the valves are not fully open.
Short form: GATE
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
SprinklerSupervisory
Supervisory
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
GenAlarm device type

Description
Assign the GenAlarm device type to alarm input circuits that connect to the following:
normally-open dry contact initiating devices
non-retarded waterflow alarm switches
devices used in applications that require soft-short detection (the device
differentiates between shorted wires and alarm conditions).
Short form: GENA
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Disabled
DisabledActive
DisabledTrouble
MaintenanceAlert
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
G_Audible device type

Description
Use the G_Audible device type if you want a CAB6 panel NAC to output a synchronized
signal that turns off when the user presses Alarm Silence. Use this device type with
Genesis temporal horns.
Note: By default for the Singapore marketplace, any devices or zones configured with this
device type cannot be disabled. If you are using the Singapore marketplace but want to use
the Disable command with this device type, check the Allow Disables check box on the
Project Parameters - Operations tab.
Short form: GAUD
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
G_AudibleVisible device type

Description
Use the G_AudibleVisible device type if you want a CAB6 NAC to output a synchronized
signal that turns off when the user presses Alarm Silence. Use this device type with
Genesis temporal horn-strobes.
Note: By default for the Singapore marketplace, any devices or zones configured with this
device type cannot be disabled. If you are using the Singapore marketplace but want to use
the Disable command with this device type, check the Allow Disables check box on the
Project Parameters - Operations tab. (The Allow Disables check box appears only for the
Singapore marketplace.)
Short form: GAV
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
G_CommonAlarmOutput device type

Description
Use the G_CommonAlarmOutput device type for Genesis devices when you want a CAB6
NAC to output a synchronized signal automatically on any alarm event that turns off when an
operator presses Alarm Silence.
Note: By default for the Singapore marketplace, any devices or zones configured with this
device type cannot be disabled. If you are using the Singapore marketplace but want to use
the Disable command with this device type, check the Allow Disables check box on the
Project Parameters - Operations tab.
Short form: GCAO
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
G_CommonMonitorOutput device type

Description
Use the G_CommonMonitorOutput device type for Genesis devices when you want a CAB6
NAC to output a synchronized signal automatically on any monitor event.
You do not have to write a rule to activate a G_CommonMonitorOutput device.
Short form: GCMO
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
G_CommonSupervisoryOutput device type

Description
Use the G_CommonSupervisoryOutput device type for Genesis devices when you want a
CAB6 NAC to output a synchronized signal automatically on any supervisory event.
You do not have to write a rule to activate a G_CommonSupervisoryOutput device.
Short form: GCSO
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
G_Visible device type

Description
Use the G_Visible device type if you want a 3X panel NAC to output a synchronized signal
that turns off when the user presses Alarm Silence. Use this device type with Genesis
temporal strobes.
Note: By default for the Singapore marketplace, any devices or zones configured with this
device type cannot be disabled. If you are using the Singapore marketplace but want to use
the Disable command with this device type, check the Allow Disables check box on the
Project Parameters - Operations tab.
Short form: GVIS
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
GenSmoke device type

Description
Use the GenSmoke device type only in rules to substitute for Smoke and SmokeVfy device
types.
Short form: GENS
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
AlarmVerify
Disabled
DisabledActive
DisabledTrouble
MaintenanceAlert
PreAlarm
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
GroundFault device type

Description
The SDU assigns the GroundFault device type to the GroundFault pseudo point on CPU
modules and loop controller modules. The GroundFault pseudo point changes to the active
state when the rail module detects a ground fault.
Short form: GNDF
Input events
This device type can initiate the following input events:
Acknowledge
GroundFault
Output commands
This device type can respond to the following output commands:
none
Guard device type

Description
Assign the Guard device type to normally-open, non-latching input circuits that are used to
connect to patrol stations in guard patrol applications.
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
StationActivation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
GuardPatrol device type

Description
The SDU assigns the GuardPatrol device type to Guard Patrol Groups.
Short form: GPG
Input events
This device type can initiate the following input events:
Acknowledge
GuardPatrol
ObjectRunning
Output commands
This device type can respond to the following output commands:
Disable
Enable
OffGuard
OnGuard
Heat device type

Description
Assign the Heat device type to an initiating device or circuit that changes to the alarm state
when there is enough heat in the protected area to indicate the presence of a fire.
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
COAlarm
COMonitor
COSupervisory
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
SignalEvacuate
SignalOff
Active1Test
AlarmTest
TroubleTest
Interlock device type

Description
Note: The interlock feature is available only for the China (Local and Prop) marketplaces.
Assign the Interlock device type to controlled equipment, such as damper actuators and fan
on/off controls, whose activation and operation you want to monitor. When the interlock
device activates, the system tracks whether it operates correctly within a programmed
response time using an associated InterlockFeedback device type.
When the interlock device activates, if its associated InterlockFeedback device type
indicates that it failed to operate correctly within the programmed response time, then the
system generates an InterlockFailure event. You can write a rule that executes when this
event occurs, for example:

[General Interlock LED]

RelayConfirmation INTERLOCK :
Steady 'LED_GEN_INTLCK',
Steady 'LED_GEN_INTLCK_DELAY';
[Interlock Feedback LED]
{Interlock successful - Turn On Interlock Feedback}

Monitor INTERLOCKFEEDBACK :
Steady 'LED_GEN_INTLCK_FEEDBACK',
Off 'LED_GEN_INTLCK_DELAY';
[Interlock Failed LED]
{Interlock failed - Turn On Interlock Failure LED}

IntLckFail INTERLOCKFEEDBACK : Steady 'LED_GEN_FEEDBACK_FAIL';

Short form: INTLCK

Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
On
Off
TroubleTest
InterlockFeedback device type

Description
Note: The interlock feature is available only for the China (Local and Prop) marketplaces.
Associate the InterlockFeedback device type to an interlock device (such as damper
actuators and fan on/off controls) whose activation and operation you want to monitor.
When the interlock device activates, if its associated InterlockFeedback device type
indicates that it failed to operate correctly within the programmed response time, then the
system generates an InterlockFailure event. You can write a rule that executes when this
event occurs, for example:

[General Interlock LED]

RelayConfirmation INTERLOCK :
Steady 'LED_GEN_INTLCK',
Steady 'LED_GEN_INTLCK_DELAY';
[Interlock Feedback LED]
{Interlock successful - Turn On Interlock Feedback}

Monitor INTERLOCKFEEDBACK :
Steady 'LED_GEN_INTLCK_FEEDBACK',
Off 'LED_GEN_INTLCK_DELAY';
[Interlock Failed LED]
{Interlock failed - Turn On Interlock Failure LED}

IntLckFail INTERLOCKFEEDBACK : Steady 'LED_GEN_FEEDBACK_FAIL';

Short form: INTLCKFB

Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
InterlockFailure
Monitor
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Active1Test
Disable
Enable
On
Off
TroubleTest
IPAccount device type
The SDU assigns the IPAccount device type to accounts that you create when configuring a
Receiver Account for an IP Receiver Service type.
Input events
This device type can initiate the following input events:
Disabled
DisabledTrouble
Trouble
Output commands
This device type can respond to the following output commands:
Disarm
Enable
SendIP
Isolator device type

Description
The SDU assigns the Isolator device type to SIGA-IM Isolator Modules when you add them
to a Signature Series controller module.
Short form: ISO
Input events
This device type can initiate the following input events:
Acknowledge
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
none
KPDISP device type

Description
Assign the KPDISP device type when adding a KPDISP Keypad Display to a 3-SAC
module.
No events or commands are associated with this device type; however, each KPDISP has
several pseudo points for which you can create rules.
Short form: KPDISP
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
LampTest device type

Description
This device type is for system use only.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
LED device type

Description
The SDU assigns the LED device type to light-emitting diodes on control-display modules.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
FastBlink
LEDOff
Off
On
SlowBlink
Steady
LocalAlarm device type

Description
The SDU assigns the LocalAlarm device type to the pseudo point that loop controller
modules change to the active state when an unprogrammed device on their circuit goes into
alarm.
Short form: LALM
Input events
This device type can initiate the following input events:
Acknowledge
LocalAlarm
Output commands
This device type can respond to the following output commands:
Disable
Enable
LocalMonitor device type

Description
The SDU assigns the LocalMonitor device type to pseudo points that monitor the activity of
rail module functions.
Short form: LMON
Input events
This device type can initiate the following input events:
Acknowledge
LocalMonitor
Output commands
This device type can respond to the following output commands:
Disable
Enable
LocalRelay device type

Description
The SDU assigns the LocalRelay device type to pseudo points that monitor a channel
selection relay on a zoned amplifier module.
Short form: LRLAY
Input events
This device type can initiate the following input events:
Acknowledge
RelayConfirmation
Output commands
This device type can respond to the following output commands:
Disable
Enable
LocalTrouble device type

Description
The SDU assigns the LocalTrouble device type to pseudo points that supervise circuits on
LRM modules for possible fault conditions.
Short form: LTRB
Input events
This device type can initiate the following input events:
Acknowledge
LocalTrouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
LogicalOutput device type

Description
The SDU assigns the LogicalOutput device type to logical outputs.
Short form: LOUT
Input events
This device type can initiate the following input events:
RelayConfirmation
Output commands
This device type can respond to the following output commands:
Enable
Disable
On
Off
LoopControllerResetExt device type

Description
The SDU assigns the LoopControllerResetExt device type to the pseudo point that changes
to the active state when a loop controller stays in the reset mode longer than normally
required.
Short form: LCREXT
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
none
Matrix device type

Description
The SDU assigns the Matrix device type to Matrix Groups.
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Monitor
Supervisory
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
MComAccount device type

Description
The SDU assigns the MComAccount device type to the accounts you create when
configuring a 3-MODCOM.
Short form: MACCT
Input events
This device type can initiate the following input events:
Disabled
DisabledTrouble
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Send
MComCompany device type

Description
The SDU assigns the MComCompany device type to the companies you create with the
Configure > Company command.
This device type is for system use only.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
Monitor device type

Description
Assign the Monitor device type to normally-open, non-latching input circuits that monitor
switch closures.
For CRC input circuits, these are devices not related to security partitions. Typically used
for request to exit buttons, unlock or open buttons, and panic bars.
Short form: MON
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
Monitor
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
MSG device type

Description
Assign the MSG device type to the recorded audio messages stored in a 3-ASU. The MSG
device type is only used to identify the message in the database and is not used when
writing a rule.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
MsgOff
MsgOn
NetworkOverflowFault device type

Description
The SDU assigns the NetworkOverflowFault device type to a panel's Network Overflow
Fault pseudo point. The pseudo point changes to the active state when the panel must
disconnect from the network due to an excess of network traffic.
Input events
This device type can initiate the following input events:
Acknowledge
Output commands
This device type can respond to the following output commands:
none
None device type

Description
The SDU assigns the None device type to the second address of dual-address Signature
Series modules, when the module's configuration prohibits use of that address. The system
programmer can also assign the None device type when configuring a dual address module
when the second address is unused.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
NonsupervisedOutput device type

Description
Assign the NonsupervisedOutput device type to nonsupervised, dry contact output circuits.
Nonsupervised output circuits do not monitor their output for open or shorted wiring.
Short form: NSO
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
TroubleTest
NSAudibleOutput device type

Description
Assign the NSAudibleOutput device type to a Signature relay/sounder group.
Short form: NSAUDO
Input events
This device type can initiate the following input events:
RelayConfirmation
Output commands
This device type can respond to the following output commands:
Off
On
NSCommonAlarmOutput device type

Description
Assign the NSCommonAlarmOutput device type to a nonsupervised, dry contact output
circuit that requires automatic activation when a panel's FirstAlarm event occurs. The
system restores the output when an operator presses Alarm Silence.
You do not have to write a rule to activate a NSCommonAlarmOutput device.
Short form: NSCAO
Input events
This device type can initiate the following input events:
Acknowledge
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
NSCommonAlarmOff
NSCommonAlarmOn
Off
On
TroubleTest
NSCommonMonitorOutput device type

Description
Assign the NSCommonMonitorOutput device type to a nonsupervised, dry contact output
circuit that requires automatic activation when a panel's FirstMonitor event occurs. You do
not have to write a rule to activate a NSCommonMonitorOutput device.
Short form: NSCMO
Input events
This device type can initiate the following input events:
Acknowledge
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
NSCommonMonitorOff
NSCommonMonitorOn
Off
On
TroubleTest
NSCommonSupervisoryOutput device type

Description
Assign the NSCommonSupervisoryOutput device type to a nonsupervised, dry contact
output circuit that requires automatic activation when a panel's FirstSupervisory event
occurs. You do not have to write a rule to activate a NSCommonSupervisoryOutput device.
Short form: NSCSO
Input events
This device type can initiate the following input events:
Acknowledge
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
NSCommonSupervisoryOff
NSCommonSupervisoryOn
Off
On
TroubleTest
NSCommonTroubleOutput device type

Description
Assign the NSCommonTroubleOutput device type to a nonsupervised, dry contact output
circuit that requires automatic activation when a panel's FirstTrouble event occurs. You do
not have to write a rule to activate a NSCommonTroubleOutput device.
Short form: NSCTO
Input events
This device type can initiate the following input events:
Acknowledge
RelayConfirmation
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
NSCommonTroubleOff
NSCommonTroubleOn
Off
On
TroubleTest
NSVisibleOutput device type

Description
Assign the NSVisibleOutput device type to a Signature relay/sounder group.
Short form: NSVISO
Input events
This device type can initiate the following input events:
RelayConfirmation
Output commands
This device type can respond to the following output commands:
Off
On
PanelCommFault device type

Description
The SDU assigns the PanelCommFault device type to panel pseudo points that monitor
panel communications.
Short form: PCF
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
none
Partition device type

Description
The SDU assigns the Partition device type to partitions.
Short form: PART
Input events
This device type can initiate the following input events:
SecurityAlarm
SecurityAway
SecurityAwayFail
SecurityDisarmed
SecurityEntryTimer
SecurityExitTimer
SecurityStay
SecurityStayFail
Output commands
This device type can respond to the following output commands:
Away
ConditionalAway
ConditionalStay
Disarm
ResetPartition
Stay
UpdateStatus
PartitionRouting device type

Description
The SDU assigns the PartitionRouting device type to a partition route.
Input events
This device type can initiate the following input events:
None
Output commands
This device type can respond to the following output commands:
None
PhoneRiser device type

Description
Assign the PhoneRiser device type to Signature SIGA-RM1 and SIGA-MRM1 modules
when used to monitor phone risers (module personality code 24).
Short form: PHRSR
Input events
This device type can initiate the following input events:
Acknowledge
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
none
Power device type

Description
Assign the Power device type to active-latching input circuits that supervise the electrical
power supplied to fire pumps or other sprinkler system equipment to determine when power
is not present.
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
SprinklerSupervisory
Supervisory
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
PS/NAC device type
When you add a cabinet to a project, the SDU assigns a device type of PS/NAC to the
primary Power Supply NAC module.
There are no input events or output commands associated with a PS/NAC device. Each has
several LocalTrouble pseudo points for which you can write rules.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
On
NAC20
NAC120
NACTemporal
Pull device type

Description
Assign the Pull device type to input circuits that connect to manual pull stations.
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
R1 device type

Description
SDU assigns the R1 device type to a panel's R1 pseudo point. The R1 pseudo point
changes to the active state when:
An operator presses a momentary switch that executes the Reset command on the
local panel
An operator presses a momentary switch that executes the Reset command on a
remote panel that is part of the same network routing group as the local panel.
Input events
This device type can initiate the following input events:
R1
Output commands
This device type can respond to the following output commands:
none
R2 device type

Description
The SDU assigns the R2 device type to a panel's R2 pseudo point. The R2 pseudo point
automatically changes to the active state when the R1 event restores.
Input events
This device type can initiate the following input events:
R2
Output commands
This device type can respond to the following output commands:
none
R3 device type

Description
The SDU assigns the R3 device type to a panel's R3 pseudo point. The R3 pseudo point
automatically changes to the active state when the R2 event restores.
Input events
This device type can initiate the following input events:
R3
Output commands
This device type can respond to the following output commands:
none
RebootFault device type

Description
The SDU assigns the RebootFault device type to a panel's RebootFault pseudo point. The
RebootFault pseudo point monitors CPU functions and changes to the active state when a
panel restarts unexpectedly.
Short form: RBF
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
none
Reset device type

Description
The SDU assigns the Reset device type to a panel's Reset pseudo point. The Reset
pseudo point changes to the active state when:
An operator presses a momentary switch on the local panel that executes the Reset
command
An operator presses a momentary switch on a remote panel that executes the
Reset command and the remote panel is part of the same network route as the local
panel
When the Reset pseudo point changes to the active state, the panel activates its automatic
Reset responses and any programmed output responses written for the Reset event.
Input events
This device type can initiate the following input events:
Reset
Output commands
This device type can respond to the following output commands:
none
Security device type

Description
Assign the Security device type to active-latching input circuits that monitor supervisory or
tamper switches.
Short form: SEC
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
Security
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
Security24Hour device type

Description
Assign the Security24Hour device type to any device that is armed and active continuously,
regardless of whether the partition is armed or disarmed. Typically used with high security
devices where a violation of the device during any armed or disarmed condition is reported
as a security alarm to the CMS.
Short form: SEC24
Input events
This device type can initiate the following input events:
SecurityAlarm
SecurityBypassed
SecurityDisabled
SecurityFault
SecurityMaintenance
SecurityTamper
ServiceDevice
This device type signals different events based on the personality code, partition state and
circuit condition. Use the following table to determine which event to use when writing a
rule.

Personality Code Partition Circuit Event

State Condition
Basic Security ArmedAway, Circuit open SecurityAlarm
ArmedStay,
or Disarmed Circuit short SecurityAlarm
Device fault SecurityFault
Security Open ArmedAway, Circuit open SecurityFault
ArmedStay,
or Disarmed Circuit short SecurityAlarm
Device fault SecurityFault
Security Closed ArmedAway, Circuit open SecurityAlarm
ArmedStay,
or Disarmed Circuit short SecurityFault
Device fault SecurityFault
Security Open with ArmedAway, Circuit open SecurityTamper
Tamper ArmedStay,
or Disarmed Circuit short SecurityAlarm
Device fault SecurityFault
Security Closed with ArmedAway, Circuit open SecurityAlarm
Tamper ArmedStay,
or Disarmed Circuit short SecurityTamper
Device fault SecurityFault
Security-Tamper ArmedAway, Circuit open SecurityTamper
ArmedStay,
or Disarmed Circuit short SecurityTamper
Device fault SecurityFault
Security- ArmedAway, Circuit open SecurityMaintenance
Maintenance ArmedStay,
or Disarmed Circuit short SecurityMaintenance
Device fault SecurityFault

Note: You must have a rule that runs a security alarm response for every SecurityAlarm,
SecurityFault, or SecurityTamper event.
Output commands
This device type can respond to the following output commands:
Bypass
Disable
Enable
RemoveBypass
Active1Test
Active2Test
AlarmTest
PrealarmTest
TroubleTest
SecurityDay device type

Description
Assign the SecurityDay device type to any device that is always active, even when the
partition is disarmed. Typically used with glass break detectors, foil, screens, and fixed
traps.
Short form: SECDAY
Input events
This device type can initiate the following input events:
SecurityAlarm
SecurityBypassed
SecurityDisabled
SecurityDisarmedAlarm
SecurityDisarmedFault
SecurityDisarmedTamper
SecurityFault
SecurityMaintenance
SecurityTamper
ServiceDevice
This device type signals different events based on the personality code, partition state, and
circuit condition. Use the following table to determine which event to use when writing a
rule.

Personality Code Partition State Circuit Condition Event

Basic Security ArmedAway or Circuit open SecurityAlarm
ArmedStay
Circuit short SecurityAlarm
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedAlarm
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Open ArmedAway or Circuit open SecurityFault
ArmedStay
Circuit short SecurityAlarm
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedFault
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Closed ArmedAway or Circuit open SecurityAlarm
ArmedStay
Circuit short SecurityFault
Device fault SecurityFault
Door ajar invalid condition
 Disarmed Circuit open SecurityDisarmedAlarm
Circuit short SecurityDisarmedFault
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Open with ArmedAway or Circuit open SecurityTamper
Tamper ArmedStay
Circuit short SecurityAlarm
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedTamper
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Closed ArmedAway or Circuit open SecurityAlarm
with Tamper ArmedStay
Circuit short SecurityTamper
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedAlarm
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security-Tamper ArmedAway or Circuit open SecurityTamper
ArmedStay
Circuit short SecurityTamper
Device fault SecurityFault
Disarmed Circuit open SecurityDisarmedTamper
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Security- ArmedAway or Circuit open SecurityMaintenance
Maintenance ArmedStay
Circuit short SecurityMaintenance
Device fault SecurityFault
Disarmed Circuit open SecurityMaintenance
Circuit short SecurityMaintenance
Device fault SecurityDisarmedFault

Notes
The Door Ajar function is configurable in the ACDB for perimeter access doors.
You must have a rule that runs a security alarm response for every SecurityAlarm,
SecurityFault, or SecurityTamper event.
Output commands
This device type can respond to the following output commands:
Bypass
Disable
Enable
RemoveBypass
Active1Test
Active2Test
AlarmTest
PrealarmTest
TroubleTest
SecurityIMonitor device type

Description
Assign the SecurityIMonitor device type to interior devices that should be secured
continuously and if opened while the partition is disarmed, or armed stay, cause local
annunciation. Activating this type of device when the partition is armed away causes a
security alarm. Typically used on stockroom type doors or cages where a violation is
handled by employees on site and not reported to an off-site monitoring station.
Short form: SECIMON
Input events
This device type can initiate the following input events:
SecurityAlarm
SecurityBypassed
SecurityDisabled
SecurityDisarmedAlarm
SecurityDisarmedFault
SecurityDisarmedTamper
SecurityFault
SecurityMaintenance
SecurityTamper
ServiceDevice
This device type signals different events based on the personality code, partition state, and
circuit condition. Use the following table to determine which event to use when writing a
rule.

Personality Code Partition State Circuit Event

Condition
Basic Security ArmedAway Circuit open SecurityAlarm
Circuit short SecurityAlarm
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedAlarm
Disarmed
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Security Open ArmedAway Circuit open SecurityFault
Circuit short SecurityAlarm
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedFault
Disarmed
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Security Closed ArmedAway Circuit open SecurityAlarm
Circuit short SecurityFault
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedAlarm
Disarmed
Circuit short SecurityDisarmedFault
Device fault SecurityDisarmedFault
Security Open with ArmedAway Circuit open SecurityTamper
Tamper
Circuit short SecurityAlarm
 Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedTamper
Disarmed
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Security Closed with ArmedAway Circuit open SecurityAlarm
Tamper
Circuit short SecurityTamper
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedAlarm
Disarmed
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Security-Tamper ArmedAway Circuit open SecurityTamper
Circuit short SecurityTamper
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedTamper
Disarmed
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Security- ArmedAway Circuit open SecurityMaintenance
Maintenance
Circuit short SecurityMaintenance
Device fault SecurityFault
ArmedStay or Circuit open SecurityMaintenance
Disarmed
Circuit short SecurityMaintenance
Device fault SecurityDisarmedFault

Notes: You must have a rule that runs a security alarm response for every SecurityAlarm,
SecurityFault, or SecurityTamper event.
Output commands
This device type can respond to the following output commands:
Bypass
Disable
Enable
RemoveBypass
Active1Test
Active2Test
AlarmTest
PrealarmTest
TroubleTest
SecurityInterior device type

Description
Assign the SecurityInterior device type to an interior detection device that allows free
passage into, out of, or through a partition when that partition is disarmed or armed stay.
Examples are: motion detectors, interior doors, or photo beams.
When the partition is armed away, this type of device provides interior detection of intrusion
through ceilings, walls, or otherwise unprotected openings. When the partition is armed
stay, these devices are bypassed, allowing staff to freely move about the interior without
causing a security alarm.
Short form: SECINT
Input events
This device type can initiate the following input events:
SecurityAlarm
SecurityBypassed
SecurityDisabled
SecurityDisarmedAlarm
SecurityDisarmedFault
SecurityDisarmedTamper
SecurityFault
SecurityMaintenance
SecurityTamper
ServiceDevice
This device type signals different events based on the personality code, partition state, and
circuit condition. Use the following table to determine which event to use when writing a
rule.

Personality Code Partition State Circuit Event

Condition
Basic Security ArmedAway Circuit open SecurityAlarm
Circuit short SecurityAlarm
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedAlarm
Disarmed
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Security Open ArmedAway Circuit open SecurityFault
Circuit short SecurityAlarm
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedFault
Disarmed
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Security Closed ArmedAway Circuit open SecurityAlarm
Circuit short SecurityFault
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedAlarm
Disarmed
Circuit short SecurityDisarmedFault
Device fault SecurityDisarmedFault
Security Open with ArmedAway Circuit open SecurityTamper
Tamper
Circuit short SecurityAlarm
 Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedTamper
Disarmed
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Security Closed with ArmedAway Circuit open SecurityAlarm
Tamper
Circuit short SecurityTamper
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedAlarm
Disarmed
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Security-Tamper ArmedAway Circuit open SecurityTamper
Circuit short SecurityTamper
Device fault SecurityFault
ArmedStay or Circuit open SecurityDisarmedTamper
Disarmed
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Security- ArmedAway Circuit open SecurityMaintenance
Maintenance
Circuit short SecurityMaintenance
Device fault SecurityFault
ArmedStay or Circuit open SecurityMaintenance
Disarmed
Circuit short SecurityMaintenance
Device fault SecurityDisarmedFault

Notes
The SecurityDisarmedAlarm event is only sent to the panel on demand.
You must have a rule that runs a security alarm response for every SecurityAlarm,
SecurityFault, or SecurityTamper event.
Output commands
This device type can respond to the following output commands:
Bypass
Disable
Enable
RemoveBypass
Active1Test
Active2Test
AlarmTest
PrealarmTest
TroubleTest
SecurityPerimeter device type

Description
Assign the SecurityPerimeter device type to any perimeter door or window that allows free
passage in and out when the partition is disarmed. When the partition is armed stay or
away, opening a door or window of this device type activates a security alarm.
Short form: SECPER
Input events
This device type can initiate the following input events:
SecurityAlarm
SecurityBypassed
SecurityDisabled
SecurityDisarmedAlarm
SecurityDisarmedFault
SecurityDisarmedTamper
SecurityFault
SecurityMaintenance
SecurityTamper
ServiceDevice
This device type signals different events based on the personality code, partition state, and
circuit condition. Use the following table to determine which event to use when writing a
rule.

Personality Code Partition State Circuit Condition Event

Basic Security ArmedAway or Circuit open SecurityAlarm
ArmedStay
Circuit short SecurityAlarm
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedAlarm
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Open ArmedAway or Circuit open SecurityFault
ArmedStay
Circuit short SecurityAlarm
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedFault
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Closed ArmedAway or Circuit open SecurityAlarm
ArmedStay
Circuit short SecurityFault
Device fault SecurityFault
Door ajar invalid condition
 Disarmed Circuit open SecurityDisarmedAlarm
Circuit short SecurityDisarmedFault
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Open with ArmedAway or Circuit open SecurityTamper
Tamper ArmedStay
Circuit short SecurityAlarm
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedTamper
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Closed ArmedAway or Circuit open SecurityAlarm
with Tamper ArmedStay
Circuit short SecurityTamper
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedAlarm
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security-Tamper ArmedAway or Circuit open SecurityTamper
ArmedStay
Circuit short SecurityTamper
Device fault SecurityFault
Disarmed Circuit open SecurityDisarmedTamper
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Security- ArmedAway or Circuit open SecurityMaintenance
Maintenance ArmedStay
Circuit short SecurityMaintenance
Device fault SecurityFault
Disarmed Circuit open SecurityMaintenance
Circuit short SecurityMaintenance
Device fault SecurityDisarmedFault

Notes
The SecurityDisarmedAlarm event is only sent to the panel once every sixty seconds.
The Door Ajar function is configurable in the ACDB for perimeter access doors.
You must have a rule that runs a security alarm response for every SecurityAlarm,
SecurityFault, or SecurityTamper event.
Output commands
This device type can respond to the following output commands:
Bypass
Disable
Enable
RemoveBypass
Active1Test
Active2Test
AlarmTest
PrealarmTest
TroubleTest
SecurityPMonitor device type

Description
Assign the SecurityPMonitor device type to exterior doors that should be secured
continuously. Opening while the partition is disarmed causes a local audible and visual
indication. Opening this type of point when the partition is armed away or stay causes a
security alarm. Typically used on emergency exit doors where a violation during the
disarmed condition is handled by employees on site and not reported to an off-site
monitoring station.
Short form: SECPMO
Input events
This device type can initiate the following input events:
SecurityAlarm
SecurityBypassed
SecurityDisabled
SecurityDisarmedAlarm
SecurityDisarmedFault
SecurityDisarmedTamper
SecurityFault
SecurityMaintenance
SecurityTamper
ServiceDevice
This device type signals different events based on the personality code, partition state, and
circuit condition. Use the following table to determine which event to use when writing a
rule.

Personality Code Partition State Circuit Condition Event

Basic Security ArmedAway or Circuit open SecurityAlarm
ArmedStay
Circuit short SecurityAlarm
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedAlarm
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Open ArmedAway or Circuit open SecurityFault
ArmedStay
Circuit short SecurityAlarm
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedFault
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Closed ArmedAway or Circuit open SecurityAlarm
ArmedStay
Circuit short SecurityFault
Device fault SecurityFault
Door ajar invalid condition
 Disarmed Circuit open SecurityDisarmedAlarm
Circuit short SecurityDisarmedFault
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Open with ArmedAway or Circuit open SecurityTamper
Tamper ArmedStay
Circuit short SecurityAlarm
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedTamper
Circuit short SecurityDisarmedAlarm
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security Closed ArmedAway or Circuit open SecurityAlarm
with Tamper ArmedStay
Circuit short SecurityTamper
Device fault SecurityFault
Door ajar invalid condition
Disarmed Circuit open SecurityDisarmedAlarm
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Door ajar SecurityMaintenance
Security-Tamper ArmedAway or Circuit open SecurityTamper
ArmedStay
Circuit short SecurityTamper
Device fault SecurityFault
Disarmed Circuit open SecurityDisarmedTamper
Circuit short SecurityDisarmedTamper
Device fault SecurityDisarmedFault
Security- ArmedAway or Circuit open SecurityMaintenance
Maintenance ArmedStay
Circuit short SecurityMaintenance
Device fault SecurityFault
Disarmed Circuit open SecurityMaintenance
Circuit short SecurityMaintenance
Device fault SecurityDisarmedFault

Notes
The Door Ajar function is configurable in the ACDB for perimeter access doors.
You must have a rule that runs a security alarm response for every SecurityAlarm,
SecurityFault, or SecurityTamper event.
Output commands
This device type can respond to the following output commands:
Bypass
Disable
Enable
RemoveBypass
Active1Test
Active2Test
AlarmTest
PrealarmTest
TroubleTest
ServiceDeviceSupervision device type

Description
Assign the ServiceDeviceSupervision device type to the pseudo point that changes to the
active state when a circuit under test is left active at the time the Service group test is
canceled.
Short form: SERVSUP
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
none
ServiceGroup device type

Description
Assign the ServiceGroup device type to Service logic groups.
Short form: SG
Input events
This device type can initiate the following input events:
Acknowledge
ObjectRunning
ServiceGroup
Output commands
This device type can respond to the following output commands:
Off
On
ServiceGroupActive device type

Description
The SDU assigns the ServiceGroupActive device type to the ServiceGroupActive event's
pseudo point. The ServiceGroupActive pseudo point changes to the active state when an
operator starts a test on a Service Group from the LCD module.
Short form: SGA
Input events
This device type can initiate the following input events:
Acknowledge
ServiceGroupActive
Output commands
This device type can respond to the following output commands:
none
SignalSilenceInhibit device type

Description
The SDU assigns the SignalSilenceInhibit device type to the system SignalSilenceInhibit
pseudo point (Signal_Silence_Inhibit_00_00). The SignalSilenceInhibit pseudo point changes
to the active state when the signal silence inhibit timer starts and is automatically restored
when the timer times out.
Short form: none
Input events
This device type can initiate the following input events:
SignalSilenceInhibit
Output commands
This device type can respond to the following output commands:
none
Smoke device type

Description
Assign the Smoke device type to an initiating device or circuit that changes to the alarm
state when there is enough smoke in the protected area to indicate the presence of a fire.
Short form: SMK
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Disabled
DisabledActive
DisabledTrouble
MaintenanceAlert
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
SignalEvacuate
SignalOff
Calibrate
Active1Test
AlarmTest
TroubleTest
SmokePre device type

Description
Assign the SmokePre device type to an initiating device or circuit that provides early
notification of a possible fire condition then changes to the alarm state when there is enough
smoke in the protected area to indicate the presence of a fire.
Short form: PRE
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Disabled
DisabledActive
DisabledTrouble
MaintenanceAlert
PreAlarm
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
SignalEvacuate
SignalOff
Calibrate
Active1Test
Active2Test
AlarmTest
PrealarmTest
TroubleTest
SmokeVfy device type

Description
Assign the SmokeVfy device type to an initiating device or circuit that verifies there is
enough smoke in the protected area to indicate the presence of a fire before changing to
the alarm state.
Short form: VFY
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
AlarmVerify
Disabled
DisabledActive
DisabledTrouble
MaintenanceAlert
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
SignalEvacuate
SignalOff
Calibrate
Active1Test
AlarmTest
TroubleTest
SprinklerSupervisory device type

Description
Assign the SprinklerSupervisory device type to a circuit that supervises a component of the
sprinkler system.
Note: The SprinklerSupervisory device type is no longer available. Use the Supervisory
device type instead. Any existing rules using the SprinklerSupervisory device type will still
function properly.
Short form: SPSUP
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
SprinklerSupervisory
Supervisory
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
StageOne device type

Description
Assign the StageOne device type to the first address (pre-alarm stage) of a circuit that
connects to a two-stage pull station.
Short form: STAGE1
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Disabled
DisabledActive
DisabledTrouble
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Active1Test
AlarmTest
TroubleTest
StageTwo device type

Description
Assign the StageTwo device type to the second address (alarm stage) of a circuit that
connects to a two-stage pull station.
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Disabled
DisabledActive
DisabledTrouble
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Active1Test
AlarmTest
Disable
Enable
TroubleTest
Startup device type

Description
The SDU assigns the Startup device type to the pseudo point that is activated when a panel
is initially powered up or when an operator initiates the Restart command from the LCD
module.
Input events
This device type can initiate the following input events:
Startup
Output commands
This device type can respond to the following output commands:
none
SupervisedOutput device type

Description
Assign the SupervisedOutput device type to notification appliance signaling circuits that
monitor their output for open or shorted wiring.
Short form: SUP
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
TroubleTest
Supervisory device type

Description
Assign the Supervisory device type to input circuits used for supervising switch closures.
Short form: SUPV
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
SprinklerSupervisory
Supervisory
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
SensorBypassOff (SIGA2-PHS only)
SensorBypassOn (SIGA2-PHS only)
Switch device type

Description
The SDU assigns the Switch device type to control-display module switches.
Short form: SW
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
Switch
Output commands
This device type can respond to the following output commands:
Disable
Enable
SystemMonitor device type

Description
The SDU assigns the SystemMonitor device type to the system function pseudo points. The
system function pseudo points change to the active state when:
An operator presses a configured system function switch on the LCD panel or a
momentary switch
An operator activates the system function pseudo point from FireWorks
When the system function pseudo point changes to the active state, the panel activates any
programmed output responses written for SystemMonitor events.
Short form: SMON
Input events
This device type can initiate the following input events:
Acknowledge
SystemMonitor
Output commands
This device type can respond to the following output commands:
None
Tamper device type

Description
Assign the Tamper device type to input circuits that supervise a secured component of the
sprinkler system to determine when someone tries to gain access to it.
Short form: TAMP
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
SprinklerSupervisory
Supervisory
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
TaskFailure device type

Description
The SDU assigns the TaskFailure device type to the pseudo point that changes to the active
state when a CPU module takes too long to complete a task.
Short form: TFAIL
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
none
Temperature device type

Description
Assign the Temperature device type to input circuits that supervise the temperature
surrounding a component of the sprinkler system to determine when freezing temperatures
exist.
Short form: TEMP
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
SprinklerSupervisory
Supervisory
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
Text device type

Description
The SDU assigns the Text device type to Instruction Text Groups.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
Disable
Enable
TimeControl device type

Description
The SDU assigns the TimeControl device type to time controls.
Short form: TIME
Input events
This device type can initiate the following input events:
TimeControl
Output commands
This device type can respond to the following output commands:
Disable
Enable
TimedAccessOutput device type

Description
When you add a CRC to a 3-SAC module, the SDU creates pseudo points for that CRC.
Several of these pseudo-points can be used in rules to monitor or control the CRC. SDU
assigns the TimedAccessOutput device type to the following pseudo points:
Timed_Unlock
Relay_Timed
Short form: TACOUT
Input events
This device type can initiate the following input events:
AccessTrouble
Output commands
This device type can respond to the following output commands:
Off
Toggle
TroubleSilence device type

Description
This device type is for system use only.
Input events
This device type can initiate the following input events:
none
Output commands
This device type can respond to the following output commands:
none
TwoStageTimerActive device type

Description
The SDU assigns the TwoStageTimerActive device type to the TwoStageTimerActive
pseudo point. The TwoStageTimerActive pseudo point changes to the active state when a
panel's two stage timer starts counting down.
Short form: 2STAGEA
Input events
This device type can initiate the following input events:
Acknowledge
TwoStageTimerActive
Output commands
This device type can respond to the following output commands:
none
TwoStageTimerExpiration device type

Description
The SDU assigns the TwoStageTimerExpiration device type to the
TwoStageTimerExpiration pseudo point. The TwoStageTimerExpiration pseudo point
changes to the active state when a panel's two stage timer completes its count-down cycle.
Short form: 2STAGETO
Input events
This device type can initiate the following input events:
Acknowledge
TwoStageTimerExpiration
Output commands
This device type can respond to the following output commands:
none
UserTrouble device type

Description
The SDU assigns the UserTrouble device type to
Short form: USRTRB
Input events
This device type can initiate the following input events:
Acknowledge
Trouble
Output commands
This device type can respond to the following output commands:
None
Visible device type

Description
Assign the Visible device type to notification appliance circuits that produce a signal that a
person can see.
Note: By default for the Singapore marketplace, any devices or zones configured with this
device type cannot be disabled. If you are using the Singapore marketplace but want to use
the Disable command with this device type, check the Allow Disables check box on the
Project Parameters - Operations tab.
Short form: VIS
Input events
This device type can initiate the following input events:
Acknowledge
Disabled
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
TroubleTest
Waterflow device type

Description
Assign the Waterflow device type to input circuits that change to the alarm state when it
detects water flowing through the fire protection sprinkler system.
Short form: FLOW
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Disabled
DisabledActive
DisabledTrouble
RelayConfirmation
ServiceDevice
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
Off
On
Active1Test
AlarmTest
TroubleTest
Zone device type

Description
The SDU assigns the Zone device type to zone groups.
Input events
This device type can initiate the following input events:
Acknowledge
Alarm
Trouble
Output commands
This device type can respond to the following output commands:
Disable
Enable
AccessTrouble event

Description
Use the AccessTrouble event to activate a rule when AccessControl pseudo point on a CRC
changes to the active state.
Short form: ACCTRB
Syntax
AccessTrouble|ACCTRB device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The AccessTrouble event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the AccessTrouble event:
AccessDoorControl
AccessOutput
AccessTrouble
TimedAccessOutput
Example
The following rule turns on an LED when any CRC battery is low.
[CRC Battery Trouble]
ACCTRB AccessTrouble 'Low_Battery_*' : Slow 'CRC_Battery_Low' ;
ACFail event

Description
Use the ACFail event to activate a rule when any device configured as an ACFail device
type goes active. This can be the AC Brownout pseudo point associated with a power
supply or a device configured to detect a loss of power.
Note: The ACFail device must be part of an AND group.
Short form: ACF
Syntax
ACFail|ACF device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: ACFail event syntax requires a device type, an object label, or both.
Device types
The following device type can initiate the ACFail event:
ACFail
Example
The following rule sends a common trouble signal to a central monitoring station when the
ACFAIL AND group activates.
{******************** GENERAL ACFAIL ********************}
[GENERAL ACFAIL – RULE 1]
ACFAIL 'AC_Brownout_0<N:1-8>_02' : ON 'LOGIC_ACFAIL' ;
[GENERAL ACFAIL – RULE 2]
RLYCFG 'LOGIC_ACFAIL' : ACTIVATE 'AND_ACFAIL' ;
[GENERAL ACFAIL – RULE 3]
CMSFIRSTTROUBLE : ACTIVATE 'AND_ACFAIL' ;
[GENERAL ACFAIL – RULE 4]
MON 'AND_ACFAIL' : +SEND 'ACCT_1' MSG "130100000" ,
-SEND 'ACCT_1' MSG "330100000" ;
See also
Programming a general ACFail event response
Imposing a delay on off-site reporting of AC power failures
Acknowledge event

Description
Use the Acknowledge event to activate a rule when an operator acknowledges an event
displayed on the LCD.
Short form: ACK
Syntax
Acknowledge|ACK device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Notes
The Acknowledge event syntax requires that you specify a device type, an object
label, or both.
The Acknowledge input event can only be used when the system is configured as a
proprietary fire alarm system in accordance with NFPA 72.
Device types
The following device types can initiate the Acknowledge event:

24VRiser Gatevalve ServiceDeviceSupervision

AND GenAlarm ServiceGroup
Audible GenSmoke ServiceGroupActive
AudioRiser GroundFault Smoke
AuxPowerSupply Guard SmokePre
CardDBIncompat GuardPatrol SmokeVfy
CMSNonsupervisedOutput Heat SprinklerSupervisory
CMSSupervisedOutput Isolator StageOne
CommFailure LocalAlarm StageTwo
CommonAlarmOutput LocalMonitor SupervisedOutput
CommonMonitorOutput LocalRelay Supervisory
CommonSupervisoryOutput LocalTrouble Switch
DamperControl LoopControllerResetExt SystemMonitor
DamperFeedback Matrix Tamper
DoorControl Monitor TaskFailure
DoorFeedback NetworkOverflowFault Temperature
ExtDBIncompatibility NonsupervisedOutput TwoStageTimerActive
Failsafe NSCommonAlarmOutput TwoStageTimerExpiration
FanControl NSCommonMonitorOutput Visible
FanFeedback NSCommonSupervisoryOutput Waterflow
Firephone NSCommonTroubleOutput Zone
G_Audible PanelCommFault
G_Visible PhoneRiser
G_AudibleVisible Power
G_CommonAlarmOutput Pull
G_CommonMonitorOutput RebootFault
G_CommonSupervisoryOutput Security
Example
The following rule turns on the control-display module LED labeled Smk_1_Ack_LED when
an operator acknowledges the corresponding event on the LCD module.
[ACK Smoke]
ACK SMK 'Smk_1': Steady -low 'Smk_1_Ack_LED' ;
Activation event

Description
Use the Activation event to program responses for a command list. Command lists can be
activated by rules, by devices, or by external control systems. The Activation event is
generated whenever a command list is activated.
Short form: ACTVN
Syntax
Activation|ACTVN device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the command list
Notes
The Activation event syntax requires that you specify a device type, an object label,
or both.
Up to 32 commands can be used in a single command list rule
The Activation event for a command list can be used in more than one rule
You cannot use the $(Location:n-m) and $(Location) substitution strings in a
command list.
Device types
The following device types can initiate the Activation event:
CmdList
Examples
The following rule turns on a specific horn and strobe when MyCmdList is activated.
[On Horn Strobes]
Activation CMDLIST 'MyCmdList':
On AUD 'Level_1_Horn',
On VIS 'Level_1_Strobe';
The following rule uses the n-variable and index modifiers to turn on a specific horn and
strobe on separate levels.
[On Horn Strobes]
Activation CMDLIST 'MyCmdList_<n:1-3>':
On AUD 'Level_<n>_Horn',
On VIS 'Level_<n>_Strobe';
Alarm event

Description
Use the Alarm event to activate a rule when any initiating device or circuit on a panel or any
panel in the same network route changes to the alarm state.
Short form: none
Syntax
Alarm device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Notes: The Alarm event syntax requires that you specify a device type, an object label, or
both.
Device types
The following device types can initiate the Alarm event:

AND Smoke
Failsafe SmokePre
GenAlarm SmokeVfy
GenSmoke StageOne
Heat StageTwo
Matrix Waterflow
Pull Zone
Example
The following rule turns on the fan control circuit when any smoke detector with the word
"Lobby" anywhere in its label changes to the alarm state.
[Fan On]
Alarm SMK '*_Lobby_*' : FANON -high 'Fan_Control_*' ;
AlarmHeat event

Description
SIGA2-PHS devices contain two elements that you can use in either the split configuration
(each element can activate a different event type) or combined configuration (either element
activates the same event). In addition, you can program the device to use Operation or
Alternate Operation modes, which can produce different events upon activation.
Use the AlarmHeat event to activate a rule when the heat sensor of the SIGA2-PHS
activates, the device uses a split configuration, and the system is in either primary
Operation or Alternate Operation mode. Note: Operation is the primary or default behavior
of the system. Alternate Operation takes effect when a rule you program using the
Alternate Sensing or Alternate Sensitivity command executes, or when the user issues the
Alternate Sensing commands through the front panel.
Note: Use the Configure Cabinet > Modules > LRM Config > Loop Detectors tab to
configure the Device Type, Operation, and Alternate Operation settings.
The following tables show the different events the system generates upon sensor activation,
based on the settings for Operation and Alternate Operation.

Table 1: SIGA2-PHS Operation configuration settings and event activation

Operation set to Device type Photo event Heat event
Photo/Heat is Alarm Smoke Alarm Alarm
(combined configuration)
Photo is Supervisory | Heat is Supervisory Supervisory AlarmHeat
AlarmHeat
(split configuration)
Photo is AlarmSmoke | Heat is Smoke AlarmSmoke AlarmHeat
AlarmHeat
(split configuration)

Table 2: SIGA2-PHS Alternate Operation configuration settings and event activation

Operation set to Device type Photo event Heat event
Photo/Heat is Alarm Smoke Alarm Alarm
(combined configuration)
Photo is Supervisory | Heat is Supervisory Supervisory AlarmHeat
AlarmHeat
(split configuration)
Photo/Heat is AlarmSmoke Supervisory AlarmSmoke AlarmSmoke
(split configuration)
Photo is AlarmSmoke | Heat is Smoke AlarmSmoke AlarmHeat
AlarmHeat
(split configuration)

Short form: none

Syntax
AlarmHeat device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Device types
The following device type can initiate the AlarmHeat event:
Smoke
Supervisory
Example
The following rule turns on the control-display module LED labeled LED_AH_Active when
the system is in either primary or alternate operation, and the heat sensor activates on the
device labeled PHS1.
[Alarm Heat Active]
ALARMHEAT SUPV 'PHS1' : ON 'LED_AH_Active';
AlarmSilence event

Description
Use the AlarmSilence event to program output responses in addition to those that the Alarm
Silence function performs automatically. The AlarmSilence event occurs when an operator
presses a switch that executes the AlarmSilence command. The switch can be the Alarm
Silence switch on the LCD module or a momentary switch on a control-display module.
Short form: AS
Syntax
AlarmSilence|AS:
Notes
The AlarmSilence event syntax does not require that you specify a device type or an
object label.
Project_configuration settings determine if the Alarm Silence function automatically
silences only audible devices or both audible and visible device types.
Device types
The following device types can initiate the AlarmSilence event:
AlarmSilence
Example
The following rule turns on the control-display module LED labeled AS_Active_LED while
the Alarm Silence function is active.
[Alarm Silence Active]
AS:FAST -LOW 'AS_Active_LED';
AlarmSmoke event

Description
SIGA2-PHS devices contain two elements that you can use in either the split configuration
(each element activates a different event type) or combined configuration (either element
activates the same event). In addition, you can program the device to use Operation or
Alternate Operation modes, which can produce different events upon activation.
Use the AlarmSmoke event to activate a rule when the photo sensor of the SIGA2-PHS
activates, the device is configured for the AlarmSmoke split configuration, and the system is
in Alternate Operation mode. Note: Operation is the primary or default behavior of the
system. Alternate Operation takes effect when a rule you program using the Alternate
Sensing or Alternate Sensitivity command executes, or when the user issues the Alternate
Sensing commands through the front panel.
Note: Use the Configure Cabinet > Modules > LRM Config > Loop Detectors tab to
configure the Device Type, Operation, and Alternate Operation settings.
The following tables show the different events the system generates upon sensor activation,
based the settings for Operation and Alternate Operation.

Table 1: SIGA2-PHS Operation configuration settings and event activation

Operation set to Device type Photo event Heat event
Photo/Heat is Alarm Smoke Alarm Alarm
(combined configuration)
Photo is Supervisory | Heat is Supervisory Supervisory AlarmHeat
AlarmHeat
(split configuration)
Photo is AlarmSmoke | Heat is Smoke AlarmSmoke AlarmHeat
AlarmHeat
(split configuration)

Table 2: SIGA2-PHS Alternate Operation configuration settings and event activation

Operation set to Device type Photo event Heat event
Photo/Heat is Alarm Smoke Alarm Alarm
(combined configuration)
Photo is Supervisory | Heat is Supervisory Supervisory AlarmHeat
AlarmHeat
(split configuration)
Photo/Heat is AlarmSmoke Supervisory AlarmSmoke AlarmSmoke
(split configuration)
Photo is AlarmSmoke | Heat is Smoke AlarmSmoke AlarmHeat
AlarmHeat
(split configuration)

Short form: none

Syntax
AlarmSmoke device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Device types
The following device type can initiate the AlarmSmoke event:
Smoke
Supervisory
Example
The following rule turns on the control-display module LED labeled LED_AS_Active when
the system is in alternate operation and either sensor activates on the device labeled PHS2.
[Alarm Smoke Active]
ALARMSMOKE SUPV 'PHS2' : ON 'LED_AS_Active';
AlarmVerify event

Description
Use the AlarmVerify event to activate a rule when a smoke detector starts its smoke
verification cycle. Typically, you use the AlarmVerify event to provide an indication of
potential alarm or pre-alarm conditions.
Short form: AVER
Syntax
AlarmVerify|AVER device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The AlarmVerify event syntax requires that you specify a device type, an object label,
or both.
Device types
The following device types can initiate the AlarmVerify event:
GenSmoke
SmokeVfy
Example
The following rule turns on the control-display module LED labeled Alrm_Vfy_On during the
smoke detector's verification process.
[Alarm Verify On]
AVER GENS 'Smk_*':SLOW -low 'Alrm_Vfy_On';
AllCall event

Description
Use the AllCall event to activate a rule when an operator presses the All Call switch on the
3-ASU.
Short form: AC
Syntax
AllCall|AC:
Note: The AllCall event syntax does not require that you specify a device type or an object
label.
Device types
The following device types can initiate the AllCall event:
AllCall
Example
The following rule turns on the control-display module LED labeled AllCall_LED when an
operator presses the All Call switch on the 3-ASU.
[All Call On]
AllCall : FAST -low 'AllCall_LED';
AllCallMinus event

Description
Use the AllCallMinus event to activate a rule when an operator presses the All Call Minus
switch on the 3-ASU.
Short form: ACM
Syntax
AllCallMinus|ACM:
Note: The AllCallMinus event syntax does not require that you specify a device type or an
object label.
Device types
The following device types can initiate the AllCallMinus event:
AllCallMinus
Example
The following rule turns on the control-display module LED labeled AllCallMinus_LED when
an operator presses the All Call Minus switch on the 3-ASU.
[All Call Minus On]
AllCallMinus:FAST -low 'AllCallMinus_LED';
AlternateSensitivityMode event
Use the AlternateSensitivityMode event to program an output response that activates when
the system is operating in alternate sensitivity or alternate sensing mode (alternate
sensitivity, alternate alarm verify, and alternate prealarm option settings are in effect). The
system operates in alternate sensitivity/sensing mode when:
An operator activates the Alt Sensitivity command On the LCD command menu.
The output side of a rule activates the AlternateSensitivityOn command or the
RemoteAltSensitivityOn command.
The output side of a rule activates the AlternateSensingOn command or the
RemoteAltSensingOn command.
An operator presses a common control switch on the LCD that is configured to
execute the Alternate Sensing command.
Short form: ALTSMODE
Syntax
AlternateSensitivityMode|ALTSMODE:
Note: The AlternateSensitivityMode event syntax does not require that you specify a device
type or an object label.
Device types
The following device types can initiate the AlternateSensitivityMode event:
AlternateSensitivityMode
Example
The following rule turns on the control-display module LED labeled Alt_Sensing_On_LED
while the alternate sensing mode is active.
[Alternate Sensing Mode Active]
ALTSMODE : FAST 'Alt_Sensing_On_LED' ;
CallIn event

Description
Use the CallIn event to activate a rule when a fire safety professional plugs a handset into a
firefighter's telephone jack.
Short form: CI
Syntax
CallIn|CI device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The CallIn event syntax requires that you specify a device type, an object label, or
both.
Device types
The following device types can initiate the CallIn event:
Firephone
Example
The following rule turns on a control-display module LED when a firefighter makes a
connection to the corresponding phone jack.
[Call In Active]
CI FP 'FP_LVL_<n:1-10>' : Steady -low 'Call_In_LVL<n>' ;
COAlarm event

Description
Use the COAlarm event to activate a rule when any CO initiating device or circuit on a panel
(or any panel in the same network route) changes to the alarm state.
Note: The SIGA-TCDR module uses two addresses: address 1 is tied to pattern 1,
address 2 is tied to pattern 2. If both channels are activated, channel 1 takes priority.
Patterns and channel configurations are driven by the marketplace. For example, in the US
marketplace channel 1 is TC3 and channel 2 is TC4. For more details, see Programming a
SIGA-TCDR for CO.
Short form: COALM
Syntax
COAlarm|COALM device_type 'object_label':
Where:
device_type specifies the device type of the CO device initiating the event
object_label specifies the label of the CO device initiating the event
Note: The Alarm event syntax requires that you specify a device type, an object label, or
both.
Device types
The following device types can initiate the COAlarm event:
COAlarm
Heat
Smoke
SmokePre
SmokeVfy
Example
The following rule turns on a TCDR when a COS detector in the mechanical equipment
room goes into alarm.
[COAlarm Mechanical Equipment Room]
COALM 'Mech_Equ_Rm_129' : On 'LVL_1_Siga_TCDR_CH_1' ;
COMonitor event

Description
Use the COMonitor event to activate a rule when any CO monitor point on a panel (or any
panel in the same network route) changes to the active state.
Short form: COMON
Syntax
COMonitor|COMON device_type 'object_label':
Where:
device_type specifies the device type of the CO device initiating the event
object_label specifies the label of the CO device initiating the event
Note: The COMonitor event requires that you specify a device type, an object label, or
both.
Device types
The following device types can initiate the COMonitor event:
COMonitor
Heat
Smoke
SmokePre
SmokeVfy
Example
The following rule turns on a TCDR when a CO monitor point in the mechanical equipment
room activates.
[COMonitor Mechanical Equipment Room]
COMON 'Mech_Equ_Rm_129' : On 'LVL_1_Siga_TCDR_CH_1' ;
Note: The SIGA-TCDR module uses two addresses: address 1 is tied to pattern 1,
address 2 is tied to pattern 2. If both channels are activated, channel 1 takes priority.
Patterns and channel configurations are driven by the marketplace. For example, in the US
marketplace channel 1 is TC3 and channel 2 is TC4. For more details, see Programming a
SIGA-TCDR for CO.
COSupervisory event

Description
Use the COSupervisory event to activate a rule when any CO point on a panel (or any panel
in the same network route) changes to the supervisory state.
Short form: COSUP
Syntax
COSupervisory|COSUP device_type 'object_label':
Where:
device_type specifies the device type of the CO device initiating the event
object_label specifies the label of the CO device initiating the event
Note: The COSupervisory event syntax requires that you specify a device type or an object
label, or both.
Device types
The following device types can initiate the COSupervisory event:
COSupervisory
Heat
Smoke
SmokePre
SmokeVfy
Example
The following rule turns on a TCDR when a CO supervisory point in the mechanical
equipment room activates.
[COSupervisory Mechanical Equipment Room]
COSUP 'Mech_Equ_Rm_129' : On 'LVL_1_Siga_TCDR_CH_1' ;
Note: The SIGA-TCDR module uses two addresses: address 1 is tied to pattern 1,
address 2 is tied to pattern 2. If both channels are activated, channel 1 takes priority.
Patterns and channel configurations are driven by the marketplace. For example, in the US
marketplace channel 1 is TC3 and channel 2 is TC4. For more details, see Programming a
SIGA-TCDR for CO.
CMSFirstTrouble event

Description
Use the CMSFirstTrouble event to program an output response that transmits a trouble
signal to a central monitoring station (CMS).
The CMSFirstTrouble event occurs the first time that any point on a panel or any panel in
the same network route changes to the trouble state. There are two exceptions:
3-MODCOM accounts (points with device type MComAccount) do not generate a
CMSFirstTrouble event
AC Brownout pseudo point (a LocalTrouble device type) does not generate a
CMSFirstTrouble event until after the AC Power Delay timer times out
In all cases, the CMSFirstTrouble event stays active until all trouble conditions restore.
Short form: CMSFT
Syntax
CMSFirstTrouble|CMSFT:
Note: The CMSFirstTrouble event syntax does not require a device type or an object label.
Device types
The following device types can initiate the CMSFirstTrouble event:
CMSFirstTrouble
Example
The following rule sends a common trouble signal to a Central Monitoring Station.
[CMS First Trouble On]
CMSFT:
+Send 'CMS_Account_SIA/DCS' "FT",
-Send 'CMS_Account_SIA/DCS' "FJ";
Disabled event

Description
Use the Disabled event to program output responses, in addition to the common disabled
responses that a panel activates automatically. The Disabled event occurs when a point on
a panel (or a panel in the same network routing group) changes to the disabled state.
Short form: DIS
Syntax
Disabled|DIS device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event

Notes
The Disabled event syntax requires that you specify a device type, an object label,
or both.
If you check the "Restore Event on Disable" check box on the Project Parameters -
Operations tab, when a device is disabled the system restores the device's off-
normal events. If you clear that check box, when a device is disabled the system
instead latches the device's off-normal events until the device is again enabled. This
affects both input events and output commands.
Device types
The following device types can initiate the Disabled event:

2 Stage Signal FanControl Power

AccessDoorControl FanFeedback Pull
AccessOutput Gatevalve Security
ACFail GenAlarm Smoke
AND G_Audible SmokePre
Audible G_Visible SmokeVfy
AudioRiser G_AudibleVisible SprinklerSupervisory
CMSNonsupervisedOutput G_CommonAlarmOutput StageOne
CMSSupervisedOutput G_CommonMonitorOutput StageTwo
COAlarm G_CommonSupervisoryOutput SupervisedOutput
COMonitor GenSmoke Supervisory
COSupervisory Guard Switch
CommonAlarmOutput Heat Tamper
DamperControl IPAccount Temperature
DamperFeedback LogicalOutput Visible
DoorControl MComAccount Waterflow
DoorFeedback Monitor
EmailAccount NonsupervisedOutput
Example
The following rule turns on an LED when a waterflow device is disabled.
[Flow Disabled Reminder]
DIS Waterflow 'Waterflow_Wing_<n:1-6>': Fast LED
'Waterflow_Off_Wing_<n>';
DisabledActive event

Description
Use the DisabledActive event to program output responses if a device in a disabled state
becomes active.
Short form: DISACT
Syntax
DisabledActive|DISACT device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The DisabledActive event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the DisabledActive event:

ACFail GenSmoke SprinklerSupervisory

COAlarm Guard StageOne
COMonitor Heat StageTwo
COSupervisory Monitor Supervisory
DamperFeedback Pull Switch
DoorFeedback Security Tamper
FanFeedback Smoke Temperature
Gatevalve SmokePre Waterflow
GenAlarm SmokeVfy
Example
The following rule turns on an LED when a smoke device that is disabled becomes active.
[Smoke Disabled Active]
DISACT Smoke 'Smk_Fl<n:1-6>': Fast LED
'Smoke_Disabled_Active_Fl<n>';
DisabledTrouble event

Description
Use the DisabledTrouble event to program output responses if a device in a disabled state
develops a fault.
Short form: DISTRB
Syntax
DisabledTrouble|DISTRB device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The DisabledTrouble event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the DisabledTrouble event:

ACFail GenSmoke SmokeVfy

COAlarm Guard SprinklerSupervisory
COMonitor Heat StageOne
COSupervisory MComAccount StageTwo
DamperFeedback Monitor Supervisory
DoorFeedback Pull Tamper
FanFeedback Security Temperature
Gatevalve Smoke Waterflow
GenAlarm SmokePre
Example
The following rule turns on an LED when a heat device that is disabled develops a fault.
[Smoke Disabled Active]
DISTRB Heat 'Heat_Fl<n:1-6>': Steady LED
'Heat_Disabled_Trb_Fl<n>';
Drill event

Description
Use the Drill event to program output responses in addition to those that the Drill function
performs automatically. The Drill event occurs when an operator presses a switch that
executes the Drill command. The switch can be the Drill switch on the LCD module or a
momentary switch on a control-display module.
Short form: none
Syntax
Drill:
Notes
The Drill event syntax does not require that you specify a device type or an object
label.
Project_configuration settings determine if the Drill function automatically activates
only audible, or audible and visible device types.
Device types
The following device types can initiate the Drill event:
Drill
Example
The following rule broadcasts the drill message over the General channel when an operator
presses a switch that executes the Drill command.
[Drill Function]
Drill:
AmpOn 'LVL*_Amp' to 'Ch_Gen_01_08',
MsgOn 'Drill_Message' to 'Ch_Gen_01_08';
See also
Configuring Drill operation
Evacuation event

Description
Use the Evacuation event to put a panel into alarm and activate its programmed alarm
responses regardless of the current state of any alarm initiating devices. The Evacuation
event occurs when an operator presses a momentary switch on a control-display module
that executes the Evacuation command.
Short form: EVAC
Syntax
Evacuation|EVAC:
Note: The Evacuation event syntax does not require a device type or an object label.
Device types
The following device types can initiate the Evacuation event:
Evacuation
Example
The following rule turns on the control-display module LED labeled Evac_Active when an
operator presses a switch that executes the Evacuation command.
[Evacuation Function]
EVAC : FAST -low 'Evac_Active';
FirstAlarm event

Description
Use the FirstAlarm event to program output responses in addition to the common alarm
responses that a panel activates automatically. The FirstAlarm event occurs the first time
that any point on a panel or any panel in the same network route changes to the alarm
state.
Short form: FA
Syntax
FirstAlarm|FA:
Note: The FirstAlarm event syntax does not require a device type or an object label.
Device types
The following device types can initiate the FirstAlarm event:
FirstAlarm
Example
The following rule turns on an LED when the FirstAlarm event occurs.
[First Alarm On]
FA:Steady -low 'First_Alarm_On';
FirstDisable event

Description
Use the FirstDisable event to program output responses in addition to the common disable
responses that a panel activates automatically. The FirstDisable event occurs the first time
that any point on a panel or any panel in the same network route changes to the disable
state.
Short form: FD
Syntax
FirstDisable|FD:
Note: The FirstDisable event syntax does not require a device type or an object label.
Device types
The following device types can initiate the FirstDisable event:
FirstDisable
Example
The following rule turns on an LED when the FirstDisable event occurs.
[First Disable On]
FD:SLOW -low 'First_Disable_On';
FirstMonitor event

Description
Use the FirstMonitor event to program output responses in addition to the common monitor
responses that a panel activates automatically. The FirstMonitor event occurs the first time
that any point on a panel or any panel in the same network route changes to the monitor
state.
Short form: FM
Syntax
FirstMonitor|FM:
Note: The FirstMonitor event syntax does not require a device type or an object label.
Device types
The following device types can initiate the FirstMonitor event:
FirstMonitor
Example
The following rule turns on an LED when the FirstMonitor event occurs.
[First Monitor On]
FM:SLOW -low 'First_Mon_On';
FirstSupervisory event

Description
Use the FirstSupervisory event to program output responses in addition to the common
supervisory responses that a panel activates automatically. The FirstSupervisory event
occurs the first time that any point on a panel or any panel in the same network route
changes to the supervisory state.
Short form: FS
Syntax
FirstSupervisory|FS:
Note: The FirstSupervisory event syntax does not require a device type or an object label.
Device types
The following device types can initiate the FirstSupervisory event:
FirstSupervisory
Example
The following rule turns on an LED when the FirstSupervisory event occurs.
[First Supervisory On]
FS:FAST -low 'First_Sup_On';
FirstTrouble event

Description
Use the FirstTrouble event to program output responses in addition to the common trouble
responses that a panel activates automatically. The FirstTrouble event occurs the first time
that any point on a panel or any panel in the same network route changes to the trouble
state.
Short form: FT
Syntax
FirstTrouble|FT:
Note: The FirstTrouble event syntax does not require a device type or an object label.
Device types
The following device types can initiate the FirstTrouble event:
FirstTrouble
Example
The following rule turns on an LED when the FirstTrouble event occurs.
[First Trouble On]
FT:FAST -low 'First_Trbl_On';
GroundFault event

Description
Use the GroundFault event to activate a rule when a rail module detects a ground fault on
its boxes wiring.
Short form: GNDF
Syntax
GroundFault|GNDF device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The GroundFault event syntax requires that you specify a device type, object label,
or both.
Device types
The following device types can initiate the GroundFault event:
GroundFault
Example
The following rule turns on an LED when the panel detects a ground fault.
[GroundFault Response]
GNDF 'Grnd_Fault_Data_Card_1_01_05':FAST -low 'Ground_Fault_LED';
GuardPatrol event

Description
Use the GuardPatrol event to activate a rule when a patrol guard fails to activate a patrol
tour station at the proper time. Typically, you use the GuardPatrol event to create an output
response for the entire Guard Patrol group.
Short form: GPG
Syntax
GuardPatrol|GPG device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The GuardPatrol event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the GuardPatrol event:
GuardPatrol
Example
The following rule turns on the guard patrol late/out of sequence horn.
[GuardPatrol Response]
GPG 'GUARD_PATROL_Group1':On -high AUD 'Guard_Horn';
InterlockFailure event

Description
Note: The interlock feature is available only for the China (Local and Prop) marketplaces.
Use the InterlockFailure event to activate a rule when controlled equipment, such as damper
actuators and fan on/off controls, fails to operate correctly within the allowed interlock
feedback response time. When the Interlock device activates, the system tracks whether it
operates correctly within a programmed response time using an associated
InterlockFeedback device type.
Short form: INTLCKFAIL
Syntax
InterlockFailure|INTLCKFAIL device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The InterlockFailure event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the InterlockFailure event:
InterlockFeedback
Example
The following rule starts the interlock feedback timer when Damper1 activates, then lights
an LED if Damper1 fails to operate correctly within the given interlock feedback response
time.

[General Interlock LED]

RelayConfirmation INTERLOCK :
Steady 'LED_GEN_INTLCK',
Steady 'LED_GEN_INTLCK_DELAY';
[Interlock Feedback LED]
{Interlock successful - Turn On Interlock Feedback}

Monitor INTERLOCKFEEDBACK :
Steady 'LED_GEN_INTLCK_FEEDBACK',
Off 'LED_GEN_INTLCK_DELAY';
[Interlock Failed LED]
{Interlock Failed – Turn on Interlock Failure LED}

IntLckFail INTERLOCKFEEDBACK : Steady 'LED_GEN_FEEDBACK_FAIL';

LocalAlarm event

Description
Use the LocalAlarm event to activate a rule when a rail module's LocalAlarm pseudo point
changes to the active state.
Short form: LALM
Syntax
LocalAlarm|LALM device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The LocalAlarm event syntax requires that you specify a device type, an object label,
or both.
Device types
The following device types can initiate the LocalAlarm event:
LocalAlarm
Example
The following rule turns on the LED labeled Unprgrmd_Device when the Signature controller
detects an unprogrammed device.
[Unprgrmd Device]
LALM 'Unprogrammed_Device_Data_Card_1_01_05':Steady -low
'Unprgrmd_Device';
LocalMonitor event

Description
Use the LocalMonitor event to activate a rule when a rail module's LocalMonitor pseudo
point goes active.
Short form: LMON
Syntax
LocalMonitor|LMON device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The LocalMonitor event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the LocalMonitor event:
LocalMonitor
Control_Center_ALO
Example
The following rule turns on the LED labeled Reconstct_Line_Data when the Signature
controller is identifying devices on the loop.
[Reconstct Line Data]
LMON 'Reconstct_Line_Data_Card_1_01_05':SLOW -low
'Reconstct_Line_Data';
LocalTrouble event

Description
Use the LocalTrouble event to activate a rule when a monitored circuit internal to a rail
module signals a fault condition.
Short form: LTRB
Syntax
LocalTrouble|LTRB device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The LocalTrouble event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the LocalTrouble event:
LocalTrouble
Example
The following rule turns on the LED labeled Map_fault when the Signature controller detects
a map fault.
[Map Fault]
LTRB 'Map_Fault_Data_Card_1_01_05':FAST -low 'Map_fault';
MaintenanceAlert event

Description
Use the MaintenanceAlert event to activate a rule when a smoke detector reaches an 80%
dirty level.
Short form: MAINT
Syntax
MaintenanceAlert|MAINT device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The MaintenanceAlert event requires that you specify a device type, an object label,
or both.
Device types
The following device types can initiate the MaintenanceAlert event:
GenAlarm
GenSmoke
Smoke
SmokePre
SmokeVfy
Monitor event

Description
Use the Monitor event to activate a rule when any monitor point on a panel or any panel in
the same network route changes to the active state.
Short form: MON
Syntax
Monitor|MON device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The Monitor event requires that you specify a device type, an object label, or both.
Device types
The following device types can initiate the Monitor event:
AND
DamperFeedback
DoorFeedback
FanFeedback
Matrix
Monitor
Example
The following rule turns on fan status LEDs 1-10 when the corresponding fan feedback
circuit changes state.
[Fan Status]
MON FANFB 'Fan<n:1-10>_Status':Steady -low 'Fan<n>_On';
ObjectRunning event

Description
Use the ObjectRunning event to activate a rule when an operator or a rule starts a Check-In
Group, Guard Patrol Group, or Service Group.
Short form: OBJR
Syntax
ObjectRunning|OBJR device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The ObjectRunning event requires that you specify a device type, an object label, or
both.
Device types
The following device types can initiate the ObjectRunning event:
GuardPatrol
ServiceGroup
Example
The following rule turns on a light-emitting diode during the check-in period for the
corresponding Check-In Group.
[Guard Patrol Route 1 in Progress]
OBJR GPG 'GuardPatrol_Route_1' : FAST 'Route_1_LED' ;
PreAlarm event

Description
Use the PreAlarm event to activate a rule when any initiating device or circuit on a panel or
any panel in the same network route changes to the active supervisory state to signal a
possible fire condition.
Short form: PREALM
Syntax
PreAlarm|PREALM device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The PreAlarm event requires that you specify a device type, an object label, or both.
Device types
The following device types can initiate the PreAlarm event:
GenSmoke
SmokePre
R1 event

Description
Use the R1 event to activate a rule when the first phase of the 3-phase reset cycle starts
after an operator presses the Reset switch on the LCD module.
Short form: none
Syntax
R1:
Notes
The R1 event syntax does not require a device type or an object label.
The R1 event is self-restoring. Any outputs activated by this event automatically
restore at the end of the reset cycle.
Device types
The following device types can initiate the R1 event:
R1
Example
The following rule turns on the LED label R1_LED during the 1st phase of the reset cycle.
[Reset 1st Phase]
R1:FAST -low 'R1_LED';
R2 event

Description
Use the R2 event to activate a rule when the second phase of the 3-phase reset cycle
starts. The second phase starts after the first phase finishes.
Short form: none
Syntax
R2:
Notes
The R2 event syntax does not require a device type or an object label.
The R2 event is self-restoring. Any outputs activated by this event automatically
restore at the end of the reset cycle.
Device types
The following device types can initiate the R2 event:
R2
Example
The following rule turns on the LED label R2_LED during the 2nd phase of the reset cycle.
[Reset 2nd Phase]
R2:FAST -low 'R2_LED';
R3 event

Description
Use the R3 event to activate a rule when the third phase of the 3-phase reset cycle starts.
The third phase starts after the second phase finishes.
Short form: none
Syntax
R3:
Notes
The R3 event syntax does not require a device type or an object label.
The R3 event is self-restoring. Any outputs activated by this event automatically
restore at the end of the reset cycle.
Device types
The following device types can initiate the R3 event:
R3
Example
The following rule turns on the LED label R3_LED during the 3rd phase of the reset cycle.
[Reset 3rd Phase]
R3:FAST -low 'R3_LED';
RelayConfirmation event

Description
Use the RelayConfirmation event to activate a rule when an output circuit indicates that its
electrical contacts have switched positions. You can also use the RelayConfirmation event
to verify the operation of the dry contact relay on SIGA–IO and SIGA–MIO modules that
are being used as alarm, active latching, and nonlatching input circuits.
Short form: RLYCFG
Syntax
RelayConfirmation|RLYCFG device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Notes
The RelayConfirmation event syntax requires that you specify a device type or an
object label, or both.
Typically, you use the RelayConfirmation event in applications that require verifying
the proper operation of remote circuits.
Device types
The following device types can initiate the RelayConfirmation event:

2 Stage Signal GenAlarm G_Audible NSCommonTroubleOutput

AccessDoorControl G_Visible NSVisibleOutput
ACFail G_AudibleVisible Power
Audible G_CommonAlarmOutput Pull
CMSNonsupervisedOutput G_CommonMonitorOutput Security
CMSSupervisedOutput G_CommonSupervisoryOutput Smoke
CommonAlarmOutput Guard SmokePre
CommonMonitorOutput Heat SmokeVfy
CommonSupervisoryOutput LocalRelay SprinklerSupervisory
DamperControl LogicalOutput SupervisedOutput
DamperFeedback Monitor Supervisory
DoorControl NonsupervisedOutput Tamper
DoorFeedback NSAudibleOutput Temperature
FanControl NSCommonAlarmOutput Visible
FanFeedback NSCommonMonitorOutput Waterflow
Firephone NSCommonSupervisoryOutput
Gatevalve

SIGA-IO and SIGA-MIO modules with the following device types can initiate the
RelayConfirmation event:

DamperFeedback Monitor Smoke

DoorFeedback NSCommonAlarmOutput SprinklerSupervisory
FanFeedback NSCommonMonitorOutput Supervisory
Gatevalve NSCommonSupervisoryOutput Tamper
GenAlarm NSCommonTroubleOutput Temperature
GuardPatrol Power Waterflow
Heat Pull
Security
Example
The following rule turns on an LED when the corresponding relay's electrical contacts have
switched positions.
[Relay OK]
RLYCFG DOOR 'Door_Control_<n:1-5>':STEADY -low 'Door_Relay<n>_OK';
Reset event

Description
Use the Reset event to activate a rule when an operator presses a switch that executes the
Reset command. The switch can be the Reset switch on the LCD module or a control-
display module switch programmed to execute the Reset command. Typically, you use the
Reset event to activate output responses unique to the Reset function.
Short form: none
Syntax
Reset:
Note: The Reset event syntax does not require a device type or an object label.
Device types
The following device types can initiate the Reset event:
Reset
Example
The following rule turns on the LED labeled Cab2_Reset_Active when an operator presses
a switch programmed to execute the Reset command.
[Cab2 Reset Active]
Reset:FAST -low 'Cab2_Reset_Active';
Security event

Description
Use the Security event to activate a rule when the open input to a device or circuit that
monitors a supervisory or tamper switch closes.
Short form: SEC
Syntax
Security|SEC device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The Security event syntax requires that you specify a device type, an object label, or
both.
Device types
The following device types can initiate the Security event:
Security
Example
The following rule turns on the LED labeled Cab1_Door_Open when an operator opens a
cabinet door guarded by a tamper switch.
[Cabinet Tamper Switch]
SEC SEC 'Cab1_Tmpr_Switch':Steady -low 'Cab1_Door_Open';
SecurityAlarm event

Description
Use the SecurityAlarm event to activate a rule when a security device in an armed partition
goes into alarm. This event occurs when the device has generated a security alarm as the
result of an open or short condition on the circuit.
Short form: SECALM
Syntax
SecurityAlarm|SECALM device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityAlarm event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityAlarm event:
Partition
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Example
The following rule handles a perimeter security breach. It activates for any
SecurityPerimeter device type in the project. The rule notifies the off-site monitoring station
and announces the breach over the PA system.
[Security Perimeter Alarm]
SECALM SecurityPerimeter '*<n:1-9999>':
Fast -High '*SECURITY_ALARM_LED*<n>*',
+Send 'CMS-Account-A' Message "BA<n>",
-Send 'CMS-Account-A' Message "BH<n>",
MsgOn 'Security_Alarm_Message' to 'SecurityChannel_1',
AmpOn '*' to 'SecurityChannel_1';
SecurityAway event

Description
Use the SecurityAway event to activate a rule when a partition is armed and changes state
to Away. You can use this event to provide feedback to users when arming partitions with
control-display modules. You can also use the SecurityAway event to report to a central
monitoring station when an exit timer is not used (the SecurityExitTimer event is
unavailable).
Short form: SECAWAY
Syntax
SecurityAway|SECAWAY device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityAway event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityAway event:
Partition
Examples
This rule turns on an LED when a partition is armed away.
[Security Away LEDs]
SecurityAway 'Partition_<n:1-7>':
Steady -medium 'Away_LED_<n>*';
The next rule transmits a closing message to a central monitoring station.
[Security Closing CMS]
SecurityAway 'Partition_<n:1-7>':
+Send 'CMSAccount<n>' Msg "CL" Confirm 'Confirm_Closing_<n>';
SecurityAwayFail event

Description
Use the SecurityAwayFail event to activate a rule when the ConditionalAway command fails
to arm a partition. You can use the SecurityAwayFail event to provide feedback to the user
when arming partitions with control-display modules. You can also use this event to report
failures when the site is configured for automatic arming using a time control.
Short form: SECAWAYF
Syntax
SecurityAwayFail|SECAWAYF device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityAwayFail event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityAwayFail event:
Partition
Examples
The following rules report the failure of a partition to arm in the away state. The first rule
turns on an LED. The second rule reports to a central monitoring station.
[Security Away Failed LEDs]
SecurityAwayFail 'Partition_<n:1-7>':
Steady -medium 'AwayFail_LED_<n>*';
[Security Closing Failed CMS]
SecurityAwayFail 'Partition_<n:1-7>':
+Send 'CMSAccount<n>' Msg "CI";
SecurityBypassed event

Description
Use the SecurityBypassed event to activate a rule when a security device is bypassed.
When a device is bypassed, alarm events from the device are ignored, but all other events
are monitored.
Short form: SECBP
Syntax
SecurityBypassed|SECBP device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityBypassed event syntax requires that you specify a device type, an
object label, or both.
Device types
The following device types can initiate the SecurityBypassed event:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Example
The following rule reports a bypassed device to the central monitoring station. Note that the
rule uses the +/- operator to report correctly when the bypass is removed.
[Security Bypass]
SecurityBypassed 'SecurityPoint_<n>':
+Send 'CMSAccount' "BB<n>",
-Send 'CMSAccount' "BU<n>";
SecurityDisabled event

Description
Use the SecurityDisabled event to activate a rule when a security device is disabled. When
a device is disabled, all device event messages are ignored.
Short form: SECDIS
Syntax
SecurityDisabled|SECDIS device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityDisabled event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityDisabled event:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Example
The following rule reports a disabled device to the central monitoring station. Note that the
rule uses the +/- operator to report correctly when the device is enabled.
[Security Disable]
SecurityDisabled 'SecurityPoint_<n>':
+Send 'CMSAccount' "BB<n>",
-Send 'CMSAccount' "BU<n>";
SecurityDisarmed event

Description
Use the SecurityDisarmed event to activate a rule when a partition is successfully disarmed.
Short form: SECDARM
Syntax
SecurityDisarmed|SECDARM device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityDisarmed event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityDisarmed event:
Partition
Example
This rule sends a message to the central monitoring station when the site is opened (the
security partition is disarmed).
[Security Disarmed]
SecurityDisarmed Partition '*__<n:1-255>':
+Send 'CMSAccount' "OP<n>";
SecurityDisarmedAlarm event

Description
Use the SecurityDisarmedAlarm event to activate a rule when a device in a disarmed
partition goes into alarm. While in a disarmed partition, the device has generated a security
alarm as the result of an open or short condition on the circuit. This event is typically used
to report alarm states in SecurityDay, SecurityIMonitor, and SecurityPMonitor device types.
Short form: SECDISALM
Syntax
SecurityDisarmedAlarm|SECDISALM device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityDisarmedAlarm event syntax requires that you specify a device type, an
object label, or both.
Device types
The following device types can initiate the SecurityDisarmedAlarm event:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Examples
This rule sends a message to the central monitoring station for an access point that should
not be triggered during the day. The rule also turns on an LED and activates a command list
that notifies on-site guards.
[Security Disarmed SecurityDay Alarms]
SecurityDisarmedAlarm SecurityDay '*__<n:1-9999>*':
Slow -Low '*Security_Alarm_LED*<n>*',
+Send 'CMSAccount' "BT<n>",
-Send 'CMSAccount' "BJ<n>",
+Activate 'Notify_Guards';
The next rule applies to an access point in the interior of a partition that needs to be
monitored even when the partition is disarmed. An example would be a stock room door.
The rule notifies on-site guards, but does not send a message to the central monitoring
station.
[Security Disarmed SecurityIMonitor Alarms]
SecurityDisarmedAlarm SecurityIMonitor '*__<n:1-9999>*':
Fast -High '*SECURITY_ALARM_LED*<n>*',
+Activate 'Notify_Guards';
The last rule applies to an access point on the perimeter of a partition that needs to be
monitored even when the partition is disarmed. An example would be an emergency-only
exit. The rule notifies the guards, but does not call the central monitoring station.
[Security Disarmed SecurityIMonitor Alarms]
SecurityDisarmedAlarm SecurityPMonitor '*__<n:1-9999>*':
Fast -High '*SECURITY_ALARM_LED*<n>*',
+Activate 'Notify_Guards';
SecurityDisarmedFault event

Description
Use the SecurityDisarmedFault event to activate a rule when a device in a disarmed
partition goes into fault. While in a disarmed partition, the device has a problem that would
impede the reporting of a security alarm or tamper.
Short form: SECDISFLT
Syntax
SecurityDisarmedFault|SECDISFLT device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityDisarmedFault event syntax requires that you specify a device type, an
object label, or both.
Device types
The following device types can initiate the SecurityDisarmedFault event:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Examples
This rule sends a security trouble message to a central monitoring station when any security
device in a disarmed partition goes into fault. The rule also activates a command list to
notify the on-site security staff, and plays a security alarm message.
[Security Disarmed Fault]
SecurityDisarmedFault '*__<n:1-9999>*':
Slow -Low '*Security_Fault_LED*<n>*',
+Send 'CMSAccount' "BT<n>",
-Send 'CMSAccount' "BJ<n>",
+Activate 'Notify_Guards',
MsgOn 'Security_Alarm_Message' to 'SecurityChannel_1',
AmpOn '*' to 'SecurityChannel_1';
The next rule is similar to the first, but sends a message to a pager, rather than to a central
monitoring station.
[Security Disarmed Fault]
SecurityDisarmedFault '*__<n:1-9999>*':
Slow -Low '*Security_Fault_LED*<n>*',
+Send 'ManagersPager' "Security Alarm$(CR)$(LOCATION:1-42)",
+Activate 'Notify_Guards',
MsgOn 'Security_Alarm_Message' to 'SecurityChannel_1',
AmpOn '*' to 'SecurityChannel_1';
SecurityDisarmedTamper event

Description
Use the SecurityDisarmedTamper event to activate a rule when a device in a disarmed
partition is tampered with. While in a disarmed partition, the device has generated a
security alarm as the result of a tamper switch being tripped.
Short form: SECDISTAMP
Syntax
SecurityDisarmedTamper|SECDISTAMP device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityDisarmedTamper event syntax requires that you specify a device type,
an object label, or both.
Device types
The following device types can initiate the SecurityDisarmedTamper event:
Partition
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Example
This rule sends a burglary trouble message to a central monitoring station when any
security device in a disarmed partition is tampered with. The rule also activates a command
list to notify on-site security staff.
[Security Disarmed Tamper]
SecurityDisarmedTamper '*__<n:1-9999>*':
Slow -Low '*SECURITY_TAMPER_LED*<n>*',
+Send 'CMSAccount' "BT<n>",
-Send 'CMSAccount' "BJ<n>",
+Activate 'Notify_Guards',
MsgOn 'Security_Alarm_Message' to 'SecurityChannel_1',
AmpOn '*' to 'SecurityChannel_1';
SecurityEntryTimer event

Description
Use this event to activate a rule when the entry timer of a partition starts running.
Short form: SECENTMR
Syntax
SecurityEntryTimer|SECENTMR device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityEntryTimer event syntax requires that you specify a device type, an
object label, or both.
Device types
The following device types can initiate the SecurityEntryTimer event:
Partition
Example
This rule controls a KPDISP Keypad Display sounder. When the door is opened the
KPDISP sounder is turned on until the partition is successfully disarmed.
[Security Entry Buzzer]
SecurityEntryTimer 'Lobby':
On -high 'Keypad_Buzzer_01';
SecurityExitTimer event

Description
Use this event to activate a rule when the exit timer of a partition starts running.
Short form: SECEXTMR
Syntax
SecurityExitTimer|SECEXTMR device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityExitTimer event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityExitTimer event:
Partition
Examples
The following rules transmit messages that a closing (partition arming) is in progress. The
first rule sends the message to a central monitoring station, while the second rule sends the
message to a pager. Both rules play a closing message on the audio system.
[Security Exit Timer]
SecurityExitTimer Partition '*__<n:1-255>':
MsgOn 'Security_Exit_Message' to 'SecurityChannel_2',
AmpOn '*' to 'SecurityChannel_2',
+Send 'CMSAccount' "CL<n>" Confirm 'Confirm_Closing';
[Security Exit Timer]
SecurityExitTimer Partition '*':
MsgOn 'Security_Exit_Message' to 'SecurityChannel_2',
AmpOn '*' to 'SecurityChannel_2',
+Send 'ManagersPager' "Closing$(CR)$(LOCATION:1-42)";
SecurityFault event

Description
Use the SecurityFault event to activate a rule when a security device in an armed partition
goes into fault. The device has a problem that would impede the reporting of a security
alarm or tamper.
Short form: SECFLT
Syntax
SecurityFault|SECFLT device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityFault event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityFault event:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Examples
The following rules send security alarm messages when a security device in an armed
partition goes into fault. The first rule sends the message to a central monitoring station,
while the second rule sends the message to a pager. Both rules play an alarm message on
the audio system.
[Security Fault]
SecurityFault '*_<n:1-9999>*':
Fast -High '*Security_Fault_LED*<n>*',
+Send 'CMSAccount' "BA<n>",
-Send 'CMSAccount' "BH<n>",
MsgOn 'Security_Alarm_Message' to 'SecurityChannel_1',
AmpOn '*' to 'SecurityChannel_1';
[Security Fault]
SecurityFault '*_<n:1-9999>*':
Fast -High '*Security_Offnormal_LED*<n>*',
+Send 'ManagersPager' "Security Alarm$(CR)$(LOCATION:1-42)",
MsgOn 'Security_Alarm_Message' to 'SecurityChannel_1',
AmpOn '*' to 'SecurityChannel_1';
SecurityMaintenance event

Description
Use the SecurityMaintenance event to activate a rule when a security device requires
maintenance. The device has a fault that would not impede the reporting of a security
alarm. The partition containing the device can be either armed or disarmed.
Short form: SECMAINT
Syntax
SecurityMaintenance|SECMAINT device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityMaintenance event syntax requires that you specify a device type, an
object label, or both.
Device types
The following device types can initiate the SecurityMaintenance event:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Examples
The following rules transmit a "door left open" message when a door contact indicates that
a door has been left open, whether or not the partition is armed. The first rule sends the
message to a central monitoring station. The second rule sends the message to a pager.
[Security Maintenance]
SecurityMaintenance 'Security*Door*<n:1-9999>*':
Slow -Low '*SECURITY_MAINTENANCE_LED*<n>*',
+Send 'CMSAccount' "DM<n>",
-Send 'CMSAccount' "DH<n>";
[Security Maintenance]
SecurityMaintenance 'Security*Door*':
Slow -Low '*SECURITY_MAINTENANCE_LED*<n>*',
+Send 'ManagersPager' "Security Maintenance$(CR)$(LOCATION:1-
42)";
SecurityStay event

Description
Use the SecurityStay event to activate a rule when a partition is armed and changes state
to Stay. You can use this event to provide feedback to users when arming partitions with
control-display modules. You can also use the SecurityStay event to report to a central
monitoring station.
Short form: SECSTAY
Syntax
SecurityStay|SECSTAY device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityStay event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityStay event:
Partition
Examples
This rule turns on an LED when a partition is armed stay.
[Security Stay LEDs]
SecurityStay 'Partition_<n:1-7>':
Steady -medium 'Stay_LED_<n>*';
This rule sends a partially armed message to a central monitoring station.
[Security Stay Partial Arm]
SecurityStay 'Partition_<n:1-7>':
+Send 'CMSAccount<n>' Msg "CG" Confirm 'Confirm_Closing_<n>';
SecurityStayFail event

Description
Use the SecurityStayFail event to activate a rule when the ConditionalStay command fails to
arm a partition. You can use the SecurityStayFail event to provide feedback to the user
when arming partitions with control-display modules. You can also use this event to report
failures when the site is configured for automatic arming using a time control.
Short form: SECSTAYF
Syntax
SecurityStayFail|SECSTAYF device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityStayFail event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityStayFail event:
Partition
Example
The following rules report the failure of a partition to arm in the stay state. The first rule
turns on an LED. The second rule reports to a central monitoring station.
[Security Stay Failed LEDs]
SecurityStayFail 'Partition_<n:1-7>':
Steady -medium 'StayFail_LED_<n>*';
[Security Closing Failed CMS]
SecurityAwayFail 'Partition_<n:1-7>':
+Send 'CMSAccount<n>' Msg "CI";
SecurityTamper event

Description
Use the SecurityTamper event to activate a rule when the tamper switch on a security
device is activated.
Short form: SECTAMP
Syntax
SecurityTamper|SECTAMP device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SecurityTamper event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the SecurityTamper event:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Examples
The following rules send security alarm messages when a security device in an armed
partition is tampered with. The first rule sends the message to a central monitoring station,
while the second rule sends the message to a pager. Both rules play an alarm message on
the audio system.
[Security Tamper]
SecurityTamper '*__<n:1-9999>*':
Fast -High '*SECURITY_TAMPER_LED*<n>*',
+Send 'CMSAccount' "BA<n>",
-Send 'CMSAccount' "BH<n>",
MsgOn 'Security_Alarm_Message' to 'SecurityChannel_1',
AmpOn '*' to 'SecurityChannel_1';
[Security Tamper]
SecurityTamper '*':
Fast -High '*SECURITY_TAMPER_LED*<n>*',
+Send 'ManagersPager' "Security Alarm$(CR)$(LOCATION:1-42)",
MsgOn 'Security_Alarm_Message' to 'SecurityChannel_1',
AmpOn '*' to 'SecurityChannel_1';
ServiceDevice event

Description
Use the ServiceDevice event to activate a rule when an authorized service technician
activates a device in a service group under test. The ServiceDevice event is used to
program individual responses for each device in the service group.
Short form: SERV
Syntax
ServiceDevice|SERV device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Notes
The ServiceDevice event syntax requires that you specify a device type, an object
label, or both.
Outputs activated in response to a ServiceDevice event stay latched until the service
test is canceled.
Device types
The following device types can initiate the ServiceDevice event:

2 Stage Signal DoorFeedback SecurityInterior

24VRiser FanControl SecurityPerimeter
ACFail FanFeedback SecurityPMonitor
Audible Firephone Smoke
AudioRiser Gatevalve SmokePre
AuxPowerSupply GenAlarm SmokeVfy
CMSNonsupervisedOutput GenSmoke SprinklerSupervisory
CMSSupervisedOutput Guard StageOne
COAlarm Heat StageTwo
COMonitor Isolator SupervisedOutput
COSupervisory Monitor Supervisory
CommonAlarmOutput PhoneRiser Tamper
CommonMonitorOutput Power Temperature
CommonSupervisoryOutput Pull Visible
DamperControl Security Waterflow
DamperFeedback Security24Hour
DoorControl SecurityDay
SecurityIMonitor
Example
The following rule turns on an LED when the corresponding device under test is activated.
[Pull Test Response]
SERV PULL 'IDC_Ckt<n:1-8>':FAST 'IDC_CKT<n>_OK';
ServiceGroup event

Description
Use the ServiceGroup event to activate a rule when service technician activates a device
that is part of a Service group under test. The ServiceGroup event is used to program a
response in order to perform a one-man test.
Short form: SG
Syntax
ServiceGroup|SG device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Notes
The ServiceGroup event syntax requires that you specify a device type, an object
label, or both.
The ServiceGroup event is self-restoring. You must include a delay command at the
end of a rule activated by the ServiceGroup event with a delay value sufficient to
perform the one-man test
Device types
The following device types can initiate the ServiceGroup event:
ServiceGroup
Example
The following rule activates the group response for performing a one-man test that lasts
approximately 5 minutes.
[Service Group Response]
SG 'SERVICE_GROUP_<n:1-8>':
On VIS 'LVL<n>_Strobes',
DLYR 300;
ServiceGroupActive event

Description
Use the ServiceGroupActive event to activate a rule when an operator starts a test on a
Service Group from the LCD module.
Short form: SGA
Syntax
ServiceGroupActive|SGA:
Note: The ServiceGroupActive event syntax does not require a device type or an object
label.
Device types
The following device types can initiate the ServiceGroupActive event:
ServiceGroupActive
Example
The following rule turns on an LED when someone starts a test on a Service Group.
[ServiceGroup Active Response]
SGA:Steady 'ServGroup_Active';
SignalSilenceInhibit event

Description
Use the SignalSilenceInhibit event to program an output response that activates on the first
alarm event when the alarm signal silence inhibit feature is enabled (Signal Silence Inhibit
option set for a value greater than zero). During this time the system cannot be silenced or
reset. Output responses typically programmed using this event include:
Turning on an LED to indicate that the alarm signal silence inhibit feature is active
and has temporarily disabled the Alarm Silence and Reset switches on the LCD.
Temporarily disabling control-display module switches programmed as Alarm Silence
and Reset controls
Short form: SSINH
Syntax
SignalSilenceInhibit | SSINH:
Note: The SignalSilenceInhibit event syntax does not require a device type or an object
label.
Device types
The following device types can initiate the SignalSilenceInhibit event:
SignalSilenceInhibit
Example
The following rule turns on an LED while the alarm signal silence inhibit timer is active.
[Automatic Signal Silence Inhibit Active]
SSINH : Steady 'Alarm_Silence_Inhibit_Active' ;
SprinklerSupervisory event

Description
Use the SprinklerSupervisory event to activate a rule when the open input to a device or
circuit that supervises a component of the sprinkler system closes. Typically, you use the
SprinklerSupervisory event to provide local and off-site notification of sprinkler system
status.
Short form: SPSUP
Syntax
SprinklerSupervisory|SPSUP device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Notes
The SprinklerSupervisory event syntax requires that you specify a device type or an
object label, or both.
The Supervisory event can be used with a greater number of device types and
should be used in place of the SprinklerSupervisory event. Any existing rules using
the SprinklerSupervisory event will still function properly and should not be rewritten.
Device types
The following device types can initiate the SprinklerSupervisory event:
Gatevalve
Power
SprinklerSupervisory
Supervisory
Tamper
Temperature
Example
The following rule turns on an LED when the gatevalve monitoring circuit changes to the
active state.
[Gatevalve Tamper Detect]
SPSUP TAMP 'Main_Valve':Steady -low 'Main_Valve_Alert';
Startup event

Description
Use the Startup event to activate a rule when the panel is initially powered up or when an
operator initiates the Restart command from the LCD module. Typically, you use the Startup
event to program the initial operating state of system components or functions.
Short form: STUP
Syntax
Startup|STUP:
Note: The Startup event syntax does not require a that you specify a device type or an
object label.
Device types
The following device types can initiate the Startup event:
Startup
Example
The following rule disables the HVAC switches at startup.
[Startup Response]
STUP:Disable -low SW '*HVAC*';
StationActivation event

Description
Use the StationActivation event to activate a rule when a patrol guard activates a patrol tour
station. Typically, you use the StationActivation event to monitor a patrol guard's progress
through the tour.
Short form: STACT
Syntax
StationActivation|STACT device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The StationActivation event syntax requires that you specify a device type, an object
label, or both.
Device types
The following device types can initiate the StationActivation event:
Guard
Example
The following rule turns on an LED when the corresponding patrol station is activated.
[Guard Station OK]
STACT 'Station<n:1-10>':Steady -low 'Station<n>_OK';
Supervisory event

Description
Use the Supervisory event to activate a rule when any point on a panel or any panel in the
same network route changes to the supervisory state.
Short form: SUP
Syntax
Supervisory|SUP device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Notes
The Supervisory event syntax requires that you specify a device type or an object
label, or both.
The Supervisory event can be used with a greater number of device types and
should be used in place of the SprinklerSupervisory event. Any existing rules using
the SprinklerSupervisory event will still function properly and need not be rewritten.
Device types
The following device types can initiate the Supervisory event:
AND
Gatevalve
Matrix
Power
SprinklerSupervisory
Supervisory
Tamper
Temperature
Example
The following rule turns on an LED when the AND group changes to the supervisory state.
[ANDGroup 1 in Sup State]
SUP AND 'AND_GROUP1' : Steady 'ANDGroup_1_Sup' ;
Switch event

Description
Use the Switch event to activate a rule when an operator presses a control-display module
switch.
Short form: SW
Syntax
Switch|SW device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Notes
The Switch event syntax requires that you specify a device type, an object label, or
both
Any commands listed in an output statement activated by the Switch event are
automatically assigned the high priority level
Device types
The following device types can initiate the Switch event:
Switch
Example
The following rule activates the Alarm Silence function on the panel labeled Cab2 when an
operator presses the switch labeled C2_AlarmSil_On.
[Alarm Silence Cntrl]
SW 'C2_AlarmSil_On':AS 'Cab2';
SystemMonitor event

Description
Use the SystemMonitor event to activate a rule when one of the system function pseudo
points activates. System function pseudo points can be activated from the four LCD key
functions, a momentary switch, or FireWorks. If using a momentary switch, or FireWorks
you must use the SystemFunction command to activate a SystemMonitor event.
If the system function pseudo point is assigned to one of the four LCD key functions, you do
not need to use SytemFunction command to activate the SystemMonitor event. The four
LCD key functions automatically activate the SystemMonitor event without using the
SystemFunction command.
Short form: SMON
Syntax
SystemMonitor|SMON device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The SystemMonitor event requires that you specify a device type, an object label, or
both.
Device types
The following device types can initiate the SystemMonitor event:
SystemMonitor
Example 1
The following rules disable all smoke detectors on all panels when an operator presses the
switch labeled System_Function_Switch_1.
Switch 'System_Function_Switch 1': SYSFUNC 1 'All_Cabinets';
SMON 'System_Function_1_Response_00_00': Disable Smoke;
Example 2
The following rule disables all smoke detectors on all panels when an operator presses the
LCD key function configured as System Function 1. The LCD key function does not require
the use of the SystemFunction command to activate the SystemMonitor event; the LCD key
function automatically activates the SystemMonitor event without using the SystemFunction
command.
SMON 'System_Function_1_Response_00_00': Disable Smoke;
TimeControl event

Description
Use the TimeControl event to activate a rule when a specific combination of day, date,
and/or time of day occurs. Typically, you use the TimeControl event to program output
responses that hold and release doors or change smoke detector sensitivity.
Short form: TIME
Syntax
TimeControl|TIME device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Notes
The TimeControl event syntax requires that you specify a device type, an object
label, or both.
Use the SysTime command in conjunction with the TimeControl event to program
daylight savings time changes. For a list of Daylight Saving days see Daylight saving
time around the world.
Device types
The following device types can initiate the TimeControl event:
TimeControl
Example
The following rule activates the alternate sensitivity and alternate alarm verification settings
according to the time control labeled Mon_Fri_Non_Work_Hrs.
[Alt Sensitivity On]
TIME 'Mon_Fri_Non_Work_Hrs' : ALTSON;
Trouble event

Description
Use the Trouble event to create a rule that runs when a point in the system signals a fault
condition. Typically, these are points that are external to the panel, but logic groups and
some pseudo points can also be used.
Short form: TRB
Syntax
Trouble|TRB device_type 'object_label':
Where:
device_type specifies the device type of the device initiating the event
object_label specifies the label of the device initiating the event
Note: The Trouble event syntax requires that you specify a device type, an object label, or
both.
Device types
The following device types can initiate the Trouble event:

2 Stage Signal FanControl NSCommonTroubleOutput

24VRiser FanFeedback PanelCommFault
ACFail Firephone PhoneRiser
AND Gatevalve Power
Audible GenAlarm G_Audible Pull
AudioRiser G_Visible RebootFault
AuxPowerSupply G_AudibleVisible Security
CardDBIncompat G_CommonAlarmOutput ServiceDeviceSupervision
CMSNonsupervisedOutput G_CommonMonitorOutput Smoke
CMSSupervisedOutput G_CommonSupervisoryOutput SmokePre
COAlarm GenSmoke SmokeVfy
COMonitor Guard SprinklerSupervisory
COSupervisory Heat StageOne
CommFailure Isolator StageTwo
CommonAlarmOutput LoopControllerResetExt SupervisedOutput
CommonMonitorOutput Matrix Supervisory
CommonSupervisoryOutput MComAccount Tamper
DamperControl Monitor TaskFailure
DamperFeedback NonsupervisedOutput Temperature
DoorControl NSCommonAlarmOutput Visible
DoorFeedback NSCommonMonitorOutput Waterflow
ExtDBIncompatibility NSCommonSupervisoryOutput Zone
Failsafe
Example
The following rule turns on a relay module when any point on the panel goes into trouble.
[Trouble Response]
TRB '*' : On NSO 'Trouble_Relay' ;
TwoStageTimerActive event

Description
Use the TwoStageTimerActive event to activate a rule when a panel's two-stage alarm
timer starts counting down. Typically, you use the TwoStageTimerActive event in
jurisdictions that require some time delay before sounding a general alarm in order to verify
the source of the alarm.
Short form: 2STAGEA
Syntax
TwoStageTimerActive|2STAGEA:
Notes
The TwoStageTimerActivation event syntax does not require a device type or an
object label.
The project parameters setting determines the two-stage timer's count value.
Device types
The following device types can initiate the TwoStageTimerActivation event:
TwoStageTimerActive
Example
The following rule turns on an LED when the panel's two-stage timer starts.
[2Stage Timer Active]
2STAGEA:FAST -low '2Stage_Active';
TwoStageTimerExpiration event

Description
Use the TwoStageTimerExpiration event to activate a rule when a panel's two-stage alarm
timer expires. Typically, you use the TwoStageTimerExpiration event to sound a general
alarm in jurisdictions that require some time delay in order to verify of the source of the
alarm.
Short form: 2STAGETO
Syntax
TwoStageTimerExpiration|2STAGETO:
Notes
The TwoStageTimerExpiration event syntax does not require a device type or an
object label.
The project parameters setting determines the two-stage timer's count value.
Device types
The following device types can initiate the TwoStageTimerExpiration event:
TwoStageTimerExpiration
Example
The following rule turns on an LED when the panel's two-stage timer expires.
[2Stage Timer Expire]
2STAGETO:FAST -low '2Stage_Expire';
Activate command

Description
Use the Activate command to activate a command list. Command lists do not have states.
Activating a command list causes its Activation rules to execute once in the activation
direction. Restoring a command list causes its Activation rules to execute once in the
restoral direction.
Short form: ACT
Syntax
[+|–]Activate|ACT device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
device_type specifies the device type of the command list you want to activate
object_label specifies the label of the command list to activate
Device types
The following device types respond to the Activate command:
AND
CmdList
Example
The following rule activates the command list labeled OnAlarmCmdList when the rule
activates, and activates OnRestoreCmdList when the rule restores.
[Smoke Alarm Response]
Alarm SMK 'Level_<n:0-64>_Smk':
On AUD 'Level_<n>_Horn',
On VIS 'Level_<n>_Strobe',
+Activate 'OnAlarmCmdList',
-Activate 'OnRestoreCmdList';
ActivateRemoteReadLock command
Use the ActivateRemoteReadLock command to disable IP read communications between
the CU and the panel. The default setting is to allow read communications (remote read
capability is unlocked).
If you are using IP connectivity, you may want to prohibit IP communications with the panel
on a normal basis to help prevent "denial of service" attacks from affecting the performance
of the panel. You can then enable panel IP communications as needed by using the
RestoreRemoteReadLock command.
Short form: ARRL
Syntax
[+|–]ActivateRemoteReadLock|ARRL 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
routing_label specifies the label of the network routing group containing the panels
for which you want to lock all remote reads.
Device types
The following device types respond to the ActivateRemoteReadLock command:
None
Example
The following rule blocks read capability between the CU and all cabinets, when an
operator presses the Activate Remote Read Lock switch.
[Remote Read OFF for all cabs]
SW 'Activate Remote Read Lock' : ARRL 'All Cabinets';
ActivateRemoteWriteUnlock command
Use the ActivateRemoteWriteUnlock command to allow write capability using IP
communications between the CU and the panel. The default setting does not allow write
communications (remote write capability is locked).
If you are using IP connectivity, you can disable IP communications with the panel on a
normal basis to block messages that write information to the panel. (This is a security
measure that can help address UL's requirement for programming a protected-premises
unit.) You can disable panel write communications as needed by using the
RestoreRemoteWriteUnlock command.
Note: After 15 minutes with no write activity, the panel automatically returns to the default,
locked state.
Short form: ARWU
Syntax
[+|–]ActivateRemoteWriteUnlock|ARWU 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
routing_label specifies the label of the network routing group containing the panels
for which you want to allow remote write operations.
Device types
The following device types respond to the ActivateRemoteWriteUnlock command:
None
Example
The following rule allows write capability between the CU and all cabinets, when an
operator presses the Activate Remote Write Unlock switch.
[Remote Write ON for all cabs]
SW 'Activate Remote Write Unlock' : ARWU 'All Cabinets';
Active1Test command

Description
Use the Active1Test command to activate nonalarm Signature devices for verification
testing. For alarm Signature devices use AlarmTest command. This command requires a 3-
SSDC1 or 3-SDDC1 loop controller and firmware version 3.4 or later.
Note: The Active1Test command puts the device into an active condition and activates its
programmed output responses.
Short form: A1TST
Syntax
[+|–]Active1Test|A1TST device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the nonalarm signature devices you want to
test
object_label specifies the label of the nonalarm signature devices to test
Device types
The following device types respond to the Active1Test command:

ACFail Guard SecurityInterior

DamperFeedback Monitor SecurityPerimeter
DoorFeedback Power SecurityPMonitor
FanFeedback Security SprinklerSupervisory
Firephone Security24Hour Supervisory
Gatevalve SecurityDay Tamper
SecurityIMonitor Temperature
Example
The following rule activates the Active1Test function on floor 1 nonalarm Signature devices
when an operator presses the switch labeled Fl1_Active1Test_On.
[Fl1 Active1Test]
SW 'Fl1_Active1Test_On': A1TST '*' ;
Active2Test command

Description
Use the Active2Test command to activate Signature security devices with a security tamper
event. This command requires a 3-SSDC1 or 3-SDDC1 loop controller and firmware version
3.4 or later.
Note: The Active2Test command puts the device into a security tamper event and activates
its programmed output responses.
Short form: A2TST
Syntax
[+|–]Active2Test|A2TST device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the signature security devices you want to
test
object_label specifies the label of the signature security devices to test
Device types
The following device types respond to the Active2Test command:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Example
The following rule activates the Active2Test function on floor 1 motion detectors when an
operator presses the switch labeled Fl1_Active2Test_On.
[Fl1 Active2Test]
SW 'Fl1_Active2Test_On': A2TST 'Fl1_Motion*';
AlarmSilence command

Description
Use the AlarmSilence command to program a momentary switch on a control-display
module to activate the Alarm Silence function. Activating the Alarm Silence function
temporarily turns off any active alarm notification appliance circuits on the local panel or on
all the panels in the same network routing group.
Short form: AS
Syntax
[+|–]AlarmSilence|AS 'cabinet_label';
— or —
[+|–]AlarmSilence|AS 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
cabinet_label specifies the panel whose Alarm Silence function you want to activate
routing_label specifies the label of the network routing group containing the panels
whose Alarm Silence function you want to activate
Notes
The AlarmSilence command syntax only requires that you specify a cabinet label or
a routing label
You must configure the switch used to execute the AlarmSilence command as a
momentary switch
Project parameter settings determine whether the Alarm Silence function silences
visible notification appliance circuits automatically
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label
Device types
The following device types respond to the AlarmSilence command:
AlarmSilence
CommonAlarmOutput
Example
The following rule activates the Alarm Silence function on the panel labeled Cab2 when an
operator presses the switch labeled C2_AlarmSil_On.
[Alarm Silence Cntrl]
SW 'C2_AlarmSil_On': AS 'Cab2';
AlarmTest command

Description
Use the AlarmTest command to place a logical address for an SDU device into alarm for
testing. This command requires a 3-SSDC1 or 3-SDDC1 loop controller and microcode
version 3.4 or later.
Note: You can also perform this function from the LCD without having to write a rule.
Short form: ALMTST
WARNING: The AlarmTest command puts the device into an alarm condition and activates
its programmed alarm responses.
Syntax
[+|–]AlarmTest|ALMTST device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the signature device you want to test.
object_label specifies the label of the signature device to test.
Device types
The following device types respond to the AlarmTest command:
COAlarm Smoke StageOne
GenAlarm SmokePre StageTwo
Heat SmokeVfy Waterflow
Pull
Example
The following rule activates the AlarmTest function on all Signature smoke devices on floor 1
when an operator presses the switch labeled FL1_AlarmTest_Smk.
[AlarmTest Smk FL1]
SW 'FL1_AlarmTest_Smk' : ALMTST 'FL1_Smk*' ;
AlternateLanguage command

Description
Use the AlternateLanguage command to change the language used to display text on the
LCD module. By programming a control-display module switch to execute the
AlternateLanguage command, an operator can switch between the primary language setting
and the secondary language setting. You can also use a time control to toggle the language
settings without operator intervention.
Short form: ALTL
Syntax
[+|–]AlternateLanguage|ALTL;
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
Notes
The AlternateLanguage command syntax does not require that you specify a device
type or an object label.
You must configure the switch used to execute the AlternateLanguage command as
a momentary switch.
The AlternateLanguage command only switches languages on the panel that
contains the switch programmed to execute the command.
Device event messages are not affected by the Language settings and are
displayed as entered in the SDU. You can customize the SDU to change the target
language used for entering device event messages.
Device types
The following device types respond to the AlternateLanguage command:
AlternateLanguage
Example
The following rule changes the language displayed on the LCD module when an operator
presses the control-display module switch labeled Cab1_Alt_Lang.
[Alt Language On]
SW 'Cab1_Alt_Lang' : ALTL ;
AlternateMsgOff command

Description
Use the AlternateMsgOff command to change event message routing properties to their
primary settings when the alternate settings are active.
The AlternateMsgOff command changes event message routing properties on selected
panels in the system or in a group of panels.
Short form: ALTMOFF
Syntax
[+|–]AlternateMsgOff|ALTMOFF 'cabinet_label';
— or —
[+|–]AlternateMsgOff|ALTMOFF 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
cabinet_label specifies the name of the panels to which the command is directed
routing_label specifies the name of the network route to which the command is
directed
Notes
The AlternateMsgOff command syntax does not require that you specify a device
type.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
The AlternateMsgOff command is typically used with a control-display module
switch to manually override the alternate message routing settings.
Device types
The following device types respond to the AlternateMsgOff command:
AlternateMsg
Example
The following rule activates the primary message routing settings on every panel on the
network when an operator presses the switch labeled Cab1_AltMsg_Off.
[Activate Pri Msg Route]
SW 'Cab1_AltMsg_Off': ALTMOFF 'All_Cabinets';
AlternateMsgOn command

Description
Use the AlternateMsgOn command to change event message routing properties to their
alternate settings when the primary settings are active.
The AlternateMsgOn command changes event message routing properties on selected
panels in the system or in a group of panels.
Short form: ALTMON
Syntax
[+|–]AlternateMsgOn|ALTMON 'cabinet_label';
— or —
[+|–]AlternateMsgOn|ALTMON 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
cabinet_label specifies the name of the panels to which the command is directed
routing_label specifies the name of the network routing group to which the command
is directed
Notes
The AlternateMsgOn command syntax does not require that you specify a device
type.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
The AlternateMsgOn command is typically used with a time control to automatically
change the routing settings and with a toggle switch to manually override the primary
settings.
Device types
The following device types respond to the AlternateMsgOn command:
AlternateMsg
Example
The following rule activates the alternate message routing settings on every panel on the
network when an operator presses the switch labeled Cab1_AltMsg_On.
[Activate Alt Msg Route]
SW 'Cab1_AltMsg_On' : ALTMON 'All_Cabinets' ;
AlternateSensingOff command

Description
Use the AlternateSensingOff command to return smoke detector sensitivity, alarm verify,
prealarm, and operation settings to their primary values from their alternate values. Note:
There are no alternate values for CO detectors.
The AlternateSensingOff command changes these options on every panel in the system.
Tip: Use the RemoteAltSensingOff command to return smoke detector sensitivity, alarm
verify, prealarm, and operation options to their primary values from their alternate values on
selected panels or on a group of panels.
Short form: ALTSOFF
Syntax
[+|–]AlternateSensingOff|ALTSOFF;
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. If you do not specify + or – , the system activates the
command when the rule activates and restores when the rule restores.
Notes
The AlternateSensingOff command syntax does not require that you specify a
device type or an object label.
The AlternateSensingOff command is typically used with a control-display module
switch to manually override the alternate settings.
Device types
The following device types respond to the AlternateSensingOff command:
AlternateSensitivityMode
Example
The following rule overrides the smoke detector alternate settings and restores the primary
settings when an operator presses the switch labeled Alt_Sensing_Off.
[Alt Sensing Off]
SW 'Alt_Sensing_Off' : ALTSOFF ;
AlternateSensingOn command

Description
Use the AlternateSensingOn command to change detector sensitivity, alarm verify,
prealarm, and operation properties to their alternate settings, when their primary settings
are active. For example, you may use these alternate settings at night when the building is
unoccupied. The AlternateSensingOn command changes these options on every panel in
the system. Note: There are no alternate settings for CO detectors.
Short form: ALTSON
Tip: Use the RemoteAltSensingOn command to change to alternate modes for detector
sensitivity, alarm verify, prealarm, and operation options on selected panels or on a group of
panels.
Syntax
[+|–]AlternateSensingOn|ALTSON;
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
Notes
The AlternateSensingOn command syntax does not require that you specify a device
type or an object label.
The AlternateSensingOn command is typically used with a time control to
automatically change smoke detector settings or with a control-display module
switch to manually override them.
Device types
The following device types respond to the AlternateSensingOn command:
AlternateSensitivityMode
Example
The following rule activates the alternate smoke detector settings when the time control
labeled Mon_Fri_Non_Work_Hrs goes active.
[Alt Sensing On]
TIME 'Mon_Fri_Non_Work_Hrs' : ALTSON ;
AlternateSensitivityOff command

Description
Use the AlternateSensitivityOff command to change smoke detector Sensitivity, Alarm
Verify, and Pre Alarm properties to their primary settings when their alternate settings are
active.
The AlternateSensitivityOff command changes smoke detector Sensitivity, Alarm Verify, and
Pre Alarm properties on every panel in the system.
Short form: ALTSOFF
Tip: Use the RemoteAltSensingOff command to restore normal smoke detector Sensitivity,
Alarm Verify, Pre Alarm, and Operation properties on selected panels or on a group of
panels.
Syntax
[+|–]AlternateSensitivityOff|ALTSOFF;
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
Notes
The AlternateSensitivityOff command syntax does not require that you specify a
device type or an object label.
The AlternateSensitivityOff command is typically used with a control-display module
switch to manually override the alternate settings.
Device types
The following device types respond to the AlternateSensitivityOff command:
AlternateSensitivity
Example
The following rule overrides the smoke detector alternate settings and restores the primary
settings when an operator presses the switch labeled Alt_Sens_Off.
[Alt Sensitivity Off]
SW 'Alt_Sens_Off' : ALTSOFF ;
AlternateSensitivityOn command

Description
Use the AlternateSensitivityOn command to change smoke detector Sensitivity, Alarm
Verify, and Pre Alarm properties to their alternate settings when their primary settings are
active.
The AlternateSensitivityOn command changes smoke detector Sensitivity, Alarm Verify, and
Pre Alarm properties on every panel in the system.
Short form: ALTSON
Tip: Use the RemoteAltSensitivityOn command to change smoke detector Sensitivity, Alarm
Verify, and Pre Alarm properties on selected panels or on a group of panels.
Syntax
[+|–]AlternateSensitivityOn|ALTSON;
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
Notes
The AlternateSensitivityOn command syntax does not require that you specify a
device type or an object label.
The AlternateSensitivityOn command is typically used with a time control to
automatically change smoke detector settings or with a control-display module
switch to manually override them.
Device types
The following device types respond to the AlternateSensitivityOn command:
AlternateSensitivity
Example
The following rule activates the alternate smoke detector settings when the time control
labeled Mon_Fri_Non_Work_Hrs goes active.
[Alt Sensitivity On]
TIME 'Mon_Fri_Non_Work_Hrs' : ALTSON ;
AmpOff command

Description
Use the AmpOff command to disconnect an amplifier module from an audio channel and
turn the amplifier off. The AmpOff command contains two parts. The first part of the
command (AmpOff) identifies the amplifier and the second part (to) identifies the audio
channel.
Short form: none
Syntax
[+|–]AmpOff –priority 'amp_label' to 'channel_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
amp_label specifies the amplifier module to turn off.
channel_label specifies the audio channel to remove from the amplifier's input.
Notes
The AmpOff command syntax requires that you specify an amplifier label and a
channel label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the AmpOff command:
Amp
Example
The following rule turns off amplifiers on a floor-by-floor basis when an operator presses
the corresponding switch.
[Page Control Switches]
SW 'LVL<n:1-10>_Page_Off' : AMPOFF -low 'LVL<n>_Amp' to
'Ch_Page_01_08' ;
AmpOn command

Description
Use the AmpOn command to connect an amplifier module to an audio channel and turn the
amplifier on. The AmpOn command contains two parts. The first part of the command
(AmpOn) identifies the amplifier and the second part (to) identifies the audio channel.
Short form: none
Syntax
[+|–]AmpOn –priority 'amp_label' to 'channel_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
amp_label specifies the amplifier module to turn on
channel_label specifies the audio channel to connect to the amplifier's input
Notes
The AmpOn command syntax only requires that you specify an amplifier label and a
channel label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the AmpOn command:
Amp
Example
The following rule turns on amplifiers on a floor-by-floor basis when an operator presses the
corresponding switch.
[Page Control Switches]
SW 'LVL<n:1-10>_Page_On' : AMPON -low 'LVL<n>_Amp' to
'Ch_Page_01_08' ;
Away command

Description
Use the Away command to arm a partition completely (both perimeter and interior devices).
The initial state of the partition can be Disarmed or Stay and the Away command changes it
to Away.
This command changes the partition state to Away unconditionally, without determining the
current state of devices in the partition.
Short form: none
Syntax
[+|–]Away device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the partition you want to arm
object_label specifies the label of the partition you want to arm
Note: The Away command syntax requires that you specify a device type, an object label,
or both.
Device types
The following device types respond to the Away command:
Partition
Example
The following rule arms (away) the common area partitions in a multi-story building.
[Manually Arm-Away Common Areas]
SW 'Arm_Away_Common' : Away PARTITION 'Common_*' ;
See also
ConditionalAway command
ConditionalStay command
Disarm command
Stay command
UpdateStatus command
Bypass command

Description
Use the Bypass command to inhibit SecurityAlarm events generated by a device. Other
events are still monitored. To remove a Bypass, use the RemoveBypass command.
The partition must be disarmed for this command to have any effect. Devices in an armed
partition cannot be bypassed.
Short form: BYP
Syntax
[+|–]Bypass|BYP device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
device_type specifies the device type of the device you want to bypass
object_label specifies the label of the device you want to bypass
Notes: The Bypass command syntax requires that you specify a device type or an object
label, or both.
Device types
The following device types respond to the Bypass command:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Example
This rule uses a switch to bypass the door to a stockroom.
Switch 'Stockroom_Access' : BYP 'Stockroom_Door_Contact';
Calibrate command

Description
Use the Calibrate command to reset the environmental compensation and dirtiness level on
Edwards Analog sensors after the devices have been cleaned. When used with a 3-EASC
or 3-EADC this command calibrates all smoke devices connected to the controller, and
recalculates the number of isolators on a Class A circuit.
Short form: CAL
Syntax
[+|–]Calibrate|CAL device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the device you want to calibrate
object_label specifies the label of the output device you want to calibrate
Notes
The Calibrate command syntax requires that you specify a device type, an object
label, or both.
The Calibrate command does not work on Signature detectors.
Device types
The following device types respond to the Calibrate command:
3-EADC
3-EASC
Smoke
SmokePre
SmokeVfy
Example
The following rule reset the environmental compensation and dirtiness level on an Edwards
analog device when an operator presses the corresponding switch.
[Calibrate Smoke Switches]
SW 'Calibrate_Smoke_<n:1-5>' : CAL Smoke 'Smoke<n>' ;
Close command

Description
Use the Close command to turn off an output circuit that connects to a control mechanism
used to operate a damper. To use this command as intended, the output circuit must be
wired to the control mechanism so that when the output circuit is turned off the control
mechanism places the damper in the closed position.
Short form: none
Syntax
[+|–]Close –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The Close command syntax only requires that you specify an object label. Specifying
a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the Close command:
DamperControl
Example
The following rule turns off the damper control output circuit when an operator presses the
corresponding switch.
[Damper Close Switches]
SW 'Close_Dmpr_<n:1-5>' : CLOSE -low 'Dmpr_Control_<n>' ;
CommonAlarmOff command

Description
Use the CommonAlarmOff command to turn off a supervised common alarm output circuit
that was turned on with the CommonAlarmOn command.
Short form: CAOFF
Syntax
[+|–]CommonAlarmOff|CAOFF –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off.
Notes
The CommonAlarmOff command syntax only requires that you specify an object
label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Common alarm output circuits turned on as a result of an alarm event cannot be
turned off using the CommonAlarmOff command.
The CommonAlarmOff command does not affect the operation of the Form C
common alarm relay on the 3-CPU1 module.
Device types
The following device types respond to the CommonAlarmOff command:
CommonAlarmOutput
Example
The following rule turns off the supervised common alarm output circuit when an operator
presses the corresponding switch.
[Common Alarm Off Switches]
SW 'Com_Alarm_<n:1-5>_Off' : CAOFF -low 'Com_Alarm_<n>' ;
CommonAlarmOn command

Description
Use the CommonAlarmOn command to turn on a supervised common alarm output circuit
when an event other than the FirstAlarm event occurs.
Short form: CAON
Syntax
[+|–]CommonAlarmOn|CAON –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on.
Notes
The CommonAlarmOn command syntax only requires that you specify an object
label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
The CommonAlarmOn command does not affect the operation of the Form C
common alarm relay on the 3-CPU1 module.
Device types
The following device types respond to the CommonAlarmOn command:
CommonAlarmOutput
Example
The following rule turns on the supervised common alarm output circuit when an operator
presses the corresponding switch.
[Common Alarm On Switches]
SW 'Com_Alarm_<n:1-5>_On' : CAON -low 'Com_Alarm_<n>' ;
CommonMonitorOff command

Description
Use the CommonMonitorOff command to turn off a supervised common monitor output
circuit that was turned on with the CommonMonitorOn command.
Short form: CMOFF
Syntax
[+|–]CommonMonitorOff|CMOFF –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The CommonMonitorOff command syntax only requires that you specify an object
label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Common monitor output circuits turned on as a result of a monitor event cannot be
turned off using the CommonMonitorOff command.
You cannot use any device to turn off a common monitor output circuit that upon
activation produces a monitor event. For example, you cannot use a control-display
module switch.
Device types
The following device types respond to the CommonMonitorOff command:
CommonMonitorOutput
Example
The following rule turns off the common monitor output circuit labeled Evac_Door when any
alarm device changes to the active state.
[General Alarm Response]
Alarm GENALARM : CMOFF -low 'Evac_Door' ;
CommonMonitorOn command

Description
Use the CommonMonitorOn command to turn on a supervised common monitor output
circuit when an event other than the FirstMonitor event occurs.
Short form: CMON
Syntax
[+|–]CommonMonitorOn|CMON –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on.
Notes
The CommonMonitorOn command syntax only requires that you specify an object
label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the CommonMonitorOn command:
CommonMonitorOutput
Example
The following rule turns on the supervised common monitor output circuit when an operator
presses the corresponding switch.
[Common Monitor On Switches]
SW 'Com_Mon_<n:1-5>_On' : CMON -low 'Com_Mon_<n>' ;
CommonSupervisoryOff command

Description
Use the CommonSupervisoryOff command to turn off a supervised common supervisory
output circuit that was turned on with the CommonSupervisoryOn command.
Short form: CSOFF
Syntax
[+|–]CommonSupervisoryOff|CSOFF –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The CommonSupervisoryOff command syntax only requires that you specify an
object label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Common supervisory output circuits turned on as a result of an supervisory event
cannot be turned off using the CommonSupervisoryOff command.
Device types
The following device types respond to the CommonSupervisoryOff command:
CommonSupervisoryOutput
Example
The following rule turns off the supervised common supervisory output circuit when an
operator presses the corresponding switch.
[Common Sup Off Switches]
SW 'Com_Sup_<n:1-5>_Off' : CSOFF -low 'Com_Sup_<n>' ;
CommonSupervisoryOn command

Description
Use the CommonSupervisoryOn command to turn on a supervised common supervisory
output circuit when an event other than the FirstSupervisory event occurs.
Short form: CSON
Syntax
[+|–]CommonSupervisoryOn|CSON –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on.
Notes
The CommonSupervisoryOn command syntax only requires that you specify an
object label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the CommonSupervisoryOn command:
CommonSupervisoryOutput
Example
The following rule turns on the supervised common supervisory output circuit when an
operator presses the corresponding switch.
[Common Sup On Switches]
SW 'Com_Sup_<n:1-5>_On' : CSON -low 'Com_Sup_<n>' ;
ConditionalAway command

Description
Use the ConditionalAway command to check the state of partition devices and arm-away
the partition if the devices are normal. The initial state of the partition can be Disarmed or
Stay and is changed to Away.
Devices must not be in any of these states:
Bypassed
SecurityAlarm
SecurityTamper
SecurityTrouble
Further, all associated points (such as AC power supervision, telecom supervision, and
network communications supervision) must be normal.
If the partition fails to arm, the system generates a SecurityAwayFail event.
Short form: CONAWAY
Syntax
[+|–]ConditionalAway|CONAWAY device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the partition you want to arm
object_label specifies the label of the partition you want to arm
Note: The ConditionalAway command syntax requires that you specify a device type, an
object label, or both.
Device types
The following device types respond to the ConditionalAway command:
Partition
Network performance
This command can result in a high volume of network messages. If you use a single
response (for example, a switch) to control several partitions, make sure that you don't
degrade network performance by generating a high volume of messages.
The number of messages exchanged by the panels depends on:
The number of partitions being controlled
The number of panels in the network
For example, if you reset 10 partitions on a 10 panel network, 100 messages are
exchanged. If you reset 50 partitions on a 40 panel network, then 2,000 messages are
exchanged. Resetting 250 partitions on a 60 panel network exchanges 15,000 messages.
While this amount of network traffic does not harm the network, the time it takes to process
the information can delay the processing of other network messages.
We recommend that you limit number of partitions controlled by a single response
according this formula:
P < 320 / N
Where:
P = number of partitions
N = number of panels
Examples: For a 20 panel network, limit commands to 16 partitions. For a 64 panel
network, limit commands to 5 partitions.
In practice, you would write a rule with several output commands. Each command would
control a limited number of partitions (according to the formula). You would also place a 10
second delay between each command, to make sure all messages for one command were
processed before the next command was executed.
This limitation does not apply to the Disarm, Away, and Stay commands. These commands
do not require a high volume of messages.
Example
The following rule tests and arms (away) the common area partitions in a multi-story
building.
[Manually Arm-Away Common Areas]
SW 'Arm_Away_Common' : CONAWAY PARTITION 'Common_*' ;
See also
Away command
ConditionalStay command
Disarm command
Stay command
UpdateStatus command
ConditionalStay command

Description
Use the ConditionalStay command to check the state of partition devices and arm-stay the
partition if the devices are normal. The initial state of the partition must be Disarmed and is
changed to Stay.
Devices must not be in any of these states:
Bypassed
SecurityAlarm
SecurityTamper
SecurityTrouble
Further, all associated points (such as AC power supervision, telecom supervision, and
network communications supervision) must be normal.
If the partition fails to arm, the system generates a SecurityStayFail event.
Short form: CONSTAY
Syntax
[+|–]ConditionalStay|CONSTAY device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the partition you want to arm
object_label specifies the label of the partition you want to arm
Note: The ConditionalStay command syntax requires that you specify a device type, an
object label, or both.
Device types
The following device types respond to the ConditionalStay command:
Partition
Network performance
This command can result in a high volume of network messages. If you use a single
response (for example, a switch) to control several partitions, make sure that you don't
degrade network performance by generating a high volume of messages.
The number of messages exchanged by the panels depends on:
The number of partitions being controlled
The number of panels in the network
For example, if you reset 10 partitions on a 10 panel network, 100 messages are
exchanged. If you reset 50 partitions on a 40 panel network, then 2,000 messages are
exchanged. Resetting 250 partitions on a 60 panel network exchanges 15,000 messages.
While this amount of network traffic does not harm the network, the time it takes to process
the information can delay the processing of other network messages.
We recommend that you limit number of partitions controlled by a single response
according this formula:
P < 320 / N
Where:
P = number of partitions
N = number of panels
Examples: For a 20 panel network, limit commands to 16 partitions. For a 64 panel
network, limit commands to 5 partitions.
In practice, you would write a rule with several output commands. Each command would
control a limited number of partitions (according to the formula). You would also place a 10
second delay between each command, to make sure all messages for one command were
processed before the next command was executed.
This limitation does not apply to the Disarm, Away, and Stay commands. These commands
do not require a high volume of messages.
Example
The following rule tests and arms (stay) the common area partitions in a multi-story building.
[Manually Arm-Stay Common Areas]
SW 'Arm_Stay_Common' : CONSTAY PARTITION 'Common_*' ;
See also
Away command
ConditionalAway command
Disarm command
Stay command
UpdateStatus command
Delay command

Description
Use the Delay command to insert a time delay between output command statements when
the rule activates and restores.
Short form: DLY
Syntax
[+|–]Delay|DLY delay_value;
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
delay_value specifies the length of the delay from 0 to 65,535 seconds, inclusive.
Note: This option lets you select settings outside the range specified in UL 864 and
CAN/ULC-S527. For more details see UL 864 and ULC-S527 programming
requirements.
Notes
The Delay command does not require that you specify a device type or an object
label.
Remember that the system can reorder output commands to optimize your compiled
rules. You can force one command to follow another by inserting a delay between
them. Even a delay of 0 seconds will keep the commands in the same order.
If the input restores during a delay, the rule restores without completing the
remaining output commands. To ensure that all output commands are executed when
a rule contains delay commands, use a command list.
Example
The following rule turns the second amplifier on approximately 10 seconds after turning on
the first amplifier when the panel first starts up.
[Startup]
STUP : AMPON 'LVL_5_Amp' TO 'Ch_Gen_01_08',
DLY 10,
AMPON 'LVL_6_Amp' TO 'Ch_Gen_01_08' ;
DelayActivate command

Description
Use the DelayActivate command to insert a time delay between output command
statements only when the rule activates. The delay is not inserted when the rule restores.
Short form: DLYA
Syntax
DelayActivate|DLYA delay_value;
Where:
delay_value specifies the length of the delay from 0 to 65,535 seconds, inclusive.
Note: This option lets you select settings outside the range specified in UL 864 and
CAN/ULC-S527. For more details see UL 864 and ULC-S527 programming
requirements.
Notes
The DelayActivate command syntax does not require that you specify a device type
or an object label.
You cannot use the On Rule Activate (+) and On Rule Restore (–) command
qualifiers with this command.
DelayActivate is equivalent to +Delay.
Remember that the system can reorder output commands to optimize your compiled
rules. You can force one command to follow another by inserting a delay between
them. Even a delay of 0 seconds will keep the commands in the same order.
It the input restores during a delay, then the rule restores without completing the
remaining output commands. To ensure that all output commands are executed when
a rule contains delay commands, use a command list.
Example
The following rule turns on the pressurization fan approximately 15 seconds after turning off
the supply fan when any smoke detector changes to the alarm state.
[Alarm Fan]
Alarm GENSMOKE : FANOFF 'Supply_Fan',
DLYA 15,
FANON 'Pressure_Fan1' ;
DelayRestore command

Description
Use the DelayRestore command to insert a time delay between output command
statements only when the rule restores. The delay is not inserted when the rule activates.
Short form: DLYR
Syntax
DelayRestore|DLYR delay_value;
Where:
delay_value specifies the length of the delay from 0 to 65,535 seconds, inclusive.
Notes
The DelayRestore command syntax does not require that you specify a device type
or an object label.
You cannot use the On Rule Activate (+) and On Rule Restore (–) command
qualifiers with this command.
DelayRestore is equivalent to -Delay.
Remember that the system can reorder output commands to optimize your compiled
rules. You can force one command to follow another by inserting a delay between
them. Even a delay of 0 seconds will keep the commands in the same order.
It the input restores during a delay, then the rule restores without completing the
remaining output commands. To ensure that all output commands are executed when
a rule contains delay commands, use a command list.
Example
The following rule turns on the second pressurization fan immediately after turning on the
first pressurization fan when the switch is pressed. When the switch is released, the first
fan is turned off approximately 15 seconds after the second fan is turned off.
[Fan On Switch]
SW 'Pressure_Fans_On' : FanOn 'Pressure_Fan1',
DLYR 15,
FanOn 'Pressure_Fan2';
Disable command

Description
Use the Disable command to prevent a system hardware component, circuit, or logic group
from activating.
Note: By default for the Singapore marketplace, any devices or zones configured with the
CMSSupervisedOutput and CMSNonsupervisedOutput device types cannot be disabled. If
you are using the Singapore marketplace but want to use the Disable command with these
device types, check the Allow Disables check box on the Project Parameters - Operations
tab (Configure > Project > Operations).
Short form: none
Syntax
[+|–]Disable device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
device_type specifies the device type of the device you want to disable.
object_label specifies the label of the output device you want to disable.
Notes
The Disable command syntax requires that you specify a device type, an object
label, or both.
Disabling a Zone group disables the group and all the devices in the group.
If you check the "Restore Event on Disable" check box on the Project Parameters -
Operations tab, when a device is disabled the system restores the device's off-
normal events. If you clear that check box, when a device is disabled the system
instead latches the device's off-normal events until the device is again enabled. This
affects both input events and output commands.
Device types
The following device types respond to the Disable command:

12SW/12LED COSupervisory LogicalOutput

12SW/24LED CommFailure Matrix
2 Stage Signal CommonAlarmOutput MComAccount
24LED CommonMonitorOutput Monitor
3-AADC CommonSupervisoryOutput NonsupervisedOutput
3-AADC1 DamperControl Power
3-ASU DamperFeedback Pull
3-DSDC DoorControl Security
3-EADC DoorFeedback Security24Hour
3-EASC EMailAccount SecurityDay
3-FTCU Ethernet_Card SecurityIMonitor
3-IDC8/4 FanControl SecurityInterior
3-MODCOM FanFeedback SecurityPerimeter
3-OPS Firephone SecurityPMonitor
3-SDDC Gatevalve Smoke
3-SDDC1 GenAlarm SmokePre
3-SSDC G_Audible SmokeVfy
3-SSDC1 G_Visible SprinklerSupervisory
3SW/3LEDX6 G_AudibleVisible StageOne
3SW/4LEDx4 G_CommonAlarmOutput StageTwo
AccessDoorControl G_CommonMonitorOutput SupervisedOutput
AccessOutput G_CommonSupervisoryOutput Supervisory
ACFail GenSmoke Switch
Amp Guard Tamper
AND GuardPatrol Temperature
Audible Heat Text
ControlledAuxOutput IPAccount TimeControl
CmdList LED Visible
CMSNonsupervisedOutput LocalAlarm Waterflow
CMSSupervisedOutput LocalMonitor Zone
COAlarm LocalRelay
COMonitor LocalTrouble
Example
The following rule disables the fan status LEDs when an operator presses the switch
labeled Fan_LED_Disable.
[Disable Fan Status LEDs]
SW 'Fan_LED_Disable' : Disable LED 'Fan_*' ;
Disarm command

Description
Use the Disarm command to disarm a partition. The partition state can be Away or Stay
and the Disarm command changes it to Disarmed.
Short form: DISA
Syntax
[+|–]Disarm|DISA device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
device_type specifies the device type of the partition you want to disarm
object_label specifies the label of the partition you want to disarm
Notes: The Disarm command syntax requires that you specify a device type or an object
label, or both.
Device types
The following device types respond to the Disarm command:
Partition
Example
The following rule disarms the common area partitions in a multi-story building.
[Manually Disarm Common Areas]
SW 'Disarm_Common' : Disarm PARTITION 'Common_*' ;
See also
Away command
ConditionalAway command
ConditionalStay command
Stay command
UpdateStatus command
Drill command

Description
Use the Drill command to program a momentary switch on a control-display module to
activate the Drill function. Activating the Drill function turns on a panel's alarm notification
appliance signals but does not put the panel into alarm.
Short form: none
Syntax
[+|–]Drill 'cabinet_label';
— or —
[+|–]Drill 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
cabinet_label specifies the label of the panel whose Drill function you want to
activate
routing_label specifies the label of the network route containing the panels whose
Drill function you want to activate
Notes
The Drill command syntax does not require that you specify a device type.
You must configure the switch used to execute the Drill command as a momentary
switch.
Project parameter settings determine whether the Drill function automatically
activates only audible, or both audible and visible notification appliance circuits.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
Device types
The following device types respond to the Drill command:
Drill
Example
The following rule activates the Drill function on the panel labeled Cab2 when an operator
presses the switch labeled C2_Drill_On.
[Drill Cntrl]
SW 'C2_Drill_On' : Drill 'Cab2' ;
Enable command

Description
Use the Enable command to allow a system hardware component, circuit, or logic group to
activate. At system start up, all devices are enabled unless disabled in a startup rule.
Short form: none
Syntax
[+|–]Enable device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
device_type specifies the device type of the device you want to enable.
object_label specifies the label of the output device you want to enable.
Note: The Enable command syntax requires that you specify a device type, an object label,
or both.
Device types
The following device types respond to the Enable command:

12SW/12LED CommFailure MComAccount

12SW/24LED CommonAlarmOutput Monitor
2 Stage Signal CommonMonitorOutput NonsupervisedOutput
24LED CommonSupervisoryOutput NSCommonAlarmOutput
3-AADC DamperControl NSCommonMonitorOutput
3-AADC1 DamperFeedback NSCommonSupervisoryOutput
3-ASU DoorControl NSCommonTroubleOutput
3-DSDC DoorFeedback Power
3-EADC EMailAccount Pull
3-EASC Ethernet_Card Security
3-FTCU FanControl Security24Hour
3-IDC8/4 FanFeedback SecurityDay
3-MODCOM Firephone SecurityIMonitor
3-OPS Gatevalve SecurityInterior
3-SDDC GenAlarm SecurityPerimeter
3-SDDC1 G_Audible SecurityPMonitor
3-SSDC G_Visible Smoke
3-SSDC1 G_AudibleVisible SmokePre
3SW/3LEDx6 G_CommonAlarmOutput SmokeVfy
3SW/4LEDx4 G_CommonMonitorOutput SprinklerSupervisory
AccessDoorControl G_CommonSupervisoryOutput StageOne
AccessOutput GenSmoke StageTwo
ACFail Guard SupervisedOutput
Amp GuardPatrol Supervisory
AND Heat Switch
Audible IPAccount Tamper
ControlledAuxOutput LED Temperature
CmdList LocalAlarm Text
CMSNonsupervisedOutput LocalMonitor TimeControl
CMSSupervisedOutput LocalRelay Visible
COAlarm LocalTrouble Waterflow
COMonitor LogicalOutput Zone
COSupervisory Matrix
Example
The following rule enables the fan status LEDs the first time that any point on the panel
changes to the alarm state.
[Enable Fan Status LEDs]
FA : Enable LED 'Fan_*' ;
Evacuation command

Description
Use the Evacuation command to program a momentary switch on a control-display module
to activate the Evacuation function. Activating the Evacuation function puts a panel into
alarm and activates its programmed alarm responses.
Short form: EVAC
Syntax
[+|–]Evacuation|EVAC 'cabinet_label';
— or —
[+|–]Evacuation|EVAC 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
cabinet_label specifies the label of the panel whose Evacuation function you want to
activate
routing_label specifies the label of the network route containing the panels whose
Evacuation function you want to activate
Notes
The Evacuation command syntax does not require that you specify a device type.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
Device types
The following device types respond to the Evacuation command:
Evacuation
Example
The following rule activates the Evacuation function on all panels in the network when an
operator presses the switch labeled C1_Evac_On.
[Evacuation Cntrl]
SW 'C1_Evac_On' : EVAC 'All_Cabinets' ;
FanOff command

Description
Use the FanOff command to turn off an output circuit that connects to a control mechanism
used to operate a fan. To use this command as intended, the output circuit must be wired to
the control mechanism so that when the output circuit is turned off the control mechanism
turns off the fan.
Short form: none
Syntax
[+|–]FanOff –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The FanOff command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the FanOff command:
FanControl
Example
The following rule turns off a fan control circuit when an operator presses the corresponding
switch.
[Fan Off Switches]
SW 'Stop_Fan_<n:1-5>' : FANOFF -low 'Fan_Control_<n>' ;
FanOn command

Description
Use the FanOn command to turn on an output circuit that connects to a control mechanism
used to operate a fan. To use this command as intended, the output circuit must be wired to
the control mechanism so that when the output circuit is turned on the control mechanism
turns on the fan.
Short form: none
Syntax
[+|–]FanOn –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on
Notes
The FanOn command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the FanOn command:
FanControl
Example
The following rule turns on a fan control circuit when an operator presses the corresponding
switch.
[Fan On Switches]
SW 'Start_Fan_<n:1-5>' : FANON -low 'Fan_Control_<n>' ;
FastBlink command

Description
Use the FastBlink command to turn on a control-display module's light-emitting diode and
have it blink at a fast rate.
Short form: FAST
Syntax
[+|–]FastBlink|FAST –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the light-emitting diode to turn on
Notes
The FastBlink command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the FastBlink command:
LED
Example
The following rule turns on the LED labeled R2_LED during the second phase of the Reset
cycle.
[Ann_Reset_2nd_Phase]
R2 : FAST -low 'R2_LED' ;
GAInhibit command

Description
Use the GAInhibit command to stop a panel's two-stage timer before it expires. By
programming a control-display module switch to execute the GAInhibit command, an
operator can stop a panel's two-stage alarm timer and prevent the panel from sounding a
general alarm.
Short form: GAIN
Syntax
[+|–]GAInhibit|GAIN 'cabinet_label';
— or —
[+|–]GAInhibit|GAIN 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
cabinet_label specifies the panel whose two-stage timer you want to stop
routing_label specifies the label of the network route containing the panels whose
two-stage timer you want to stop
Notes
The GAInhibit command syntax does not require that you specify a device type.
You must configure the switch used to execute the GAInhibit command as a
momentary switch.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
Device types
The following device types respond to the GAInhibit command:
GAInhibit
Example
The following rule stops the two-stage timer on all the panels in the network when an
operator presses the switch labeled 2Stage_Stop.
[GAInhibit Cntrl]
SW '2Stage_Stop' : GAIN 'All_Cabinets' ;
GasAcceleratedResponseOff command

Description
Use this command to turn off the accelerated response mode for testing CO devices, and
to return CO detection to the normal levels.
Note: When testing a CO device, you can first turn on the accelerated response mode by
using the GasAcceleratedResponseOn command; the device stays in that mode for up to
four hours or until it is turned off by the GasAcceleratedResponseOff command.
Short form: GASACCELOFF
Syntax
[+|–]GasAcceleratedResponseOff|GASACCELOFF device_type 'object_label';
Where:
device_type specifies the device type of the device to turn off.
object_label specifies the label of the device to turn off.
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
Device types
The following device types respond to the GasAcceleratedResponseOff command:
COAlarm
COMonitor
COSupervisory
Heat
Smoke
SmokePre
SmokeVfy
Example
The following rule turns off CO gas acceleration for the CO detector on the second floor,
and returns the CO detection to the normal levels, when an operator activates switch 001.
[Turn CO Gas acceleration off]
SW 'SW_001' : GASACCELOFF 'CO_FLR_002' ;
GasAcceleratedResponseOn command

Description
Use this command to change the CO rate of detection, for test purposes only.
Under normal conditions, it takes approximately four minutes at 400 PPM of CO before a
CO detector activates (which mimics the normal absorption rate of CO in the bloodstream).
When testing a CO device, you can put the CO detectors in the CO accelerated response
mode, which shortens the time to activation to be between four to eight seconds at 400
PPM of CO.
After completing the CO tests, return to the regular CO response mode by using the
GasAcceleratedResponseOff command.
Note: If you do not use the GasAcceleratedResponseOff command, CO detection returns
to its normal response after 4 hours.
Short form: GASACCELON
Syntax
[+|–]GasAcceleratedResponseOn|GASACCELON device_type 'object_label';
Where:
device_type specifies the device type of the device to turn on.
object_label specifies the label of the device to turn on.
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
Notes
The GasAcceleratedResponseOn command syntax requires that you specify a
device type, an object label, or both.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the GasAcceleratedResponseOn command:
COAlarm
COMonitor
COSupervisory
Heat
Smoke
SmokePre
SmokeVfy
Example
The following rule accelerates CO gas detection for the CO detector on the second floor,
when an operator presses switch 002.
[Turn CO Gas acceleration on for test]
SW 'SW_002' : GASACCELON 'CO_FLR_002' ;
HoldDoor command

Description
Use the HoldDoor command to turn on an output circuit that connects to a control
mechanism used to hold a door in a fixed position. To use this command as intended, the
output circuit must be wired to the control mechanism so that when the output circuit is
turned on the control mechanism holds the door.
Short form: HOLD
Syntax
[+|–]HoldDoor|HOLD –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on
Notes
The HoldDoor command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the HoldDoor command:
DoorControl
Example
The following rule turns on a door control circuit when an operator presses the
corresponding switch.
[Door Hold Switches]
SW 'Hold_Door_<n:1-5>' : HOLD -low 'Door_Control_<n>' ;
LampTest command

Description
Use the LampTest command to program a momentary switch on a control-display module to
activate the Lamp Test function. Activating the Lamp Test function temporarily lights all
control-display module light-emitting diodes only on the panel containing the switch
programmed that executes the command.
Short form: LAMP
Syntax
[+|–]LampTest|LAMP;
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
Notes
The LampTest command syntax does not require that you specify a device type or
an object label.
You must configure the switch used to execute the LampTest command as a
momentary switch.
The LampTest command operates only on the panel containing the switch
programmed to execute the command. To do a lamp test on all panels defined in
network routing, use the LampTest2 command instead.
Device types
The following device types respond to the LampTest command:
LampTest
Example
The following rule activates a network's Lamp Test function.
[Lamp Test]
SW 'C2_LampTest' : +LAMP ;
LampTest2 command

Description
Use the LampTest2 command to program a momentary switch on a control-display module
to activate the Lamp Test2 function. Activating the Lamp Test2 function temporarily lights all
control-display module light-emitting diodes defined by the cabinet or network routing label.
Short form: LAMP2
Syntax
[+|–]LampTest2|LAMP2 ‘cabinet_label’;
[+|–]LampTest2|LAMP2 ‘routing_label’;
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
Notes
The LampTest2 command syntax does not require that you specify a device type or
an object label.
You must configure the switch used to execute the LampTest2 command as a
momentary switch.
The LampTest2 command operates on all panels defined in network routing. To do a
lamp test only on the panel containing the switch programmed to execute the
command, use the LampTest command instead.
Device types
The following device types respond to the LampTest2 command:
LampTest
Example
The following rule activates a panel's Lamp Test2 function.
[Lamp Test2]
SW 'C2_LampTest' : +LAMP2 ‘Cab1’;
SW 'C2_LampTest' : +LAMP2 ‘All_Cabinets’;
LEDOff command

Description
Use the LEDOff command to turn off a control-display module's light-emitting diode.
Short form: none
Syntax
[+|–]LEDOff –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the LED to turn off
Notes
The LEDOff command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the LEDOff command:
LED
Example
The following rule turns off the damper status LED when the corresponding damper
feedback circuit changes to the active state.
[DAMPER_LIMIT_LED_OFF]
MON DAMPERFB 'Fan<n:1-5>_Dmpr_CLIMIT' : LEDOFF -low
'Dmpr<n>_Open_LED' ;
MsgOff command

Description
Use the MsgOff command to stop broadcasting an voice message over the selected audio
channel. The MsgOff command contains three parts. The first part of the command
(MsgOff) identifies the message, the second part (from) identifies the 3-ASU that provides
the message, and the third part (to) identifies the audio channel.
Short form: none
Syntax
[+|–]MsgOff –priority 'msg_label' from 'asu_label' to 'channel_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
msg_label specifies the label of the voice message to stop broadcasting.
asu_label specifies the label of the audio source unit providing the voice message.
channel_label specifies the label of the audio channel broadcasting the voice
message.
Notes
Use the asu_label parameter only with systems that have multiple audio source
units.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the MsgOff command:
MSG
Example
The following rule stops the test message from being broadcast over the EVAC channel
when an operator presses the switch labeled Evac_Ch_Off.
[EVAC Msg Off Test]
SW 'Evac_Ch_Off' : MSGOFF 'Test_Msg' from '3-ASU1' to
'Ch_Evac_01_08' ;
MsgOn command

Description
Use the MsgOn command to start broadcasting a voice message over a selected audio
channel. The MsgOn command contains three parts. The first part of the command
(MsgOn) identifies the message, the second part (from) identifies the 3-ASU that provides
the message, and the third part (to) identifies the audio channel.
Short form: none
Syntax
[+|–]MsgOn –priority 'msg_label' from 'asu_label' to 'channel_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
msg_label specifies the label of the voice message to start broadcasting.
asu_label specifies the label of the audio source unit providing the voice message.
channel_label specifies the label of the audio channel broadcasting the voice
message.
Notes
The MsgOn command must be placed after the AmpOn command in a rule and
selected to the same audio channel as the amplifier.
Only use the asu_label parameter with systems that have multiple audio source
units.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the MsgOff command:
MSG
Example
The following rule broadcasts the test message over the EVAC channel when an operator
presses the switch labeled Evac_Msg_Test.
[EVAC Msg Test]
SW 'Evac_Msg_Test' :
AMPON 'Amp1' to 'Ch_Evac_01_08',
MSGON 'Test_Msg' from '3-ASU1' to 'Ch_Evac_01_08' ;
NAC120 command
Use the NAC120 command to change a notification appliance circuit's output to 120 beats
per minute (1/4 second on, 1/4 second off).
Note: Do not use on notification appliance circuits connected to temporal horns or strobes.
Short form: none
Syntax
[+|–]NAC120 –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit.
Device types
The following device types respond to the NAC120 command:
Audible
CommonAlarmOutput
Example
The following rule, upon alarm activation, sounds all the horns on the floor of incidence, the
floor above, and the floor below using the NACTemporal pattern; all horns on the floors that
are two floors above and two floors below the floor of incidence using the NAC120 pattern;
and the horns on all other floors using the NAC20 pattern.
[Alarm Horns]
Alarm 'Level_<N:1-10>_SMK' : NAC20 -low 'Level_*_Horn',
NACTMP -high 'Level_<N>_Horn',
NACTMP -high 'Level_<N+1>_Horn',
NACTMP -high 'Level_<N-1>_Horn',
NAC120 -medium 'Level_<N+2>_Horn',
NAC120 -medium 'Level_<N-2>_Horn';
NAC20 command
Use the NAC20 command to change a notification appliance circuit's output to 20 beats per
minute (1-1/2 seconds on, 1-1/2 seconds off).
Note: Do not use on notification appliance circuits connected to temporal horns or strobes.
Short form: none
Syntax
[+|–]NAC20 –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit.
Device types
The following device types respond to the NAC20 command:
Audible
CommonAlarmOutput
Example
The following rule, upon alarm activation, sounds all the horns on the floor of incidence, the
floor above, and the floor below using the NACTemporal pattern; all horns on the floors that
are two floors above and two floors below the floor of incidence using the NAC120 pattern;
and the horns on all other floors using the NAC20 pattern.
[Alarm Horns]
[Alarm Horns]
Alarm 'Level_<N:1-10>_SMK' : NAC20 -low 'Level_*_Horn',
NACTMP -high 'Level_<N>_Horn',
NACTMP -high 'Level_<N+1>_Horn',
NACTMP -high 'Level_<N-1>_Horn',
NAC120 -medium 'Level_<N+2>_Horn',
NAC120 -medium 'Level_<N-2>_Horn';
NACCO command
Use the NACCO command to change a notification appliance circuit's output to the CO
alarm signal pattern: 1/10th second on, 1/10th second off, 1/10th second on, 1/10th second
off, 1/10th second on, 1/10th second off, 1/10th second on, 5-1/10th seconds off.
Notes
Do not use on notification appliance circuits connected to temporal horns or strobes.
You can only use the NACCO command for circuits on the PS/NAC module.
Short form: none
Syntax
[+|–]NACCO –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit.
Device types
The following device types respond to the NACCO command:
Audible
CommonAlarmOutput
Example
The following rule, upon CO alarm activation, sounds all the horns on the floor of incidence,
the floor above, and the floor below using the NACCO pattern.
[COAlarm Horns]
COALM 'Level_<N:1-10>_CO' : NACCO -high 'Level_<N>_Horn',
NACCO -high 'Level_<N+1>_Horn',
NACCO -high 'Level_<N-1>_Horn';
NACTemporal command
Use the NACTemporal command to change a notification appliance circuit's output to the
NFPA 72 audible emergency evacuation signal pattern (3-3-3).
Note: Do not use on notification appliance circuits connected to temporal horns or strobes.
Short form: NACTMP
Syntax
[+|–]NACTemporal|NACTMP –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit.
Device types
The following device types respond to the NACTMP command:
Audible
CommonAlarmOutput
Example
The following rule, upon alarm activation, sounds all the horns on the floor of incidence, the
floor above, and the floor below using the NACTemporal pattern; all horns on the floors that
are two floors above and two floors below the floor of incidence using the NAC120 pattern;
and the horns on all other floors using the NAC20 pattern.
[Alarm Horns]
Alarm 'Level_<N:1-10>_SMK' : NAC20 -low 'Level_*_Horn',
NACTMP -high 'Level_<N>_Horn',
NACTMP -high 'Level_<N+1>_Horn',
NACTMP -high 'Level_<N-1>_Horn',
NAC120 -medium 'Level_<N+2>_Horn',
NAC120 -medium 'Level_<N-2>_Horn';
NCClose command

Description
Use the NCClose command to turn on an output circuit that connects to a control
mechanism used to operate a damper. To use this command as intended, the output circuit
must be wired to the control mechanism so that when the output circuit is turned on the
control mechanism places the damper in the closed position.
Short form: none
Syntax
[+|–]NCClose –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on.
Notes
The NCClose command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the NCClose command:
DamperControl
Example
The following rule turns on a damper control circuit when an operator presses the
corresponding switch.
[Damper Close Switches]
SW 'Close_Dmpr_<n:1-5>' : NCCLOSE -low 'Dmpr_Control_<n>' ;
NCFanOff command

Description
Use the NCFanOff command to turn on an output circuit that connects to a control
mechanism used to operate a fan. To use this command as intended, the output circuit must
be wired to the control mechanism so that when the output circuit is turned on the control
mechanism turns off the fan.
Short form: none
Syntax
[+|–]NCFanOff –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on
Notes
The NCFanOff command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the NCFanOff command:
FanControl
Example
The following rule turns on a fan control circuit when an operator presses the corresponding
switch.
[Fan Off Switches]
SW 'Stop_Fan_<n:1-5>' : NCFANOFF -low 'Fan_Control_<n>' ;
NCFanOn command

Description
Use the NCFanOn command to turn off an output circuit that connects to a control
mechanism used to operate a fan. To use this command as intended, the output circuit must
be wired to the control mechanism so that when the output circuit is turned off the control
mechanism turns on the fan.
Short form: none
Syntax
[+|–]NCFanOn –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The NCFanOn command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the NCFanOn command:
FanControl
Example
The following rule turns off a fan control circuit when an operator presses the corresponding
switch.
[Fan On Switches]
SW 'Start_Fan_<n:1-5>' : NCFANON -low 'Fan_Control_<n>' ;
NCHoldDoor command

Description
Use the NCHoldDoor command to turn off an output circuit that connects to a control
mechanism used to hold a door in a fixed position. To use this command as intended, the
output circuit must be wired to the control mechanism so that when the output circuit is
turned off the control mechanism holds the door.
Short form: NCHOLD
Syntax
[+|–]NCHoldDoor|NCHOLD –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The NCHoldDoor command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the NCHoldDoor command:
DoorControl
Example
The following rule turns off the door control circuit when an operator presses the
corresponding switch.
[Door Hold Switches]
SW 'Hold_Door_<n:1-5>' : NCHOLD -low 'Door_Control_<n>' ;
NCOpen command

Description
Use the NCOpen command to turn off an output circuit that connects to a control
mechanism used to operate a damper. To use this command as intended, the output circuit
must be wired to the control mechanism so that when the output circuit is turned off the
control mechanism places the damper in the open position.
Short form: none
Syntax
[+|–]NCOpen –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The NCOpen command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the NCOpen command:
DamperControl
Example
The following rule turns off the damper control circuit when an operator presses the
corresponding switch.
[Damper Open Switches]
SW 'Open_Dmpr_<n:1-5>' : NCOpen -low 'Dmpr_Control_<n>' ;
NCReleaseDoor command

Description
Use the NCReleaseDoor command to turn on an output circuit that connects to a control
mechanism used to hold a door in a fixed position. To use this command as intended, the
output circuit must be wired to the control mechanism so that when the output circuit is
turned on the control mechanism releases the door.
Short form: NCRELEASE
Syntax
[+|–]NCReleaseDoor|NCRELEASE –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on
Notes
The NCReleaseDoor command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the NCReleaseDoor command:
DoorControl
Example
The following rule turns on the door control circuit when an operator presses the
corresponding switch.
[Door Release Switches]
SW 'Release_Door_<n:1-5>' : NCRELEASE -low 'Door_Control_<n>' ;
NSCommonAlarmOff command

Description
Use the NSCommonAlarmOff command to turn off a nonsupervised common alarm output
circuit that was turned on with the NSCommonAlarmOn command.
Short form: NSCAOFF
Syntax
[+|–]NSCommonAlarmOff|NSCAOFF –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The NSCommonAlarmOff command syntax only requires that you specify an object
label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Nonsupervised common alarm output circuits turned on as a result of the FirstAlarm
event cannot be turned off using the NSCommonAlarmOff command.
The NSCommonAlarmOff command does not affect the Form C common alarm
relay on the 3-CPU1 module.
Device types
The following device types respond to the NSCommonAlarmOff command:
NSCommonAlarmOutput
Example
The following rule turns off the nonsupervised common alarm output circuit when an
operator presses the corresponding switch.
[NSCommon Alarm Off Switches]
SW 'NSCom_Alarm_<n:1-5>_Off' : NSCAOFF -low 'NSCom_Alarm_<n>' ;
NSCommonAlarmOn command

Description
Use the NSCommonAlarmOn command to turn on a nonsupervised common alarm output
circuit when an event other than the FirstAlarm event occurs.
Short form: NSCAON
Syntax
[+|–]NSCommonAlarmOn|NSCAON –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on
Notes
The NSCommonAlarmOn command syntax only requires that you specify an object
label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
The NSCommonAlarmOn command does not affect the Form C common alarm relay
on the 3-CPU1 module.
Device types
The following device types respond to the NSCommonAlarmOn command:
NSCommonAlarmOutput
Example
The following rule turns on the nonsupervised common alarm output circuit when an
operator presses the corresponding switch.
[NSCommon Alarm On Switches]
SW 'NSCom_Alarm_<n:1-5>_On' : NSCAON -low 'NSCom_Alarm_<n>' ;
NSCommonMonitorOff command

Description
Use the NSCommonMonitorOff command to turn off a nonsupervised common monitor
output circuit that was turned on with the NSCommonMonitorOn command.
Short form: NSCMOFF
Syntax
[+|–]NSCommonMonitorOff|NSCMOFF –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The NSCommonMonitorOff command only works on circuits with the
The NSCommonMonitorOff command syntax only requires that you specify an object
label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Nonsupervised common monitor output circuits turned on as a result of the
FirstMonitor event cannot be turned off using the NSCommonMonitorOff command.
You cannot use any device to turn off a nonsupervised common monitor output
circuit that upon activation produces a monitor event. For example, you cannot use a
control-display module switch.
Device types
The following device types respond to the NSCommonMonitorOff command:
NSCommonMonitorOutput
Example
The following rule turns off the nonsupervised common monitor output circuit when an
operator presses the corresponding switch.
[General Alarm Response]
Alarm GENALARM : NSCMOFF -low 'Evac_Door' ;
NSCommonMonitorOn command

Description
Use the NSCommonMonitorOn command to turn on a nonsupervised common monitor
output circuit when an event other than the FirstMonitor event occurs.
Short form: NSCMON
Syntax
[+|–]NSCommonMonitorOn|NSCMON –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on
Notes
The NSCommonMonitorOn command syntax only requires that you specify an object
label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the NSCommonMonitorOn command:
NSCommonMonitorOutput
Example
The following rule turns on the nonsupervised common monitor output circuit when an
operator presses the corresponding switch.
[NSCommon Monitor On Switches]
SW 'NSCom_Mon_<n:1-5>_On' : NSCMON -low 'NSCom_Mon_<n>' ;
NSCommonSupervisoryOff command

Description
Use the NSCommonSupervisoryOff command to turn off a nonsupervised common
supervisory output circuit that was turned on with the NSCommonSupervisoryOn command.
Short form: NSCSOFF
Syntax
[+|–]NSCommonSupervisoryOff|NSCSOFF –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The NSCommonSupervisoryOff command syntax only requires that you specify an
object label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Nonsupervised common supervisory output circuits turned on as a result of the
FirstSupervisory event cannot be turned off using the NSCommonSupervisoryOff
command.
The NSCommonSupervisoryOff command does not affect the Form C common
supervisory relay on the 3-CPU1 module.
Device types
The following device types respond to the NSCommonSupervisoryOff command:
NSCommonSupervisoryOutput
Example
The following rule turns off the nonsupervised common supervisory output circuit when an
operator presses the corresponding switch.
[NSCommon Sup Off Switches]
SW 'NSCom_Sup_<n:1-5>_Off' : NSCSOFF -low 'NSCom_Sup_<n>' ;
NSCommonSupervisoryOn command

Description
Use the NSCommonSupervisoryOn command to turn on a nonsupervised common
supervisory output circuit when an event other than the FirstSupervisory event occurs.
Short form: NSCSON
Syntax
[+|–]NSCommonSupervisoryOn|NSCSON –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on
Notes
The NSCommonSupervisoryOn command syntax only requires that you specify an
object label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
The NSCommonSupervisoryOn command does not affect the Form C common
supervisory relay on the 3-CPU1 module.
Device types
The following device types respond to the NSCommonSupervisoryOn command:
NSCommonSupervisoryOutput
Example
The following rule turns on the nonsupervised common supervisory output circuit when an
operator presses the corresponding switch.
[NSCommon Sup On Switches]
SW 'NSCom_Sup_<n:1-5>_On' : NSCSON -low 'NSCom_Sup_<n>' ;
NSCommonTroubleOff command

Description
Use the NSCommonTroubleOff command to turn off a nonsupervised common trouble
output circuit that was turned on with the NSCommonTroubleOn command.
Short form: NSCTOFF
Syntax
[+|–]NSCommonTroubleOff|NSCTOFF –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The NSCommonTroubleOff command syntax only requires that you specify an object
label. Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Nonsupervised common trouble output circuits turned on as a result of the
FirstTrouble event cannot be turned off using the NSCommonTroubleOff command.
The NSCommonTroubleOff command does not affect the Form C common trouble
relay on the 3-CPU1 module.
Device types
The following device types respond to the NSCommonTroubleOff command:
NSCommonTroubleOutput
Example
The following rule turns off the nonsupervised common trouble output circuit when an
operator presses the corresponding switch.
[NSCommon Trbl Off Switches]
SW 'NSCom_Trbl_<n:1-5>_Off' : NSCTOFF -low 'NSCom_Trbl_<n>' ;
NSCommonTroubleOn command

Description
Use the NSCommonTroubleOn command to turn on a nonsupervised common trouble output
circuit when an event other than the FirstTrouble event occurs.
Short form: NSCTON
Syntax
[+|–]NSCommonTroubleOn|NSCTON –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on
Notes
NSCommonTroubleOnSpecifying a priority is optional. If you do not specify a priority,
the system assigns one based on the input event used to activate the rule. For all
events except for the Switch event, the system assigns a low priority. For the Switch
event, the system assigns a high priority.
The NSCommonTroubleOn command does not affect the Form C common trouble
relay on the 3-CPU1 module.
Device types
The following device types respond to the NSCommonTroubleOn command:
NSCommonTroubleOutput
Example
The following rule turns on the nonsupervised common trouble output circuit when an
operator presses the corresponding switch.
[NSCommon Trbl On Switches]
SW 'NSCom_Trbl_<n:1-5>_On' : NSCTON -low 'NSCom_Trbl_<n>' ;
Off command

Description
Use the Off command to restore a system hardware component, circuit, or logic group.
Short form: none
Syntax
[+|–]Off –priority device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
device_type specifies the device type of the device to turn off
object_label specifies the label of the device to turn off
Notes
The Off command syntax requires that you specify a device type, an object label, or
both.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the Off command:

2 Stage Signal Gatevalve NSCommonSupervisoryOutput

AccessDoorControl GenAlarm G_Audible NSCommonTroubleOutput
AccessOutput G_Visible NSVisibleOutput
ACFail G_AudibleVisible Power
Audible G_CommonAlarmOutput Pull
CMSNonsupervisedOutput G_CommonMonitorOutput Security
CMSSupervisedOutput G_CommonSupervisoryOutput ServiceGroup
CommonAlarmOutput Guard Smoke
CommonMonitorOutput Heat SmokePre
CommonSupervisoryOutput LED SmokeVfy
Control_Center_ALO LogicalOutput SprinklerSupervisory
ControlledAuxOutput Monitor SupervisedOutput
DamperControl NonsupervisedOutput Supervisory
DamperFeedback NSAudibleOutput Tamper
DoorControl NSCommonAlarmOutput Temperature
DoorFeedback NSCommonMonitorOutput TimedAccessOutput
FanControl Visible
FanFeedback Waterflow
Firephone

SIGA-IO and SIGA-MIO modules with the following device types respond to the Off
command:

DamperFeedback Guard Smoke

DoorFeedback Heat SprinklerSupervisory
FanFeedback Monitor Supervisory
Gatevalve Power Tamper
GenAlarm Pull Temperature
Security Waterflow
Example
The following rule turns off all the horns on a given floor when an operator presses the
corresponding switch.
[Horn Off Switches]
SW 'Horns_On_Floor_<n:1-5>' : Off -low AUD 'Floor<n>_Horn*' ;
OffGuard command

Description
Use the OffGuard command to cancel a specific guard patrol tour. The OffGuard command
contains two parts. The first part of the command (OffGuard) identifies the GuardPatrol
group and the second part (Route) identifies the route number.
Short form: none
Syntax
[+|–]OffGuard 'guard_label' Route route_id
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
guard_label specifies the label of the Guard Patrol group
route_id specifies the route number of the guard patrol tour to turn off
Example
The following rule turns off the guard patrol tour when an operator presses the control-
display module switch.
[GuardPatrol Route Off Switches]
SW 'Group_1_Tour_1_Off' : OffGuard 'Guard_Patrol_Group1' Route 1 ;
On command

Description
Use the On command to turn on control-display module LEDs, output circuits, and the dry
contact relay on SIGA–IO and SIGA–MIO modules configured as alarm, active latching, or
nonlatching input circuits.
Short form: none
Syntax
[+|–]On –priority device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
device_type specifies the device type of the device to turn on
object_label specifies the label of the device to turn on
Notes
The On command syntax requires that you specify a device type, an object label, or
both
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the On command:

2 Stage Signal Gatevalve NSCommonSupervisoryOutput

AccessDoorControl GenAlarm G_Audible NSCommonTroubleOutput
AccessOutput G_Visible NSVisibleOutput
ACFail G_AudibleVisible Power
Audible G_CommonAlarmOutput Pull
CMSNonsupervisedOutput G_CommonMonitorOutput Security
CMSSupervisedOutput G_CommonSupervisoryOutput ServiceGroup
CommonAlarmOutput Guard Smoke
CommonMonitorOutput Heat SmokePre
CommonSupervisoryOutput LED SmokeVfy
Control_Center_ALO LogicalOutput SprinklerSupervisory
ControlledAuxOutput Monitor SupervisedOutput
DamperControl NonsupervisedOutput Supervisory
DamperFeedback NSAudibleOutput Tamper
DoorControl NSCommonAlarmOutput Temperature
DoorFeedback NSCommonMonitorOutput TimedAccessOutput
FanControl Visible
FanFeedback Waterflow
Firephone

SIGA-IO and SIGA-MIO modules with the following device types respond to the On
command:

DamperFeedback Guard Smoke

DoorFeedback Heat SprinklerSupervisory
FanFeedback Monitor Supervisory
Gatevalve Power Tamper
GenAlarm Pull Temperature
Security Waterflow
Example
The following rule turns on all the horns on a given floor when an operator presses the
corresponding switch.
[Horn On Switches]
SW 'Horns_On_Floor_<n:1-5>' : On -low AUD 'Floor<n>_Horn*' ;
OnGuard command

Description
Use the OnGuard command to start a specific guard patrol tour. The OnGuard command
contains two parts. The first part of the command (OnGuard) identifies the GuardPatrol
group and the second part (Route) identifies the route number.
Short form: none
Syntax
[+|–]OnGuard 'guard_label' Route route_id
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
guard_label specifies the label of the Guard Patrol group
route_id specifies the route number of the guard patrol tour to turn on
Example
The following rule turns on the guard patrol tour when an operator presses the control-
display module switch.
[GuardPatrol Route On Switch]
SW 'Group_1_Tour_1_On' : OnGuard 'Guard_Patrol_Group1' Route 1 ;
Open command

Description
Use the Open command to turn on an output circuit that connects to a control mechanism
used to operate a damper. To use this command as intended, the output circuit must be
wired to the control mechanism so that when the output circuit is turned on the control
mechanism places the damper in the open position.
Short form: none
Syntax
[+|–]Open –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn on
Notes
The Open command syntax only requires that you specify an object label. Specifying
a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the Open command:
DamperControl
Example
The following rule turns on the damper control circuit when an operator presses the
corresponding switch.
[Damper Open Switches]
SW 'Open_Dmpr_<n:1-5>' : Open -low 'Dmpr_Control_<n>' ;
PrealarmTest command

Description
Use the PrealarmTest command to place a signature sensor into pre-alarm for verification
testing. This command requires a 3-SSDC1 or 3-SDDC1 loop controller and firmware
version 3.4 or later.
Note: The PrealarmTest command puts the device into a pre-alarm condition and activates
its programmed output responses.
Short form: PALMTST
Syntax
[+|–]PrealarmTest|PALMTST device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the signature sensor you want to test
object_label specifies the label of the signature sensor to test
Device types
The following device types respond to the PrealarmTest command:
SmokePre
Example
The following rule activates the PrealarmTest function on all smoke sensors on floor 1 when
an operator presses the switch labeled Fl1_PrealarmTest_Smk.
[PrealarmTest Smk Fl1]
SW 'Fl1_PrealarmTest_Smk' : PALMTST 'Fl1_Smk*' ;
ReleaseDoor command

Description
Use the ReleaseDoor command to turn off an output circuit that connects to a control
mechanism used to hold a door in a fixed position. To use this command as intended, the
output circuit must be wired to the control mechanism so that when the output circuit is
turned off the control mechanism releases the door.
Short form: RELEASE
Syntax
[+|–]ReleaseDoor|RELEASE –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the output circuit to turn off
Notes
The ReleaseDoor command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the ReleaseDoor command:
DoorControl
Example
The following rule turns off the door control circuit when an operator presses the
corresponding switch.
[Door Release Switches]
SW 'Release_Door_<n:1-5>' : RELEASE -low 'Door_Control_<n>' ;
RemoteAltSensingOn command

Description
Use the RemoteAltSensingOn command to change smoke detector sensitivity, alarm verify,
and prealarm options to their alternate settings when their primary settings are active.
The RemoteAltSensingOn command changes these options on every panel in the system or
in a group of panels.
Short form: RASON
Syntax
[+|–]RemoteAltSensingOn|RASON 'cabinet_label';
— or —
[+|–]RemoteAltSensingOn|RASON 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
cabinet_label specifies the panel whose alternate sensitivity and alarm verification
settings you want to activate.
routing_label specifies the label of the network routing group containing the panels
whose alternate sensitivity and alarm verification settings you want to activate.
Notes
The RemoteAltSensitivityOn command syntax does not require that you specify a
device type or an object label.
You can use wildcards to substitute characters in the cabinet label but not in the
routing label.
The RemoteAltSensingOn command is typically used with a time control to
automatically change smoke detector settings or with a control-display module
switch to manually override them.
Device types
The following device types respond to the RemoteAltSensitivityOn command:
AlternateSensitivityMode
Example
The following rule activates the alternate smoke detector settings on the panel labeled
Cab2, when the time control labeled Mon_Fri_Non_Work_Hrs goes active.
[Remote Alt Sensing On]
TIME 'Mon_Fri_Non_Work_Hrs' : RASON 'Cab2' ;
RemoteAltSensingOff command

Description
Use the RemoteAltSensingOff command to change smoke detector sensitivity, alarm verify,
and prealarm options to their primary settings when their alternate settings are active.
The RemoteAltSensingOff command changes these options on selected panels in the
system or in a group of panels.
Short form: RASOFF
Syntax
[+|–]RemoteAltSensingOff|RASOFF 'cabinet_label';
— or —
[+|–]RemoteAltSensingOff|RASOFF 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
cabinet_label specifies the panel whose primary sensitivity and alarm verification
settings you want to activate.
routing_label specifies the label of the network routing group containing the panels
whose primary sensitivity and alarm verification settings you want to activate.
Notes
The RemoteAltSensingOff command syntax does not require that you specify a
device type or an object label.
You can use wildcards to substitute characters in the cabinet label but not in the
routing label.
Typically, you use the RemoteAltSensingOff command with a toggle switch to
manually override the alternate settings.
Device types
The following device types respond to the RemoteAltSensingOff command:
AlternateSensitivityMode
Example
The following rule deactivates the alternate smoke detector settings and returns to the
primary detector settings on the panel labeled Cab2, when the time control labeled
Mon_Fri_Normal_Work_Hrs goes active.
[Remote Alt Sensing Off]
TIME 'Mon_Fri_Normal_Work_Hrs' : RASOFF 'Cab2' ;
RemoteAltSensitivityOff command

Description
Use the RemoteAltSensitivityOff command to change smoke detector Sensitivity, Alarm
Verify, and Pre Alarm properties to their primary settings when their alternate settings are
active.
The RemoteAltSensitivityOff command changes smoke detector Sensitivity, Alarm Verify,
and Pre Alarm properties on selected panels in the system or in a group of panels.
Short form: RASOFF
Syntax
[+|–]RemoteAltSensitivityOff|RASOFF 'cabinet_label';
— or —
[+|–]RemoteAltSensitivityOff|RASOFF 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
cabinet_label specifies the panel whose primary sensitivity and alarm verification
settings you want to activate
routing_label specifies the label of the network routing group containing the panels
whose primary sensitivity and alarm verification settings you want to activate
Notes
The RemoteAltSensitivityOff command syntax does not require that you specify a
device type or an object label.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
Typically, you use the RemoteAltSensitivityOff command with a toggle switch to
manually override the alternate settings.
Device types
The following device types respond to the RemoteAltSensitivityOff command:
AlternateSensitivity
Example
The following rule overrides the smoke detector alternate settings and restores the primary
settings on the panel labeled Cab2 when an operator presses the switch labeled
Alt_Sens_Off.
[Remote Alt Sensitivity Off Switch]
SW 'C2_AltSens_On' : RASOFF 'Cab2' ;
RemoteAltSensitivityOn command

Description
Use the RemoteAltSensitivityOn command to change smoke detector Sensitivity, Alarm
Verify, and Pre Alarm properties to their alternate settings when their primary settings are
active.
The RemoteAltSensitivityOn command changes smoke detector Sensitivity, Alarm Verify,
and Pre Alarm properties on every panel in the system or in a group of panels.
Short form: RASON
Syntax
[+|–]RemoteAltSensitivityOn|RASON 'cabinet_label';
— or —
[+|–]RemoteAltSensitivityOn|RASON 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
cabinet_label specifies the panel whose alternate sensitivity and alarm verification
settings you want to activate
routing_label specifies the label of the network routing group containing the panels
whose alternate sensitivity and alarm verification settings you want to activate
Notes
The RemoteAltSensitivityOn command syntax does not require that you specify a
device type or an object label.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
The RemoteAltSensitivityOn command is typically used with a time control to
automatically change smoke detector settings or with a control-display module
switch to manually override them.
Device types
The following device types respond to the RemoteAltSensitivityOn command:
AlternateSensitivity
Example
The following rule activates the alternate smoke detector settings on the panel labeled
Cab2 when the time control labeled Mon_Fri_Non_Work_Hrs goes active.
[Remote Alt Sensitivity On]
TIME 'Mon_Fri_Non_Work_Hrs' : RASON 'Cab2' ;
RemoveBypass command

Description
Use the RemoveBypass command to resume monitoring of SecurityAlarm events generated
by a device. When a device was bypassed using the Bypass command, the RemoveBypass
command removes the bypass.
The partition must be disarmed for this command to have any effect. Devices in an armed
partition cannot have a bypass removed.
Short form: REMBYP
Syntax
[+|–]RemoveBypass|REMBYP device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
device_type specifies the device type of the device from which you want to remove
a bypass
object_label specifies the label of the device from which you want to remove a
bypass
Notes: The RemoveBypass command syntax requires that you specify a device type or an
object label, or both.
Device types
The following device types respond to the RemoveBypass command:
Security24Hour
SecurityDay
SecurityIMonitor
SecurityInterior
SecurityPerimeter
SecurityPMonitor
Example
This rule uses a switch to bypass then remove the bypass from the door to a stockroom. In
effect it provides a momentary bypass of the door to allow controlled entry to or exit from
the room.
Switch 'Stockroom_Access' :
+Bypass SecurityIMonitor 'Stockroom_Door_Contact',
–RemoveBypass SecurityIMonitor 'Stockroom_Door_Contact',
Delay 60 ;
Reset command

Description
Use the Reset command to program a momentary switch on a control-display module to
activate the Reset function. Activating the Reset function clears the panel of any latched off-
normal conditions that have been restored.
Short form: none
Syntax
[+|–]Reset 'cabinet_label';
— or —
[+|–]Reset 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
cabinet_label specifies the panel whose Reset function you want to activate
routing_label specifies the label of the network routing group containing the panels
whose Reset function you want to activate
Notes
The Reset command syntax does not require that you specify a device type or an
object label.
You must configure the switch used to execute the Reset command as a momentary
switch.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
Device types
The following device types respond to the Reset command:
Reset
Example
The following rule activates the Reset function on the panel labeled Cab2 when an operator
presses the switch labeled C2_Reset_On.
[Reset Cntrl]
SW 'C2_Reset_On' : Reset 'Cab2' ;
ResetPartition command

Description
Use the ResetPartition command to reset a partition. You can use this command to emulate
the Partition Restore command available on the LCD menu, or the Reset Security command
available on KPDISP menu. When restoring a partition, ResetPartition updates the status of
all points in the partition and clears security event messages from the KPDISP queues.
You could use the ResetPartition command to program a momentary switch on a control-
display module to reset a partition.
Short form: RSTPART
Syntax
[+|–]ResetPartition|RSTPART device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the partition you want to reset
object_label specifies the label of the partition you want to reset
Notes
The ResetPartition command syntax requires that you specify a device type or an
object label, or both.
The ResetPartition command can only be used with a device type of
The partition must be disarmed before it can be reset.
Device types
The following device types respond to the ResetPartition command:
Partition
Network performance
This command can result in a high volume of network messages. If you use a single
response (for example, a switch) to control several partitions, make sure that you don't
degrade network performance by generating a high volume of messages.
The number of messages exchanged by the panels depends on:
The number of partitions being controlled
The number of panels in the network
For example, if you reset 10 partitions on a 10 panel network, 100 messages are
exchanged. If you reset 50 partitions on a 40 panel network, then 2,000 messages are
exchanged. Resetting 250 partitions on a 60 panel network exchanges 15,000 messages.
While this amount of network traffic does not harm the network, the time it takes to process
the information can delay the processing of other network messages.
We recommend that you limit number of partitions controlled by a single response
according this formula:
P < 320 / N
Where:
P = number of partitions
N = number of panels
Examples: For a 20 panel network, limit commands to 16 partitions. For a 64 panel
network limit, commands to 5 partitions.
In practice, you would write a rule with several output commands. Each command would
control a limited number of partitions (according to the formula). You would also place a 10
second delay between each command, to make sure all messages for one command were
processed before the next command was executed.
This limitation does not apply to the Disarm, Away, and Stay commands. These commands
do not require a high volume of messages.
Example
The following rule resets the common area partitions in a multi-story building. You must
configure the switch as a momentary switch.
[Manually Reset Common Areas]
SW 'Reset_Common' : RSTPART PARTITION 'Common_*' ;
Restore command

Description
Use the Restore command to restore a command list. Command lists do not have states.
Activating a command list causes its Activation rules to execute once in the activation
direction. Restoring a command list causes its Activation rules to execute once in the
restoral direction.
Short form: none
Syntax
[+|–]Restore 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
object_label specifies the label of the command list to restore
Device types
The following device types respond to the Restore command:
AND
CmdList
Example
The following rule activates the command list labeled OnAlarmCmdList when the rule
activates, and restores OnAlarmCmdList when the rule restores.
[Smoke Alarm Response]
Alarm SMK 'Level_<n:0-64>_Smk' :
On AUD 'Level_<n>_Horn',
On VIS 'Level_<n>_Strobe',
+Activate 'OnAlarmCmdList',
–Restore 'OnAlarmCmdList' ;
RestoreRemoteReadLock command
Use the RestoreRemoteReadLock command to allow IP read communications between the
CU and the panel. The default setting is to allow read communications (remote read
capability is unlocked).
If you are using IP connectivity, you may want to prohibit IP communications with the panel
on a normal basis to help prevent "denial of service" attacks from affecting the performance
of the panel. You can disable panel IP communications by using the
ActivateRemoteReadLock command.
Short form: RRRL
Syntax
[+|–]RestoreRemoteReadLock|RRRL 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
routing_label specifies the label of the network routing group containing the panels
for which you want to allow remote reads.
Device types
The following device types respond to the RestoreRemoteReadLock command:
None
Example
The following rule allows read capability between the CU and all cabinets, when an operator
presses the Restore Remote Read Lock switch.
[Remote Read ON for all cabs]
SW 'Restore Remote Read Lock' : RRRL 'All Cabinets';
RestoreRemoteWriteUnlock command
Use the RestoreRemoteWriteUnlock command to block write capability using IP
communications between the CU and the panel. The default setting is to block write
communications (remote write capability is locked).
If you are using IP connectivity, you can disable IP communications with the panel on a
normal basis to block messages that write information to the panel. (This is a security
measure that can help address UL's requirement for programming a protected-premises
unit.) You can then enable panel IP communications when needed by
using ActivateRemoteWriteUnlock command.
Note: After 15 minutes with no write activity, the panel automatically returns to the default,
locked state.
Short form: RRWU
Syntax
[+|–]RestoreRemoteWriteUnlock|RRWU 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
routing_label specifies the label of the network routing group containing the panels
for which you want to block remote write operations.
Device types
The following device types respond to the RestoreRemoteWriteUnlock command:
None
Example
The following rule blocks write capability between the CU and all cabinets, when an
operator presses the Restore Remote Write Unlock switch.
[Remote Write OFF for all cabs]
SW 'Restore Remote Write Unlock' : RRWU 'All Cabinets';
Send command

Description
Use the Send command to send a message to a central monitoring station through the 3-
MODCOM.
Short form: none
Syntax
[+|-]Send 'account_label' [Message|MSG] "text" [Priority|PRI ppp] [Confirm|CNF
'cmd_list_label'];
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
Note: This option lets you select settings outside the range specified in UL 864 and
CAN/ULC-S527. For more details see UL 864 and ULC-S527 programming
requirements.
account_label specifies the account (and thus the receiver) to which the message is
being sent
Message is an optional keyword to identify the text portion as the message being
sent
text specifies the actual body of the message sent to the receiver. The message
format depends on the transmission protocol that the central monitoring station
requires.
Priority ppp specifies the order of importance this command has over other
commands affecting the same output device. Valid priority levels are any whole
number between 1 and 255, inclusive. 1 is the highest priority and 255 is the lowest.
Note: This option lets you select settings outside the range specified in UL 864 and
CAN/ULC-S527. For more details see UL 864 and ULC-S527 programming
requirements.
Confirm 'cmd_list_label' specifies the command list to activate on the successful
transmission of the message. Specifying a confirmation command list is optional.
Note: Specifying a priority is optional. If you do not specify a priority, the system assigns
priority values based on the input event used to activate the rule. If you do specify priorities,
be sure to use the same priority for the activation and restore messages of each input
event. This ensures that multiple activation and restore messages from the same point do
not pass one another.
Here is a list of the priority substitution default values for each event type:

Event Type SDU SDU Event Type SDU SDU

CID TAP CID TAP
Priority Priority Priority Priority
Alarm 10 205 DisabledActive 200 235
AlarmHeat 10 205 Drill 200 235
AlarmSmoke 10 205 FirstMonitor 200 235
Evacuation 10 205 LocalMonitor 200 235
FirstAlarm 10 205 MaintenanceAlert 200 235
LocalAlarm 10 205 Monitor 200 235
SystemAlarm 10 205 ObjectRunning 200 235
COAlarm 20 210 PreAlarm 200 235
GuardPatrol 20 210 R1 200 235
FirstSupervisory 50 220 R2 200 235
SprinklerSupervisory 50 220 R3 200 235
Supervisory 50 220 RelayConfirmation 200 235
COSupervisory 60 225 Reset 200 235
InterlockFailure 60 225 Security 200 235
AccessTrouble 150 230 SecurityAlarm 200 235
ACFail 150 230 SecurityAway 200 235
Acknowledge 150 230 SecurityAwayFail 200 235
AlarmSilence 150 230 SecurityDisabled 200 235
Bypassed 150 230 SecurityDisarmed 200 235
CMSFirstTrouble 150 230 SecurityDisarmedAlarm 200 235
Disabled 150 230 SecurityDisarmedFault 200 235
DisabledTrouble 150 230 SecurityDisarmedTamper 200 235
EndOfLife 150 230 SecurityEntryTimer 200 235
FirstDisable 150 230 SecurityExitTimer 200 235
FirstTrouble 150 230 SecurityFault 200 235
GroundFault 150 230 SecurityMaintenance 200 235
LocalTrouble 150 230 SecurityStay 200 235
SecurityBypassed 150 230 SecurityStayFail 200 235
ServiceGroupActive 150 230 SecurityTamper 200 235
SystemTrouble 150 230 SecurityTroubleClosing 200 235
Trouble 150 230 ServiceGroup 200 235
TwoStageInteractive 150 230 SignalSilenceInhibit 200 235
AlarmVerify 200 235 Startup 200 235
AllCall 200 235 StationActivation 200 235
AllCallMinus 200 235 Switch 200 235
AlternateSensitivityMode 200 235 SystemMonitor 200 235
AutoAlmsilExpiration 200 235 TimeControl 200 235
CallIn 200 235 TwoStageTimerExpiration 200 235
COMonitor 200 235
Device types
The following device types respond to the Send command:
CmdList
Example
The following rule sends alarm and restore messages to the CMS, depending on the state
of the smoke detectors on each floor. The SIA DCS protocol is used.
[CMS_notification_fire_alarms]
ALARM 'Floor_<n:1-5>_Smoke' :
+SEND 'CMS' "FA<n>" ,
-SEND 'CMS' "FH<n>" ;
See also
Contact ID codes
SIA DCS codes
SIA DCS substitution strings
TAP substitution strings
SendEMail command

Description
Use the SendEMail command to send email or SMS text messages to an SMTP server
through the Ethernet card.
Short form: none
Syntax
[+|-] Sendemail 'Account_Label' [Message|MSG] “$(location) text” [Priority|PRI ppp]
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
Account_label specifies the email account (email server) to which the message is
being sent.
Message or MSG is an optional keyword. The “text” specified will be appended to
the email message body with the corresponding event. The same SendEmail
command is used for texting as well; however, if the email address is configured to
be a text message, then the text portion of the rule will be ignored.
Note: This parameter contains an optional “$(location)” element. When “$(location)” is
used, the message will contain the location text configured in the SDU, which is the
Message text shown in the Configure > Objects Configuration tab.
Priority or PRI ppp specifies the order of importance this command has over other
commands affecting the same output device. Valid priority levels are any whole
number between 1 and 255, inclusive. 1 is the highest priority and 255 is the lowest.
Note: Specifying a priority is optional. If you do specify a priority, be sure to use the same
priority for the activation and restore messages of each input event. This ensures that
multiple activation and restore messages from the same point do not pass one another. If
you do not specify a priority, the system assigns priority values based on the input event
used to activate the rule.
Here is a list of the priority substitution values:

Fire Alarm event 10

Supervisory Alarm event 10
Security Holdup event 30
Guard Patrol event 60
Security Alarm event 50
Security Tamper event 50
Security Trouble event 50
Check-in Group event 60
Smoke Prealarm event 150
Smoke Verify event 150
Fire Trouble event 100
Monitor Trouble event 100
Supervisory Trouble event 100
Monitor event 150
Security Maintenance event 150
Device types
The following device types respond to the SendEMail command:
EmailAccount
Examples
The following rule sends alarm and restore email messages, depending on the state of the
smoke detectors on each floor.
[Email_notification_fire_alarms]
ALARM 'Floor_<n:1-5>_Smoke':
+SENDEMAIL 'Email_Account_1',
-SENDEMAIL 'Email_Account_1';
See also
Contact ID codes
SendIP command

Description
Use the SendIP command to send events messages to a remote site through the Ethernet
card.
Short form: none
Syntax
[+|-]SendIP 'Account_Label' MSG 'CID Text' [Priority | PRI ppp] [CNF 'Command List
Label']
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
Account_label specifies the IP account to which the message is being sent.
MSG is an optional keyword to identify the CID Text portion as the message being
sent.
CID Text specifies the actual body of the message.
Contact ID messages are typically 16-digit hexadecimal strings that include predefined
event codes and variable account and address information.
ACCT MT QEEE GG PPP S
Where:
ACCT = Account number. A four-digit account number (hex 0-9, B-F) defined in the
SDU. The account number links a company to a receiver. You must include the
account number in your rule.
MT = Message type. This two-digit code identifies the Contact ID message type to
the receiver. The IP receiver service sends this portion (with value = 18)
automatically.
Q = Event qualifier. A one-digit code. Use 1 for activation messages and 3 for
restoral messages. You must include the event qualifier as part of your message.
EEE = Event code. A three-digit code (hex 0-9, B-F). The codes and descriptions
are given in the topic Contact ID codes.
GG = Group, zone, or partition number. A two-digit number that identifies a group,
zone, or partition (hex 0-9, B-F). Use 00 when no group, zone, or partition
information applies.
PPP = Point ID (for event reports) or user ID (for open or close reports ). A three-
digit number (hex 0-9,B-F ). Use 000 when no point or user information applies.
S = Checksum digit. one-digit hex checksum calculated by the IP receiver service.
CNF 'cmd_list_label' specifies a user-defined command list to activate on the
successful transmission of the message. Specifying a confirmation command list is
optional. Use the Activate and Restore commands to activate and restore a
command list.
Priority ppp specifies the order of importance this command has over other
commands affecting the same output device. Valid priority levels are any whole
 number between 1 and 255, inclusive. 1 is the highest priority and 255 is the lowest.
Note: Specifying a priority is optional. If you do specify a priority, be sure to use the same
priority for the activation and restore messages of each input event. This ensures that
multiple activation and restore messages from the same point do not pass one another. If
you do not specify a priority, the system assigns priority values based on the input event
used to activate the rule.
Here is a list of the priority substitution default values for each event type:

Event Type SDU SDU Event Type SDU SDU

CID TAP CID TAP
Priority Priority Priority Priority
Alarm 10 205 DisabledActive 200 235
AlarmHeat 10 205 Drill 200 235
AlarmSmoke 10 205 FirstMonitor 200 235
Evacuation 10 205 LocalMonitor 200 235
FirstAlarm 10 205 MaintenanceAlert 200 235
LocalAlarm 10 205 Monitor 200 235
SystemAlarm 10 205 ObjectRunning 200 235
COAlarm 20 210 PreAlarm 200 235
GuardPatrol 20 210 R1 200 235
FirstSupervisory 50 220 R2 200 235
SprinklerSupervisory 50 220 R3 200 235
Supervisory 50 220 RelayConfirmation 200 235
COSupervisory 60 225 Reset 200 235
InterlockFailure 60 225 Security 200 235
AccessTrouble 150 230 SecurityAlarm 200 235
ACFail 150 230 SecurityAway 200 235
Acknowledge 150 230 SecurityAwayFail 200 235
AlarmSilence 150 230 SecurityDisabled 200 235
Bypassed 150 230 SecurityDisarmed 200 235
CMSFirstTrouble 150 230 SecurityDisarmedAlarm 200 235
Disabled 150 230 SecurityDisarmedFault 200 235
DisabledTrouble 150 230 SecurityDisarmedTamper 200 235
EndOfLife 150 230 SecurityEntryTimer 200 235
FirstDisable 150 230 SecurityExitTimer 200 235
FirstTrouble 150 230 SecurityFault 200 235
GroundFault 150 230 SecurityMaintenance 200 235
LocalTrouble 150 230 SecurityStay 200 235
SecurityBypassed 150 230 SecurityStayFail 200 235
ServiceGroupActive 150 230 SecurityTamper 200 235
SystemTrouble 150 230 SecurityTroubleClosing 200 235
Trouble 150 230 ServiceGroup 200 235
TwoStageInteractive 150 230 SignalSilenceInhibit 200 235
AlarmVerify 200 235 Startup 200 235
AllCall 200 235 StationActivation 200 235
AllCallMinus 200 235 Switch 200 235
AlternateSensitivityMode 200 235 SystemMonitor 200 235
AutoAlmsilExpiration 200 235 TimeControl 200 235
CallIn 200 235 TwoStageTimerExpiration 200 235
COMonitor 200 235
Device types
The following device types respond to the SendIP command:
IPAccount
Examples
The following rule sends alarm and restore messages, depending on the state of the smoke
detectors on each floor.
[IP_Dialer_smoke_alarm]
ALARM 'N_01_Slot_4_SMK_1':
+SENDIP 'IP_ACCOUNT_xx_xx' Msg "111100001" PRI 50 ,
-SENDIP 'IP_ACCOUNT_xx_xx' Msg "311100001" PRI 99 ;
Where xx is the cabinet number
See also
Contact ID codes
SensorBypassOff command

Description
Use the SensorBypassOff command to turn off an existing bypass condition that has
inhibited the smoke element on a SIGA2-PHS. After issuing this command, both the heat
and smoke (photo) elements of the PHS return to normal operation (activation messages
for either condition appear on the LCD).
When the user turns bypass off for a SIGA2-PHS photo element, the panel removes the
"SensorBypass active" trouble message from the LCD.
To bypass the photo element on a SIGA2-PHS, use the SensorBypassOn command.
When a SensorBypass command is manually activated from the LCD or by a switch rule,
the event is stored in a marketplace-dependent queue. Refer to the table below to
determine which queue is used for your marketplace.

Queue
Marketplace Trouble Trouble (All Other Monitor
Others)

Arabic X

Asia X

Australia AS4428 X

Australia AS7240 X

Canada X

China X

Europe X

International X

Middle East X

New Zealand X

Singapore X

US X

Note: This command works only with the SIGA2-PHS detector; it does not function with the
SIGA-PHS detector. This option also requires both:
SDU version 04.00.00 or later
A 3-SSDC1 or 3-SDDC1 loop controller running application code version 04.00.00
and bootloader code version 04.00.00 or later
Short form: SBYPOFF
Syntax
[+|–]SensorBypassOff|SBYPOFF device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
device_type specifies the device type of the device whose sensor you no longer
want to bypass (Supervisory).
object_label specifies the label of the SIGA2-PHS device you no longer want to
bypass.
Device types
The following device type responds to the SensorBypassOff command:
Supervisory
Note: The SensorBypassOff command does not apply to all Supervisory device types; it
works only with the SIGA2-PHS detector using Supervisory as the device type.
Example
This rule activates the previously-disabled photo element of the PHS devices on the second
floor, when a user presses the switch labeled Smoke_Bypass_Off.
[turn smoke bypass on for 2nd floor]
SW 'Smoke_Bypass_Off' : SBYPOFF 'PHS_Flr_002' ;
SensorBypassOn command

Description
Use this command to keep the photo element on the SIGA2-PHS detector from generating
supervisory messages on the LCD, while still using the heat element of the same SIGA2-
PHS. With this condition on, the system displays an alarm message only if the heat element
activates. For example, if a large event is planned that allows smoking or pyrotechnics in a
ballroom that has SIGA2-PHS detectors installed, you could bypass the smoke element to
prevent false alarms while still using the heat element to detect a fire.
When the user bypasses a SIGA2-PHS photo element, the panel displays a "SensorBypass
active" trouble message on the LCD. If the photo element activates, it appears as
"Disabled Active Event" in reports even though it does not appear on the LCD.
To remove an existing bypass and return to normal (dual) functioning for a SIGA2-PHS
detector, use the SensorBypassOff command.
When a SensorBypass command is manually activated from the LCD or by a switch rule,
the event is stored in a marketplace-dependent queue. Refer to the table below to
determine which queue is used for your marketplace.

Queue
Trouble (All
Marketplace Trouble Other Monitor
Others)

Arabic X

Asia X

Australia AS4428 X

Australia AS7240 X

Canada X

China X

Europe X

International X

Middle East X

New Zealand X

Singapore X

US X

Note: This command works only with the SIGA2-PHS detector; it does not function with the
SIGA-PHS detector. This option also requires both:
SDU version 04.00.00 or later
 A 3-SSDC1 or 3-SDDC1 loop controller running application code version 04.00.00
and bootloader code version 04.00.00 or later
Note: This command works only on SIGA2-PHS detectors that have been set to "Photo is
Supervisory | Heat is AlarmHeat." It does not work in alternate operation.
Short form: SBYPON
Syntax
[+|–]SensorBypassOn|SBYPON device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
device_type specifies the device type of the device whose sensor you want to
bypass (Supervisory).
object_label specifies the label of the SIGA2-PHS device whose smoke element you
want to bypass.
Note: The SensorBypassOn command syntax requires that you specify a device type or an
object label, or both.
Device types
The following device type responds to the SensorBypassOn command:
Supervisory
Note: The SensorBypassOn command does not apply to all Supervisory device types; it
works only with the SIGA2-PHS detector using Supervisory as the device type.
Example
This rule bypasses the photo element of the PHS devices on the second floor, when a user
presses the switch labeled Smoke_Bypass_On.
[turn smoke bypass on for 2nd floor]
SW 'Smoke_Bypass_On' : SBYPON 'PHS_Flr_002' ;
SignalAlert command

Description
Use the SignalAlert command to activate the Edwards Analog sounder to sound an alert
signal.
Short form: SIGALERT
Syntax
[+|–]SIGALERT –priority device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
device_type specifies the device type for the signal alert command
object_label specifies the label for the signal alert command
Notes
The SignalAlert command syntax requires that you specify a device type, an object
label, or both.
We recommend that you use a different priority for SignalAlert commands and
SignalEvacuate commands. This allows the panel to track signal types by priority. If
a sounder is active in alert state at a low priority, and then switched to evacuate
state at a high priority, and then off at a high priority, the system will restore the alert
state.
Device types
The following device types respond to the SignalAlert command:
2_Stage_Signal
Example
The following rule activates all sounders on the floor above and floor below the smoke
alarm floor.
[Alarm Signal Alert]
Alarm Smk 'Fl<N:1-9>_Smk*' : SIGALERT 'FL<N+1>_Sounder*' ,
SIGALERT 'FL<N-1>_Sounder*' ;
SignalEvacuate command

Description
Use the SignalEvacuate command to activate the Edwards Analog sounder to sound an
evacuate signal.
Short form: SIGEVAC
Syntax
[+|–]SIGEVAC –priority device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
device_type specifies the device type for the signal evacuate command
object_label specifies the label for the signal evacuate command
Notes
The SignalEvacuate command syntax requires that you specify a device type, an
object label, or both.
We recommend that you use a different priority for SignalAlert commands and
SignalEvacuate commands. This allows the panel to track signal types by priority. If
a sounder is active in alert state at a low priority, and then switched to evacuate
state at a high priority, and then off at a high priority, the system will restore the alert
state.
Device types
The following device types respond to the SignalEvacuate command:
2 Stage Signal
Example
The following rule activates all sounders on the floor of the smoke alarm.
[Alarm Signal Evacuate]
Alarm Smk 'Fl<N:1-9>_Smk*' : SIGEVAC 'FL<N>_Sounder*' ;
SignalOff command

Description
Use the SignalOff command to turn off the alert and evacuate signals on Edwards Analog
sounders.
Short form: SIGOFF
Syntax
[+|–]On –priority device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
device_type specifies the device type for the signal off command
object_label specifies the label for the signal off command
Notes
The SignalOff command syntax requires that you specify a device type, an object
label, or both.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the SignalOff command:
2 Stage Signal
Example
The following rule turns off all sounders when an operator presses the switch labeled
SW1_SignalOff.
[SignalOff Switch]
SW 'SW1_SignalOff' : SIGOFF 'FL*_Sounder*' ;
SlowBlink command

Description
Use the SlowBlink command to turn on a control-display module's light-emitting diode and
have it blink at a slow interval.
Short form: SLOW
Syntax
[+|–]SlowBlink|SLOW –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the LED to turn on
Notes
The SlowBlink command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the SlowBlink command:
LED
Example
The following rule turns on the LED label R2_LED during the 2nd phase of the Reset cycle.
[Ann_Reset_2nd_Phase]
R2 : SLOW -low 'R2_LED' ;
Stay command

Description
Use the Stay command to arm a partition perimeter (interior devices are not armed). The
partition state must be Disarmed for the Stay command to work. You cannot change the
partition state from Away to Stay.
This command changes the partition state to Stay unconditionally, without determining the
current state of devices in the partition.
Short form: none
Syntax
[+|–]Stay device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the partition you want to arm
object_label specifies the label of the partition you want to arm
Notes
The Stay command syntax requires that you specify a device type or an object label,
or both.
The Stay command can only be used with a device type of
Device types
The following device types respond to the Stay command:
Partition
Example
The following rule arms (stay) the common area partitions in a multi-story building.
[Manually Arm-Stay Common Areas]
SW 'Arm_Stay_Common' : Stay PARTITION 'Common_*' ;
See also
Away command
ConditionalAway command
ConditionalStay command
Disarm command
UpdateStatus command
Steady command

Description
Use the Steady command to turn on a control-display module's light-emitting diode and have
it remain on.
Short form: none
Syntax
[+|–]Steady –priority 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
object_label specifies the label of the LED to turn on
Notes
The Steady command syntax only requires that you specify an object label.
Specifying a device type causes the compiler to report an error.
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
Device types
The following device types respond to the Steady command:
LED
Example
The following rule turns on the LED labeled Call_In_Active when a firefighter's telephone
handset is connected to a firefighter's phone jack.
[Phone Connection Response]
CI : STEADY -low 'Call_In_Active' ;
SystemFunction command

Description
Use the SystemFunction command to activate a SystemMonitor event from a momentary
switch or a FireWorks command. Activating the SystemMonitor event lets you program a
rule response to the activation of one of the four system function pseudo points.
If a system function pseudo point is assigned to one of the four LCD key functions, you do
not need to use SytemFunction command to activate the SystemMonitor event. The four
LCD key function automatically activate the SystemMonitor event without using the
SystemFunction command.
Short form: SYSFUNC
Syntax
[+|–]SYSFUNC 1-4 'cabinet_label';
— or —
[+|–]SYSFUNC 1-4 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
1-4 specifies which SystemFunction command you want to activate
cabinet_label specifies the label of the panel whose SystemFunction function you
want to activate
routing_label specifies the label of the network routing group containing the panels
whose SystemFunction function you want to activate
Notes
The SystemFunction command syntax does not require that you specify a device
type.
You must configure the switch used to execute the SystemFunction command as a
momentary switch.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
Device types
The following device types respond to the SystemFunction command:
none
Example 1
The following rules disable all smoke detectors on all panels when an operator presses the
switch labeled System_Function_Switch_1.
Switch 'System_Function_Switch 1' : SYSFUNC 1 'All_Cabinets' ;
SMON 'System_Function_1_Response_00_00 ': Disable Smoke ;
Example 2
The following rule disables all smoke detectors on all panels when an operator presses the
LCD key function configured as System Function 1. The LCD key function does not require
the use of the SystemFunction command to activate the SystemMonitor event. The LCD
key function automatically activates the SystemMonitor event without using the
SystemFunction command.
SMON 'System_Function_1_Response_00_00': Disable Smoke;
SysTime command

Description
Use the SysTime command to set the system clock.
Short form: SYSTIME
Syntax
[+|–]SysTime HH:MM:SS;
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
HH is the hour setting from 00 to 23; MM is the minute setting from 00 to 59; SS is
the seconds setting from 00 to 59
Device types
The following device types respond to the SysTime command:
none
Example
The following rules change the system clock for daylight saving time. For a list of daylight
saving days see Daylight saving time around the world.
[Standard_to_Daylight_Saving]
TIME 'Spring_Ahead' : +SysTime 03:00:00 ;
[Daylight_Saving_to_Standard]
TIME 'Fall_Behind' : +SysTime 01:00:00 ;
Note: the Daylight_Saving_to_Standard time control must be configured to run for more
than one hour. This prevents it from running continuously each time it reaches 02:00:00.
Toggle command

Description
Each CRC has two pseudo points with the device type TimedAccessOutput. These are
named Timed_Unlock and Relay_Timed. Activating these points causes the CRC to activate
its lock or relay for a specified period of time. The period of time is not specified in the
SDU, but in the Access Control Database (ACDB) program.
Use the Toggle command to activate the Timed_Unlock or Relay_Timed points on a CRC.
This lets you create rules in the SDU while leaving the decision about timer values to the
end user of the ACDB.
For example, you could include Toggle commands in a command list that is triggered from a
FireWorks workstation. In this way, a central guard station could use CCTV video to control
access at a remote door.
Short form: none
Syntax
[+|–]Toggle –priority device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
priority specifies the order of importance this command has over other commands
affecting the same output device. Valid priority levels are: low, medium, high, latch,
and set.
device_type specifies the device type of the point to activate
object_label specifies the label of the point to activate
Notes
Specifying a priority is optional. If you do not specify a priority, the system assigns
one based on the input event used to activate the rule. For all events except for the
Switch event, the system assigns a low priority. For the Switch event, the system
assigns a high priority.
The Toggle command syntax requires that you specify a device type or an object
label, or both.
Device types
The following device types respond to the Toggle command:
TimedAccessOutput
Example
The following rule turns on all the horns on a given floor when an operator presses the
corresponding switch.
[Open Storage Door]
Activation 'Open_Storage_Door' : Toggle -high TimedAccessOutput
'Timed_Unlock_01_06_01' ;
TroubleSilence command

Description
Use the TroubleSilence command to program a momentary switch on a control-display
module to activate the Trouble Silence function. Activating the Trouble Silence function
temporarily turns off a panel's trouble buzzer.
Short form: TS
Syntax
[+|–]TroubleSilence|TS 'cabinet_label';
— or —
[+|–]TroubleSilence|TS 'routing_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
cabinet_label specifies the panel whose Trouble Silence function you want to
activate
routing_label specifies the label of the network routing group containing the panels
whose Trouble Silence function you want to activate
Notes
The TroubleSilence command syntax does not require that you specify a device
type.
You must configure the switch used to execute the TroubleSilence command as a
momentary switch.
Wildcards can be used to substitute characters in the cabinet label but not in the
routing label.
Device types
The following device types respond to the TroubleSilence command:
TroubleSilence
Example
The following rule silences the trouble buzzer on the panel labeled Cab2 when an operator
presses the control-display module switch labeled C2_Panel_Silence.
[Panel Silence Switch]
SW 'C2_Panel_Silence' : TS 'Cab2' ;
TroubleTest command

Description
Use the TroubleTest command to put a Signature device into a fault condition. This
command requires a 3-SSDC1 or 3-SDDC1 and firmware version 3.4 or later.
Short form: TRBTST
Syntax
[+|–]TroubleTest|TRBTST device_type 'object_label';
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
only when the rule activates.
device_type specifies the device type of the Signature devices you want to put into a
fault condition.
object_label specifies the label of the Signature devices to put into a fault condition.
Device types
The following device types respond to the TroubleTest command:
ACFail Gatevalve SecurityPerimeter
Audible GenAlarm SecurityPMonitor
CMSNonsupervisedOutput Guard Smoke
CMSSupervisedOutput Heat SmokePre
COAlarm Monitor SmokeVfy
COMonitor NonsupervisedOutput SprinklerSupervisory
COSupervisory NSCommonAlarmOutput StageOne
CommonAlarmOutput NSCommonMonitorOutput StageTwo
CommonMonitorOutput NSCommonSupervisoryOutput SupervisedOutput
CommonSupervisoryOutput NSCommonTroubleOutput Supervisory
DamperControl Power Tamper
DamperFeedback Pull Temperature
DoorControl Security Visible
DoorFeedback Security24Hour Waterflow
FanControl SecurityDay
FanFeedback SecurityIMonitor
Firephone SecurityInterior
Example
The following rule activates the TroubleTest function for floor 1 smoke detectors when an
operator presses the switch labeled 'FL1_TroubleTest_On'.
[FL1 TroubleTest]
SW 'FL1_TroubleTest_On' : TRBTST 'FL1_Smk*' ;
UpdateStatus command

Description
Use the UpdateStatus command to force an update of the status of all points in the
partition.
Short form: UPSTAT
Syntax
[+|–]UpdateStatus|UPSTAT device_type 'object_label'
Where:
+ activates the command only when the rule activates, and – activates the command
only when the rule restores. When + or – are not specified, the command activates
when the rule activates and restores when the rule restores.
device_type specifies the device type of the partition you want to update
object_label specifies the label of the partition you want to update
Note: The UpdateStatus command syntax requires that you specify a device type, an
object label, or both.
Device types
The following device types respond to the UpdateStatus command:
Partition
Network performance
This command can result in a high volume of network messages. If you use a single
response (for example, a switch) to control several partitions, make sure that you don't
degrade network performance by generating a high volume of messages.
The number of messages exchanged by the panels depends on:
The number of partitions being controlled
The number of panels in the network
For example, if you reset 10 partitions on a 10 panel network, 100 messages are
exchanged. If you reset 50 partitions on a 40 panel network, then 2,000 messages are
exchanged. Resetting 250 partitions on a 60 panel network exchanges 15,000 messages.
While this amount of network traffic does not harm the network, the time it takes to process
the information can delay the processing of other network messages.
We recommend that you limit number of partitions controlled by a single response
according this formula:
P < 320 / N
Where:
P = number of partitions
N = number of panels
Examples: For a 20 panel network, limit commands to 16 partitions. For a 64 panel
network, limit commands to 5 partitions.
In practice, you would write a rule with several output commands. Each command would
control a limited number of partitions (according to the formula). You would also place a 10
second delay between each command, to make sure all messages for one command were
processed before the next command was executed.
This limitation does not apply to the Disarm, Away, and Stay commands. These commands
do not require a high volume of messages.
See also
Away command
ConditionalAway command
ConditionalStay command
Disarm command
Stay command
Using command lists
A command list is an abstract component that you can create for use in developing rules.
The command list itself has no features except for a label and description. Although it does
not contain a list of commands as its name implies, it is associated with a rule that defines
the actions to be performed. The command list's function is to activate on command, in
order to generate a activation event. You can use this event to initiate a chain of events
specified in a set of rules.
Command lists respond to the commands Activate and Restore. The Activate command
executes the Activation rules in activation sequence (forward). The Restore command
executes the Activation rules in reverse.
You can create command lists by specifying a label and description in the Command List
Manager. You can access this dialog box by selecting Command List from the Configure
menu.
Activating a command list
Using rules to activate command lists
Suppressing multiple activations
To create a command list:
1. From the Configure menu, select Command Lists. This opens the Command List
Manager, which lists any existing command lists.
2. Click the New button. This opens the Command List Properties dialog box.
3. In the Command List Label box, enter a descriptive label.
Tip: If you want to include the address as part of the label, enter the number symbol (#)
where the address is to appear. The SDU automatically inserts the address. This is
especially useful for creating multiple command lists at once.
4. In the Description box, enter any information that would be helpful in distinguishing
this command list from others that may be similar.
5. Click the Edit Message button and enter the location message to be displayed on
the control-display module when the command list activates. This will be displayed
as two lines or as a single line depending on the control-display model installed.
6. In the Abbreviation box, type a short form of the label that can be used to refer to
the command list in the LCD command menus.
7. To send a command to a bell coder when the command list goes active, check the
Coder box, and enter the numeric command string to be sent in boxes on the right.
To clear the command string, click Clear Coder Command.
8. Click Save. This closes the Object Message dialog box.
 9. Click OK. This closes the Command List Properties dialog box.
10. Click Close.
Using command qualifiers
Normally, each command in a rule is activated when the rule activates and restored when
the rule restores. However, you can preface a command with a qualifier that determines
when the command is executed. You can use the command qualifiers with any commands
except DelayActivate and DelayRestore.
The qualifiers are:
+ (on rule activate) causes the command to execute when the rule activates
– (on rule restore) causes the command to execute when the rule restores
For example, +ON executes when the rule activates but does nothing when the rule
restores, and –ON executes when the rule restores but does nothing when the rule
activates.
With no qualifier, commands behave as before. They activate when the rule activates and
restore when the rule restores. This means that the use of command qualifiers is optional.
Existing rules do not have to be rewritten.
Using H-variables
The H-variable lets you generate a set of system responses by writing a single rule, rather
than writing several rules that are identical except for numeric portions of the labels. The H-
variable is similar to the n-variable, but uses hexadecimal values. The H-variable is most
commonly used for sending messages to a central monitoring station (CMS).
You can use the N-variable on one side of a rule and the H-variable on the other side. This
means you can label your devices using ordinary decimal numbers, but send messages to
the CMS that contain hexadecimal point addresses. The system converts between decimal
and hexadecimal values automatically. (See Using N-variables.)
The H-variable has this general format:
<h:###[:w]>
Where:
h is the variable identifier
### is a list or range of values, or a combination these
w is the minimum number of digits for the index (optional, default is 1)
How the H-variable works
Writing a rule that uses the H-variable
H-variable input formats
H-variable output formats
Using mathematical operators
Using the mathematical operators gives the programmer the ability to generate a set
system responses with a single rule when there is an offset between the index number
modifier used in the input object label and the index number modifier used in output object
label. You can use mathematical operators in conjunction with n-variables or H-variables.
For example:
<n + #> substitutes a number greater than the number determined by the input
object label
<n - #> substitutes a number less than the number determined by the input object
label
When using mathematical operators remember that:
The # parameter can be any integer (there are no practical limits to the value)
<n + #> can be any integer
<n - #> cannot equal less than zero
Wildcards cannot be used in place of the #-parameter
Combining multiple n-, or H-variables in the same pair of brackets is not allowed
For example, an application calls for all devices on a floor of a ten story building to activate
the horns and strobes on the fire floor, the floor above the fire floor, and the floor below the
fire floor. Using mathematical operators, the rule required might appear as shown below.
[FireFlrHorn]
Alarm 'LVL<n:2-9>*':
On 'LVL<n>_Horn',
On 'LVL<n>_Strobe',
On 'LVL<n+1>_Horn',
On 'LVL<n+1>_Strobe',
On 'LVL<n-1>_Horn',
On 'LVL<n-1>_Strobe';
Using N-variables
The N-variable lets you generate a set of system responses by writing a single rule, rather
than writing several rules that are identical except for numeric portions of the labels. To use
an N-variable, your device labels should include numbers (ASCII character range 1-32767)
that can be treated as an index.
Note: The number zero (0) cannot be used as an n-variable.
Example: If your device labels include a floor number, you can use an N-variable to write
one rule for all floors, rather than writing separate rules for each floor. The floor number
acts as the index.
You can use an N-variable on one side of a rule and an H-variable on the other side. The
system converts between decimal and hexadecimal values automatically. (See Using H-
variables.)
The N-variable has this general format:
<n:###[:w]>
Where:
n is the variable identifier
### is a list or range of values, or a combination of these
w is the minimum number of digits for the index (optional, default is 1)
How the N-variable works
Writing a rule that uses the N-variable
N-variable input formats

N-variable output formats

Using substitution strings
Substitution strings can be used in the text parameter of the Send command to insert state-
specific information into the message that the 3-MODCOM sends to a central monitoring
station. The format of the inserted information varies with the substitution string and the
protocol that the central monitoring station requires.
$(...) denotes the substitution string escape sequence. Any string enclosed in parenthesis
and preceded by $ is a substitution string. $(TIME12), $(DATE), and $(MMDDYY) are
examples of substitution strings that insert system information. Substitution strings can also
be ASCII text characters. For example, $(") is a substitution string that inserts a double
quote mark into the text.
Here is an example of a rule that uses substitution strings:
[Send SIA DCS Example]
ALARM SMK 'SMK_67':
+Send 'My_SIA_Account' "$(DATE)$(TIME)FA67";
If smoke detector SMK_67 changes to the alarm state on May 23, 1999 at 11:23:33 a.m.,
the 3-MODCOM will send the following message to account labeled My_SIA_Account:
da05-23-99ti11:23:33FA67
Note: Use of a substitution string that is undefined for a protocol will cause the default
equivalent format to be used. For example, $(TIME12) is not supported by the SIA DCS
protocol therefore the system will insert the default string $(TIME), which for DCS is the
same as $(TIME24).
See also
SIA DCS substitution strings
TAP substitution strings
Using system function pseudo points
System function pseudo points are used to activate rule responses from one of the four
LCD keys, a momentary switch, or a FireWorks command. The SystemMonitor event is
used to activate the system function pseudo points.
If using a momentary switch or a FireWorks command, you must use the SystemFunction
command to activate a SystemMonitor event.
If a system function pseudo point is assigned to one of the four LCD key functions, you do
not need to use the SytemFunction command to activate the SystemMonitor event. The four
LCD key functions automatically activate the SystemMonitor event without using the
SystemFunction command.
Examples
The following rules disable all smoke detectors on all panels when an operator presses the
momentary switch labeled System_Function_Switch_1. The SystemFunction command is
used to activate the SystemMonitor event.
Switch 'System_Function_Switch 1':
SYSFUNC 1 'All_Cabinets';
SMON 'System_Function_1_Response_00_00':
Disable Smoke;
The next rule disables all smoke detectors on all panels when an operator presses the LCD
key function configured as System Function 1. The LCD key function does not require the
use of the SystemFunction command to activate the SystemMonitor event. The LCD key
function automatically activate the SystemMonitor event without using the SystemFunction
command.
SMON 'System_Function_1_Response_00_00':
Disable Smoke;
Using wildcards
Wildcards (*) are used in rules to identify all objects whose labels follow a specific pattern.
You might be familiar with wildcard notations such as *.txt that are used in file searches to
identify all text files in a folder. Wildcards take the place of one or more characters. Notice
the structure of the following series of object labels:
Floor1_smoke
Floor2_smoke
Floor3_smoke
etc.
These labels differ only by a single character, the floor number. You could easily describe
the entire series by substituting a wildcard (*) for the floor number. Writing Floor*_smoke
identifies any object starting with Floor and ending with _smoke.
Other examples include the following:

*_AMP Identifies all objects whose labels end with

_AMP, such as Floor1_AMP, LVL1_AMP, etc.
Excludes Floor1Amp, Amp_LVL1, etc.
LVL_*_SMK Identifies all objects whose labels start with LVL_
and end with _SMK, such as LVL1_SMK,
LVL1_ElevLobby_SMK. Excludes LVL1SMK or
LVL_1_SMOKE, etc.
*SMK* Identifies all objects with SMK somewhere in the
label (ELEVLOBBY_SMK1, Room1_SMK1).

Using wildcards in rules

Avoiding careless use of wildcards

See Also
Using H-variables
Using N-variables
Using logical outputs
Logical outputs are abstract objects that mimic the operation of actual nonsupervised
relays. They provide a convenient method of developing a system of complex system
interactions. Logical outputs can be activated and restored from front panel menus or
through rules programming. Activating a logical output produces a relay confirmation event
(RelayConfirmation or RLYCFG) that can be incorporated in rules and used to drive further
operations.
Sample rules
The following table contains three sample rules that make use of a logical output
(Logical_Output_Alarm) and an AND group (Floor2_AND) whose Activation Number = 2.
The device counter for the AND group is incremented by one (+1) when any of the following
goes into alarm: smoke detector, heat detector, pull station, or the matrix group labeled
Floor2_Matrix.

Rules Notes
[Rule 1] In this project, all smoke detectors, heat detectors, and
Alarm 'Floor*' : pull stations share the label scheme "Floor[floor
ON 'Logical_Output_Alarm'; #]_[device type]". For example, Floor9_pull or
Floor1_heat.
Rule 1 condenses all smoke detector, heat detector, and
pull station activations to a single point — the logical
output labeled Logical_Output_Alarm. Notice that Rule 3
uses the resulting relay confirmation to activate the
Floor2_AND group.
[Rule 2] The matrix group follows a different labeling scheme that
Alarm 'Floor2_Matrix' : differs from the devices covered by Rule 1. This makes it
ACTIVATE 'Floor2_AND'; possible to write a separate rule (Rule 2) stating that each
time the matrix group goes into alarm, the Floor2_AND
group is activated.

[Rule 3] Rule 3 states that each time the logical output labeled
RLYCFG Logical_Output_Alarm is turned on, one (1) is added to
'Logical_Output_Alarm' : the activation count of the AND group.
ACTIVATE 'Floor2_AND';

View diagram illustrating how this set of rules functions.

Programming a 3-MODCOM

Content
General procedure
Events
Commands
Command lists
Message protocols
Contact ID for Network Type EST3 / Combination
Contact ID for Network Type 3X Only
SIA DCS
SIA P2 and P3 formats
TAP protocol
Pseudo points
Account disabling
General procedure
Here is an overview of the steps you should follow to configure and program a 3-
MODCOM.
1. Use the Configure 3-MODCOM dialog boxes to configure the 3-MODCOM.
2. The Receiver Properties dialog box, accessible from the Receivers tab, lets you
enter codes for the Receiver Default Messages.
3. Use the Rules Editor to code rules that handle event-driven off-site monitoring
station messages.
4. Print the CMS Messaging Report and give a copy to the off-site monitoring station.
5. This allows the off-site monitoring station to verify the codes your project will be
sending.
Back to top
Events
For security applications, two input events are useful when reporting to an off-site
monitoring station. These are SecurityDisarmed and SecurityExitTimer.
SecurityDisarmed: This event occurs when a partition is disarmed and can be used to
report an opening to the CMS.
SecurityExitTimer: This event occurs when a partition is armed and can be used to report a
closing to the CMS.
For more information, see SecurityDisarmed event and SecurityExitTimer event.
Back to top
Commands
For all applications, three output commands are useful when programming for a 3-
MODCOM. These are the Send, Activate, and Restore commands. Send is used to send a
message to an off-site monitoring station. Activate and restore cause activation and restoral
of a command list.
Send command
Activate command
Restore command
Example: This rule uses SIA DCS format to send a closing message to an off-site
monitoring station. The send command uses the confirm option to activate a command list
when the CMS confirms receipt of the message.
[Closing]
SecurityExitTimer 'Office_Partition':
+Send 'AcmeAcct1234' MSG "CL" Cnf 'Confirm_Closing';
Back to top
Command lists
A command list is an object you create by specifying a label and description. You can use
the Activate and Restore commands to activate and restore a command list. You can use
the Activation event to detect activation or restoral of a command list. Command lists can
also be activated by devices and by external command and control systems.
You must use command lists to program system responses to CRC events. Command lists
can include commands that report security events to an off-site monitoring station via the 3-
MODCOM.
Example: This rule reports an access denied event to the CMS. The rule is triggered by
activation of a command list (Access_Denied_Door_1 through 8). Each command list would
be defined in the SDU, and then assigned to the access denied event of a given CRC during
configuration.
[Access denied - doors 1 to 8]
Activation 'Access_Denied_Door_<n:1-8>':
Send 'AcmeAcct1234' Msg "DD<n>";
Example: This rule sounds an audible device to confirm receipt of the closing message by
the CMS. The triggering command list would be named as the Confirm option of the Send
command that sends the closing message.
[Confirm Closing]
Activation 'Confirm_Closing':
On 'Security_Sounder',
Delay 1,
Off 'Security_Sounder';
Back to top
Message protocols
The 3-MODCOM can use any of the following message protocols:
Contact ID
SIA DCS
SIA P2 (3/1 Pulse Format)
SIA P3 (4/2 Pulse Format)
TAP (MODCOMP only)
Note: Contact ID, SIA P2, and SIA P3 formats make use of a special Telco version of
hexadecimal coding. In this version, 0 and A are equivalent. The SDU automatically converts
hex A to hex 0 when compiling rules for projects using these protocols. It generates a
warning message when this causes different events to generate the same CMS message.
Use these warnings to resolve labeling problems.
Back to top
Contact ID for Network Type EST3 / Combination
Contact ID messages are typically 16-digit hexadecimal strings that include predefined
event codes and variable account and address information.
ACCT MT QEEE GG PPP S
Where:
ACCT = Account number. A four-digit account number (hex 0-9, B-F) defined in the
SDU. The account number links a company to a receiver. You must include the account
number in your rule.
MT = Message type. This two-digit code identifies the Contact ID message type to the
receiver. The 3-MODCOM sends this portion (with value = 18) automatically.
Q = Event qualifier. A one-digit code. Use 1 for activation messages and 3 for restoral
messages. You must include the event qualifier as part of your message.
EEE = Event code. A three-digit code (hex 0-9, B-F). See Contact ID codes for a list of
codes and descriptions.
GG = Group, zone, or partition number. A two-digit number that identifies a group,
zone, or partition (hex 0-9, B-F). Use 00 when no group, zone, or partition information
applies.
PPP = Point ID (for event reports) or user ID (for open or close reports ). A three-digit
number (hex 0-9,B-F ). Use 000 when no point or user information applies.
S = Checksum digit. A one-digit hex checksum calculated by the 3-MODCOM
You can use the $(User) substitution string with Contact ID protocol. No other substitution
strings are allowed.
Examples of Send commands using Contact ID protocol:
SecurityAway Partition<h=1-5>:
+Send 'NationalAcct1235' Msg "3401<h>$(User)";
Alarm<h=1-4096>:
+Send 'NationalAcct1235' Msg "111000<h>",
-Send 'NationalAcct1235' Msg "311000<h>";
Check with your dialer receiver and central monitoring station software provider for the
exact structures they require. Use of wild cards and variable arithmetic is allowable in rules.
Remember that rules for device states require separate -Send commands to send the
appropriate restore messages. Events that do not require restore messages should use
+Send commands, which are run only on activation and not on restore.
Back to top
Contact ID for Network Type 3X Only
Contact ID messages are typically 16-digit hexadecimal strings that include predefined
event codes and variable account and address information.
Note: Guard patrol and text groups do not generate CID strings and will not be part of the
CMS report.
ACCT MT QEEE PC DDD S
Where:
ACCT = Account number. A four-digit account number (hex 0-9, B-F) defined in the
SDU. The account number links a company to a receiver. You must include the account
number in your rule.
MT = Message type. This two-digit code identifies the Contact ID message type to the
receiver. The 3-MODCOM sends this portion (with value = 18) automatically.
Q = Event qualifier. A one-digit code. Use 1 for activation messages and 3 for restoral
messages. You must include the event qualifier as part of your message.
EEE = Event code. A three-digit code (hex 0-9, B-F). See Contact ID codes for a list of
codes and descriptions.
P = Panel address. A one-digit code. Use 0 for logic groups (AND, zone, matrix, etc.)
and project level pseudo points (FirstAlarm, ResetActive, etc.).
C = Card address. A one-digit code. Use the following:
0 for project level pseudo points
6 for AND groups
7 for matrix groups
5 for service groups
4 for zone groups
DDD = Device address.
S = Checksum digit. A one-digit hex checksum calculated by the 3-MODCOM.
You can use the $(User) substitution string with Contact ID protocol. No other substitution
strings are allowed.
Examples of Send commands using Contact ID protocol:
SecurityAway Partition<h=1-5>:
+Send 'NationalAcct1235' Msg "3401<h>$(User)";
Alarm<h=1-4096>:
+Send 'NationalAcct1235' Msg "111000<h>"
-Send 'NationalAcct1235' Msg "311000<h>"
Check with your dialer receiver and central monitoring station software provider for the
exact structures they require. Use of wild cards and variable arithmetic is allowable in rules.
Remember that rules for device states require separate -Send commands to send the
appropriate restore messages. Events that do not require restore messages should use
+Send commands, which are run only on activation and not on restore.
Back to top
SIA DCS
SIA DCS messages are typically 6-digit strings that include variable account numbers in
hexadecimal format and predefined event codes in ASCII text. The messages can also
include a number of optional parameters. The format is:
ACCT EE [PPPP] [Date] [Time] [UserID]
Where:
ACCT = Account number. A four-digit account number (hex 0-9, B-F) defined in the SDU.
The account number links a company to a receiver. You must include the account number
in your rule.
EE = Event code. A two-character code consisting of upper-case ASCII letters. The
codes and descriptions are given in the topic SIA DCS codes.
PPPP = Address number. A four-digit number (hex 0-9, B-F). This can be a group, zone,
partition, or point number.
Date, Time, and UserID: These items are optional. Then can be included in your
message by using substitution strings. See the topic SIA DCS substitution strings for
details.
For more information, see SIA DCS codes and SIA DCS substitution strings
There is no partition or door substitution variable. You must use labels like Partition_1 and
Door_2 when naming the partitions and doors, and use <n> wildcard substitutions.
Examples: CL<n> or DD<n>.
Examples of Send commands using SIA DCS protocol:
+Send 'AcmeAcct1234' Msg "$(USERID)DD<n>";
+Send 'AcmeAcct1234' Msg "$(DATE)$(TIME)FA<n>"
Check with your dialer receiver and central monitoring station software provider for the
exact structures they require. Use of wild cards and variable arithmetic is allowed in rules
using the Send command.
Remember that rules for device states require separate -Send commands to send the
appropriate restore messages. Events that do not require restore messages should use
+Send commands, which are run only on activation and not on restore.
Back to top
SIA P2 and P3 formats
SIA P2 (3/1) and SIA P3 (4/2) messages include only an account number and a predefined
event code. In SIA P2 the account number is three digits and the event code is one digit. In
SIA P3 the account number is four digits and the event code is two digits. In both cases, the
account numbers and event codes are in hexadecimal format.
Because there are no standard event codes for these formats, the central monitoring
station must provide you with a list of the codes they use. The event code portion can
contain variable address information. For example, 11 could be a fire alarm in zone 1. 24
could be a burglar alarm in partition 4.
There are no substitution strings for addresses. You must use labels like Partition_1 and
Door_2 when naming partitions and doors, then use hex wildcard substitutions such as
3<h>.
You can use the $(User) substitution string for the second digit of the event code, but you
must set the first digit to 0. In this case, you are limited to reporting only 16 different user
IDs. (This is typically used in a small security or access control application, and is not used
for fire applications.)
Examples of Send commands using 4/2 format:
Send 'MuniAcct1236' Msg "3<h>"
Send 'MuniAcct1236' Msg "22"
Send 'MuniAcct1236' Msg "0$(User)"
Check with your central monitoring station for the exact codes and message formats they
require. Use of wild cards and variable arithmetic is allowed in rules using the Send
command.
Back to top
TAP protocol
TAP format consists of short, predefined ASCII text messages that contain a number of
optional parameters. The format is:
PagerID CR [Date] [Time] [User] Message [Location]
PagerID: Valid Pager IDs are determined by the paging service. While the Pager ID has
traditionally been a 7 digit PIN, many systems use a 4 digits and some use 10 or more
digits.
The SDU places no restriction on the Pager ID format. However, the total length of the
Pager ID and the Message is 59 characters, including spaces between words. The
longer the Pager ID, the shorter the text message.
CR: Use the substitution string $(CR). This inserts a carriage return into the text
message. This is a required boxes, and must appear between the PagerID and the body
of the message.
Date, Time, User, and Location: These items are optional. Then can be included in your
message by using substitution strings. See the topic TAP substitution strings for details.
Message: The text message to be sent. Examples: Fire Alarm, Burglar Bypass. Refer to
the SIA DCS codes and Contact ID codes topics for standard event descriptions.
Note: The system does not support embedded control characters such as carriage return
(CR), line feed (LF), escape (ESC), STX, ETX, US, ETB, EOT, or SUB in the message.
You might want to use labels like Partition_1 and Door_2 when naming the partitions and
doors, then use <n> wildcard substitutions. Example Partition_<n> and Door_<n>.
Examples of the Send command using TAP protocol:
+Send 'PageMart' Msg "1234567$(CR)$(Date) $(Time) Fire Alarm $(Location:1-20)"
+Send 'PageMart' Msg "1234567$(CR)$(DATE) $(TIME) Opening – Pharmacy $(User)"
Check that your paging service provider accepts the TAP protocol and determine any
further message length limitations. Use of wild cards and variable arithmetic is allowable in
the rule.
Remember that rules for device states require separate -Send commands to send the
appropriate restore messages. Events that do not require restore messages should use
+Send commands, which are run only on activation and not on restore.
Note: Messages sent using TAP protocol have the same priority, and are stored in a single
queued when received by the paging service. Delivery of alarm messages might take
several minutes during times of heavy traffic. When writing rules, always send messages to
the central monitoring station receivers first, then send messages to supplemental receivers
such as pagers.
Back to top
Pseudo points
The 3-MODCOM has the following pseudo points for which you can write rules.

Address Device type Device label

001 MCOMACCOUNT Account_Label
261 MCOMCOMPANY Company_Label
600 LOCALTROUBLE Annunciator_Supervision
601 LOCALTROUBLE Rail_Module_Communications_Fault
604 LOCALTROUBLE Internal_Fault
605 LOCALTROUBLE Database_Supervision
606 LOCALTROUBLE Code_Supervision
609 LOCALTROUBLE Configuration_Fault
610 LOCALTROUBLE Telephone_Line_1
611 LOCALTROUBLE Telephone_Line_2
612 LOCALTROUBLE Receiver_Test_Line_1
613 LOCALTROUBLE Receiver_Test_Line_2
614 LOCALTROUBLE RS-232_Channel
615 LOCALMONITOR Incoming_Ring
617 LOCALTROUBLE DSP_Supervision
620 LOCALTROUBLE Waiting_For_SDU_Download
621 NONSUPERVISEDOUTPUT Manual_Answer_Control
622 LOCALMONITOR Outgoing_Call_In_Progress

Example: This rule sends a message to the CMS (using SIA DCS protocol) when either
telephone line goes into trouble or comes out of trouble. (The 3-MODCOM handles line
switching internally, so that the alternate line is used.)
[Telephone line trouble]
LocalTrouble 'Telephone_Line_<n:1-2>':
+Send 'Account_Label' Msg "LT <n>",
-Send 'Account_Label' Msg "LR <n>";
Example: This rule activates an LED when the 3-MODCOM receives a call.
[Incoming call on MODCOM]
LocalMonitor 'Incoming_Ring_XX_XX':
Fast 'LED1';
Example: This rule establishes manual reception of incoming calls. This could be used
when the customer requires a person on site before allowing any changes to the system.
You would use the previous example rule to indicate an incoming call. When site staff
respond by activating the switch, the 3-MODCOM proceeds to answer the call.

[Accept incoming call]

Switch 'Switch_1':
On 'Manual_Answer_Control_XX_XX',
Steady 'LED1';
Back to top
Account disabling
You can disable a single account or an entire 3-MODCOM.
To notify the CMS and disable a single account using a switch, create the following
rule.
[Disable MODCOM account]
Switch 'Switch_Label':
+Send 'Account_Label' MSG "155100000" {Disable account message},
-Send 'Account_Label' MSG "355100000" {Enable account message},
Disable 'Account_Label';

To notify the CMS (or several CMSs) and disable all accounts using a switch, create
the following rule.
[Disable all MODCOM accounts]
Switch 'Switch_Label':
+Send 'Account_Label <N:001-255>' MSG "155100<N:3>" {Disable account
message},
-Send 'Account_Label <N:001-255>' MSG "355100<N:3>" {Enable account
message},
Disable 'MODCOM_Label';

Back to top
Contact ID codes

Event code Description Data type

ALARMS
100 Medical Alarms
100 Medical Zone
101 Personal Emergency Zone
102 Fail to report in Zone
110 Fire Alarms
110 Fire Zone
111 Smoke Zone
112 Combustion Zone
113 Water flow Zone
114 Heat Zone
115 Pull Station Zone
116 Duct Zone
117 Flame Zone
118 Near Alarm Zone
120 Panic Alarms
120 Panic Zone
121 Duress User
122 Silent Zone
123 Audible Zone
124 Duress Access granted Zone
125 Duress Egress granted Zone
130 Burglar Alarms
130 Burglary Zone
131 Perimeter Zone
132 Interior Zone
133 24 Hour (Safe) Zone
134 Entry/Exit Zone
135 Day/night Zone
136 Outdoor Zone
137 Tamper Zone
138 Near alarm Zone
139 Intrusion Verifier Zone
140 General Alarm
140 General Alarm Zone
141 Polling loop open Zone
142 Polling loop short Zone
143 Expansion module failure Zone
144 Sensor tamper Zone
145 Expansion module tamper Zone
146 Silent Burglary Zone
147 Sensor Supervision Failure Zone
150 and 160 24 Hour Non-Burglary
150 24 Hour Non-Burglary Zone
151 Gas detected Zone
152 Refrigeration Zone
153 Loss of heat Zone
154 Water Leakage Zone
155 Foil Break Zone
156 Day Trouble Zone
157 Low bottled gas level Zone
158 High temp Zone
159 Low temp Zone
161 Loss of air flow Zone
162 Carbon Monoxide detected Zone
163 Tank level Zone
SUPERVISORY
200 and 210 Fire Supervisory
200 Fire Supervisory Zone
201 Low water pressure Zone
202 Low CO2 Zone
203 Gate valve sensor Zone
204 Low water level Zone
205 Pump activated Zone
206 Pump failure Zone
TROUBLES
300 and 310 System Troubles
300 System Trouble Zone
301 AC Loss Zone
302 Low system battery Zone
303 RAM Checksum bad Zone
304 ROM checksum bad Zone
305 System reset Zone
306 Panel programming changed Zone
307 Self-test failure Zone
308 System shutdown Zone
309 Battery test failure Zone

310 Ground fault Zone

311 Battery Missing/Dead Zone
312 Power Supply Overcurrent Zone
313 Engineer Reset User
320 Sounder / Relay Troubles
320 Sounder/Relay Zone
321 Bell 1 Zone
322 Bell 2 Zone
323 Alarm relay Zone
324 Trouble relay Zone
325 Reversing relay Zone
326 Notification Appliance Ckt. # 3 Zone
327 Notification Appliance Ckt. #4 Zone
328 Alarm silence Zone
330 and 340 System Peripheral Trouble
330 System Peripheral trouble Zone
331 Polling loop open Zone
332 Polling loop short Zone
333 Expansion module failure Zone
334 Repeater failure Zone
335 Local printer out of paper Zone
336 Local printer failure Zone
337 Exp. Module DC Loss Zone
338 Exp. Module Low Batt. Zone
339 Exp. Module Reset Zone
341 Exp. Module Tamper Zone
342 Exp. Module AC Loss Zone
343 Exp. Module self-test fail Zone
344 RF Receiver Jam Detect Zone
350 and 360 Communication Troubles
350 Communication trouble Zone
351 Telco 1 fault Zone
352 Telco 2 fault Zone
353 Long Range Radio xmitter fault Zone
354 Failure to communicate event Zone
355 Loss of Radio supervision Zone
356 Loss of central polling Zone
357 Long Range Radio VSWR problem Zone
370 Protection Loop
370 Protection loop Zone

371 Protection loop open Zone

372 Protection loop short Zone
373 Fire trouble Zone
374 Exit error alarm (zone) Zone
375 Panic zone trouble Zone
376 Hold-up zone trouble Zone
377 Swinger Trouble Zone
378 Cross-zone Trouble Zone
380 Sensor Trouble
380 Sensor trouble Zone
381 Loss of supervision - RF Zone
382 Loss of supervision - RPM Zone
383 Sensor tamper Zone
384 RF low battery Zone
385 Smoke detector Hi sensitivity Zone
386 Smoke detector Low sensitivity Zone
387 Intrusion detector Hi sensitivity Zone
388 Intrusion detector Low sensitivity Zone
389 Sensor self-test failure Zone
391 Sensor Watch trouble Zone
392 Drift Compensation Error Zone
393 Maintenance Alert Zone
OPEN/CLOSE/REMOTE ACCESS
400, 440, 450 Open/Close
400 Open/Close User
401 O/C by user User
402 Group O/C User
403 Automatic O/C User
404 Late to O/C (Note: use 453, 454 instead ) User
405 Deferred O/C (Obsolete- do not use ) User
406 Cancel User
407 Remote arm/disarm User
408 Quick arm User
409 Keyswitch O/C User
441 Armed STAY User
442 Keyswitch Armed STAY User
450 Exception O/C User
451 Early O/C User
452 Late O/C User
453 Failed to Open User

454 Failed to Close User

455 Auto-arm Failed User
456 Partial Arm User
457 Exit Error (user) User
458 User on Premises User
459 Recent Close User
461 Wrong Code Entry Zone
462 Legal Code Entry User
463 Re-arm after Alarm User
464 Auto-arm Time Extended User
465 Panic Alarm Reset Zone
466 Service On/Off Premises User
410 Remote Access
411 Callback request made User
412 Successful download/access User
413 Unsuccessful access User
414 System shutdown command received User
415 Dialer shutdown command received User
416 Successful Upload Zone
420, 430 Access control
421 Access denied User
422 Access report by user User
423 Forced Access Zone
424 Egress Denied User
425 Egress Granted User
426 Access Door propped open Zone
427 Access point Door Status Monitor trouble Zone
428 Access point Request To Exit trouble Zone
429 Access program mode entry User
430 Access program mode exit User
431 Access threat level change User
432 Access relay/trigger fail Zone
433 Access RTE shunt Zone
434 Access DSM shunt Zone
BYPASSES / DISABLES
500 and 510 System Disables
500 First disable Zone
501 Access reader disable Zone
520 Sounder / Relay Disable
520 Sounder/Relay Disable Zone

521 Bell 1 disable Zone

522 Bell 2 disable Zone
523 Alarm relay disable Zone
524 Trouble relay disable Zone
525 Reversing relay disable Zone
526 Notification Appliance Ckt. # 3 disable Zone
527 Notification Appliance Ckt. # 4 disable Zone
530 and 540 System Peripheral Disables
531 Module Added Zone
532 Module Removed Zone
550 and 560 Communication Disables
551 Dialer disabled Zone
552 Radio transmitter disabled Zone
553 Remote Upload/Download disabled Zone
570 Bypasses
570 Zone/Sensor bypass Zone
571 Fire bypass Zone
572 24 Hour zone bypass Zone
573 Burg. Bypass Zone
574 Group bypass User
575 Swinger bypass Zone
576 Access zone shunt Zone
577 Access point bypass Zone
TEST / MISC.
600, 610 Test/Misc.
601 Manual trigger test report Zone
602 Periodic test report Zone
603 Periodic RF transmission Zone
604 Fire test User
605 Status report to follow Zone
606 Listen-in to follow Zone
607 Walk test mode User
608 Periodic test - System Trouble Present Zone
609 Video Xmitter active Zone
611 Point tested OK Zone
612 Point not tested Zone
613 Intrusion Zone Walk Tested Zone
614 Fire Zone Walk Tested Zone
615 Panic Zone Walk Tested Zone
616 Service Request Zone
620 Event Log
621 Event Log reset Zone
622 Event Log 50% full Zone
623 Event Log 90% full Zone
624 Event Log overflow Zone
625 Time/Date reset User
626 Time/Date inaccurate Zone
627 Program mode entry Zone
628 Program mode exit Zone
629 32 Hour Event log marker Zone
630 Scheduling
630 Schedule change Zone
631 Exception schedule change Zone
632 Access schedule change Zone
640 Personnel Monitoring
641 Senior Watch Trouble Zone
642 Latch-key Supervision User
650 Misc.
651 Reserved Zone
652 Reserved User
653 Reserved User
654 System Inactivity Zone
SIA DCS codes

Description Event code

24 Hour Non Burglary Alarm -
24 Hour Non Burglary Alarm Restore -

24 Hour Zone Bypass -

24 Hour Zone Unbypass -
AC Restoral AR
AC Trouble/Fail AT
Access Denied DD
Access Denied – Access Level DV

Access Denied – Door Secure DZ

Access Denied – Interlock DW
Access Denied – Outside Schedule DP
Access Denied – Partition Armed DQ
Access Granted DG
Access Lockout DK
Access Open to Authorized Users DO
Access report by user -
Access Trouble DT
Access, Closed DC
Activity Resumed NS
Air Flow, Loss of -

Air Flow, Loss of, Restore -

Analog Restoral AN
Analog Service AS
Battery Missing (System) YM
Battery Restoral (System) YR
Battery Trouble (System) YT
Battery, Sensor Low -
Battery, System, Low -
Battery, Test Failure -
Battery, Transmitter Trouble XT
Bell Disabled -
Bell Disabled Restore -
Bell Fault YA
Bell Restored YH

Burglar Supervisory BS
Burglary Alarm BA

Burglary Alarm Cross Point BM

Burglary Alarm Restore BH
Burglary Alarm, 24 Hour (Safe) -

Burglary Alarm, 24 Hour Restore -

Burglary Alarm, Day/night -
Burglary Alarm, Day/night Restore -
Burglary Alarm, Entry/Exit -
Burglary Alarm, Entry/Exit Restore -
Burglary Alarm, Interior -

Burglary Alarm, Interior Restore -

Burglary Alarm, Near Alarm -
Burglary Alarm, Near Alarm Restore -
Burglary Alarm, Outdoor -
Burglary Alarm, Outdoor Restore -
Burglary Alarm, Perimeter -
Burglary Alarm, Perimeter Restore -
Burglary Bypass BB
Burglary Cancel BC
Burglary Restoral BR
Burglary Test BX
Burglary Trouble BT

Burglary Trouble Restore BJ

Burglary Unbypass BU
Burglary Verified BV
Burglary, Silent -
Burglary, Silent Restore -
Cancel Report OC
Card Assigned DA
Card Deleted DB
Close Area CG
Close Early -
Close Group -
Close Remote -
Close Stay -
Close, Early CK

Close, Fail to CI
Close, Late OT

Closing Automatic CA
Closing Automatic CP
Closing Delinquent CD

Closing Extend CE
Closing Keyswitch CS
Closing Report CL
Closing, Exit Alarm EA
Closing, Exit Error EE
Closing, Forced CW

Closing, Perimeter Only Armed NL

Closing, Device CZ
Closing, Recent CR
CO2, Low level -
CO2, Low level Restore -
Communication Trouble YS
Communications Fail YC
Communications Restoral YK
Date Changed JD
Dialer Disabled -
Dialer Disabled Restore -
Door Forced DF

Door Forced – Trouble DJ

Door Left Open – Alarm DL
Door Left Open – Non-Alarm DN
Door Left Open – Restoral DH
Door Left Open – Trouble DM
Door Locked DY
Door Restoral DR
Door Station DS
Emergency Alarm QA
Emergency Alarm Restore QH
Emergency Alarm/Trouble Restore QR
Emergency Bypass QB
Emergency Supervisory QS
Emergency Trouble QT

Emergency Trouble Restore QJ

Emergency Unbypass QU

Equipment Failure Condition IA

Equipment Failure Restore IR
Event Log 50% Full -

Event Log 90% Full -

Event Log Overflow -
Event Log Reset -
Expansion Module DC Loss -
Expansion Module Fail -
Expansion Module Low Bat -

Expansion Module Reset -

Expansion Module Tamper -
Expansion Restoral ER
Expansion Trouble ET
External Device Condition EX
Extra Device XE
Extra RF Device XF
Fail To Communicate -
Fire – Missing Supervision FZ
Fire – Missing Trouble FY
Fire Alarm FA
Fire Alarm – Cross Point FM

Fire Alarm Restore FH

Fire Bypass FB
Fire Cancel FC
Fire Pump Failure -
Fire Pump Failure Restore -
Fire Pump Running -
Fire Pump Running Restore -
Fire Restoral FR
Fire Supervisory FS
Fire Test FX
Fire Test Begin FI
Fire Test End FK
Fire Trouble FT
Fire Trouble Restore FJ

Fire Unbypass FU

Fire, Combustion -

Fire, Combustion Restore -

Fire, Duct -
Fire, Duct Restore -

Fire, Flame -
Fire, Flame Restore -
Fire, Heat -
Fire, Heat Restore -
Fire, Near Alarm -
Fire, Near Alarm Restore -

Fire, Pull Station -

Fire, Pull Station Restore -
Fire, Smoke -
Fire, Smoke Restore -
Fire, Waterflow -
Fire, Waterflow Restore -
Foil Break -
Foil Break Restore -
Forced Closing CF
Forced Perimeter Arm NF
Forced Device XW
Freeze Alarm ZA

Freeze Alarm Restore ZH

Freeze Alarm/Trouble Restore ZR
Freeze Bypass ZB
Freeze Supervisory ZS
Freeze Trouble ZT
Freeze Trouble Restore ZJ
Freeze Unbypass ZU
Gas Alarm GA
Gas Alarm Restore GH
Gas Alarm/Trouble Restoral GR
Gas Bypass GB
Gas Test GX
Gas Trouble GT
Gas Trouble Restore GJ

Gas Unbypass GU
Gas, Low Level -

Gas, Low Level Restore -

Gate Valve Sensor Active -
Gate Valve Sensor Restore -

Ground Fault -
Ground Fault Restore -
Group Bypass -
Group UnBypass -
Heat Alarm KA
Heat Alarm Restore KH

Heat Alarm/Trouble Restoral KR

Heat Bypass KB
Heat Supervisory KS
Heat Trouble KT
Heat Trouble Restore KJ
Heat Unbypass KU
Holdup Alarm HA
Holdup Alarm Restore HH
Holdup Alarm/Trouble Restoral HR
Holdup Bypass HB
Holdup Supervisory HS
Holdup Trouble HT

Holdup Trouble Restore HJ

Holdup Unbypass HU
Holiday Changed JH
Intrusion Detector Hi Sen Restore -
Intrusion Detector Hi Sensitivity -
Intrusion Detector Low Sen Restore -
Intrusion Detector Low Sensitivity -
Latchkey Alert JK
Late Close CJ
Late to Open CT
Local Program LB
Local Program Denied LD
Local Program Ended LX
Local Program Fail LU

Local Program Success LS

Medical Alarm MA

Medical Alarm Restore MH

Medical Alarm/Trouble Restore MR
Medical Bypass MB

Medical Supervisory MS
Medical Trouble MT
Medical Trouble Restore MJ
Medical Unbypass MU
Message, Unknown YO
Missing Alarm – Exit Error EZ

Missing Alarm – Recent Closing CM

Missing Alarm- Cross Point XM
Missing Supervision BZ
Network Condition NC
Network Failure NT
Network Restoral NR
No Zone Activity NA
Open Area OG
Open Partition OP
Open Remote -
Open, Early OK
Open, Early from Alarm OH

Open, Fail to OI
Open, From Alarm OR
Open, Late OJ
Open, Late from Alarm OL
Open, Device OZ
Opening Automatic OA
Opening Keyswitch OS
Opening Report OP
Opening Report by User OP
Panic Alarm PA
Panic Alarm Restore PH
Panic Alarm/Trouble Restore PR
Panic Bypass PB
Panic Supervisory PS

Panic Trouble PT
Panic Trouble Restore PJ

Panic Unbypass PU
Panic, Audible -
Panic, Audible Restore -

Panic, Duress -
Panic, Duress Restore -
Panic, Silent -
Panic, Silent Restore -
Parameter Changed YG
Parameter Checksum Fail YF

Polling Circuit Open -

Polling Circuit Open Restore -
Polling Circuit Short -
Polling Circuit Short Restore -
Polling, Loss of Central Poll -
Polling, Loss of Central Poll Restore -
Power Supply Restored YQ
Power Supply Trouble YP
Power Up RR
Printer Offline VZ
Printer Online VY
Printer Paper In VI

Printer Paper Out VO

Printer Restore VR
Printer Test VX
Printer Trouble VT
Protection Circuit Open -
Protection Circuit Open Restore -
Protection Circuit Short -
Protection Circuit Short Restore -
Protection Circuit Trouble -
Protection Circuit Trouble Restore -
Relay Close RC
Relay Open RO
Relay, Alarm, Disable -
Relay, Alarm, Disable Restore -

Relay, Alarm, Trouble -

Relay, Alarm, Trouble Restore -

Relay, Reversing, Disable -

Relay, Reversing, Disable Restore -

Relay, Reversing, Trouble -

Relay, Reversing, Trouble Restore -
Relay, Trouble, Disable -
Relay, Trouble, Disable Restore -
Relay, Trouble, Trouble -
Relay, Trouble, Trouble Restore -
Remote Program Fail RU

Remote Programmer Call Failed RA

Remote Programming Begin RB
Remote Programming Denied RD
Remote Programming Success RS
Remote Reset RN
Report, Invalid YN
Report, Status YY
Request to Enter DE
Request to Exit DX
Reset, Sensor XI
Reset, System -
Reset, Watchdog YW

RF, Long Range Trans Fault -

RF, Long Range Trans Fault Restore -
RF, Long Range VSWR Problem -
RF, Long Range VSWR Restore -
RF, Loss of Radio Supervision -
RF, Loss of Radio Supervision Restore -
RF, Loss of Sensor Sup Restore -
RF, Loss of Sensor Supervision -
RF, Radio Transmitter Dis Restore -
RF, Radio Transmitter Disabled -
RF, Repeater Failure -
RF, Repeater Failure Restore -
Schedule Changed JS
Schedule, Access, Change -

Schedule, Exception, Change -

Sensor Trouble -

Sensor Trouble Restore -

Service Completed YZ
Service Required YX

Smoke Detector Hi Sensitivity -

Smoke Detector Hi Sensitivity Restore -
Smoke Detector Low Sen. Restore -
Smoke Detector Low Sensitivity -
Sprinkler Alarm SA
Sprinkler Alarm Restore SH

Sprinkler Alarm/Trouble Restore SR

Sprinkler Bypass SB
Sprinkler Supervisory SS
Sprinkler Trouble ST
Sprinkler Trouble Restore SJ
Sprinkler Unbypass SU
Swinger Bypass -
Swinger Unbypass -
System Peripheral Trouble -
System Peripheral Trouble Restore -
System Ram Checksum Bad -
System ROM Checksum Bad -

System Shutdown -
System Trouble -
System Trouble Restore -
Tamper Alarm TA
Tamper Bypass TB
Tamper Restoral TR
Tamper Trouble TT
Tamper Unbypass TU
Tamper, Expansion Module -
Tamper, Expansion Module Restore -
Telephone Line 1 Fault -
Telephone Line 1 Fault Restore -
Telephone Line 2 Fault -
Telephone Line 2 Fault Restore -

Telephone Line Restoral LR

Telephone Line Trouble LT

Temperature, High -
Temperature, High Restore -
Temperature, Low -

Temperature, Low Restore -

Test End TE
Test Fail XX
Test Report TX
Test, Automatic RP
Test, Manual RX

Test, Off Normal RY

Test, Periodic RF Transmission -
Test, Start TS
Test, Walk, Device End -
Test, Walk, Device Start TP
Tested, All devices TC
Time Changed JT
Time Inaccurate -
Undefined UX
Untyped Missing Alarm UZ
Untyped Missing Trouble UY
Untyped Zone Alarm UA

Untyped Zone Alarm Restore UH

Untyped Zone Alarm/Trouble Restore UR
Untyped Zone Bypass UB
Untyped Zone Supervisory US
Untyped Zone Trouble UT
Untyped Zone Trouble Restore UJ
Untyped Zone Unbypass UU
User Code Added JY
User Code Changed JV
User Code Deleted JX
User Code Tamper JA
User Level Set JZ
Water Alarm WA
Water Alarm Restore WH

Water Alarm/Trouble Restore WR

Water Bypass WB

Water Level Low -

Water Level Low Restore -

Water Pressure Low -

Water Pressure Low Restore -

Water Supervisory WS
Water Trouble WT
Water Trouble Restore WJ
Water Unbypass WU
Zone Bypass -

Zone Bypass Restore -

Country codes
Country Code
Afghanistan 93
Albania 355
Algeria 213
American Samoa 684
Andorra 376
Angola 244
Anguilla 1
Antigua 1
Argentina 54
Armenia 374
Aruba 297
Ascension Island 247
Australia 61
Australian Antarctic Territory 672
Austria 43
Azerbaijan 994
Bahamas 1
Bahrain 973
Bangladesh 880
Barbados 1
Barbuda 1
Belarus 375
Belgium 32
Belize 501
Benin 229
Bermuda 1
Bhutan 975
Bolivia 591
Bosnia and Herzegovina 387
Botswana 267
Brazil 55
British Virgin Islands 1
Brunei 673
Bulgaria 359
Burkina Faso 226
Burundi 257
Cambodia 855
Cameroon 237
Canada 1
Cape Verde Islands 238
Cayman Islands 1
Central African Republic 236
Chad 235
Chile 56
China 86
Christmas Island 672
Cocos-Keeling Islands 61
Colombia 57
Comoros 269
Congo 242
Cook Islands 682
Costa Rica 506
Croatia 385
Cuba 53
Cyprus 357
Czech Republic 42
Denmark 45
Diego Garcia 246
Djibouti 253
Dominica 1
Dominican Republic 1
Ecuador 593
Egypt 20
El Salvador 503
Equatorial Guinea 240
Eritrea 291
Estonia 372
Ethiopia 251
F.Y.R.O.M. (Former Yugoslav Republic of 389
Macedonia)
Faeroe Islands 298
Falkland Islands 500
Fiji Islands 679
Finland 358
France 33
French Antilles 590
French Guiana 594
French Polynesia 689
Gabon 241
Gambia 220
Georgia 995
Germany 49
Ghana 233
Gibraltar 350
Greece 30
Greenland 299
Grenada 1
Guadeloupe 590
Guam 671
Guantanamo Bay 53
Guatemala 502
Guinea 224
Guinea-Bissau 245
Guyana 592
Haiti 509
Honduras 504
Hong Kong 852
Hungary 36
Iceland 354
India 91
Indonesia 62
INMARSAT (Atlantic-East) 871
INMARSAT (Atlantic-West) 874
INMARSAT (Indian) 873
INMARSAT (Pacific) 872
Iran 98
Iraq 964
Ireland 353
Israel 972
Italy 39
Ivory Coast 225
Jamaica 1
Japan 81
Jordan 962
Kazakhstan 7
Kenya 254
Kiribati Republic 686
Korea (North) 850
Korea (South) 82
Kuwait 965
Kyrgyzstan 7
Laos 856
Latvia 371
Lebanon 961
Lesotho 266
Liberia 231
Libya 218
Liechtenstein 41
Lithuania 370
Luxembourg 352
Macao 853
Madagascar 261
Malawi 265
Malaysia 60
Maldives 960
Mali 223
Malta 356
Marshall Islands 692
Martinique 596
Mauritania 222
Mauritius 230
Mayotte Island 269
Mexico 52
Micronesia 691
Moldova 373
Monaco 33
Mongolia 976
Montserrat 1
Morocco 212
Mozambique 258
Myanmar 95
Namibia 264
Nauru 674
Nepal 977
Netherlands 31
Netherlands Antilles 599
Nevis 1
New Caledonia 687
New Zealand 64
Nicaragua 505
Niger 227
Nigeria 234
Niue 683
Norfolk Island 672
Norway 47

Oman 968
Pakistan 92
Palau 680
Panama 507
Papua New Guinea 675
Paraguay 595
Peru 51
Philippines 63
Poland 48
Portugal 351
Puerto Rico 1
Qatar 974
Reunion Island 262
Romania 40
Rota Island 670
Russia 7
Rwanda 250
Saint Lucia 1
Saipan Island 670
San Marino 378
Sao Tome and Principe 239
Saudi Arabia 966
Senegal Republic 221
Seychelle Islands 248
Sierra Leone 232
Singapore 65
Slovak Republic 42
Slovenia 386
Solomon Islands 677
Somalia 252
South Africa 27
Spain 34
Sri Lanka 94
St. Helena 290
St. Kitts 1
St. Pierre and Miquelon 508
St. Vincent and the Grenadines 1
Sudan 249
Suriname 597
Swaziland 268
Sweden 46
Switzerland 41
Syria 963
Taiwan 886
Tajikistan 7
Tanzania 255
Thailand 66
Tinian Island 670
Togo 228
Tokelau 690
Tonga 676
Trinidad and Tobago 1
Tunisia 216
Turkey 90
Turkmenistan 7
Turks and Caicos Islands 1
Tuvalu 688
Uganda 256
Ukraine 380
United Arab Emirates 971
United Kingdom 44
United States of America 1
United States Virgin Islands 1
Uruguay 598
Uzbekistan 7
Vanuatu 678
Vatican City 39
Venezuela 58
Vietnam 84
Wallis and Futuna Islands 681
Western Samoa 685
Yemen 967
Yugoslavia 381
Zaire 243
Zambia 260
Zimbabwe 263
SIA DCS substitution strings
These are the substitution strings that you can use when sending messages to a central
monitoring station account that uses the SIA DCS protocol.

String Description
$(DATE) Inserts the date type code and current date in this
format: daMM-DD-YY
$(TIME) Inserts the time type code and current time in this
format: tiHH:MM:SS
$(USER) Inserts the current user (subscriber) ID in this format:
UUUU
$(USERID) Inserts the user (subscriber) ID type code and current
user ID in this format: idUUUU
TAP substitution strings
These are the substitution strings that you can use when sending messages to a central
monitoring station account that uses the TAP protocol.

String Description
$(") Inserts a quotation mark
$(CR) Inserts a carriage return
$(DATE) Inserts the current date in the format:
MM-DD-YY
$(DDMMYY) Inserts the current date in the format:
DD-MM-YY
$(DDMMYYYY) Inserts the current date in the format:
DD-MM-YYYY
$(LOCATION) Inserts all of the characters in the active
device location message text
$(LOCATION:M- Inserts a string of characters from the
N) active device location message text,
where:
M is the position of the
beginning character to use. M
must be greater than 0 and
less than N.
N is the position of the ending
character to use. N must be
greater than M.
$(MMDDYY) Inserts the current date in the format:
MM-DD-YY
$(MMDDYYYY) Inserts the current date in the format:
MM-DD-YYYY
$(TIME) Inserts the current time in the same
format as $(TIME24)
$(TIME12) Inserts the current time in 12-hour
format: HH:MM:SS X
HH is the current hour from 00 to 12
X is a (for a.m.) or p (for p.m.). These
values are language dependent.
$(TIME24) Inserts the current time in 24-hour
format: HH:MM:SS
HH is the hour from 00 to 23.
$(USER) Inserts the user ID in the format UUUU
$(USERID) Inserts the user ID in the format UUUU
Display and control centers (Canadian marketplace)
In the Canadian marketplace, for a life safety network using display and control centers
(DCCs) each DCC cabinet in a network route must indicate which DCC cabinet or gateway
DCC within the same network routing group is in control of the common control functions of
the network group. The common Reset and Alarm Silence control buttons and any other
control switches on the DCC will be disabled until the DCC is in control of the network.
There are additional operation requirements if the system includes optional features such as
a paging microphone, emergency telephone system, alarm signal silence inhibit, two-stage
operation, or global panel silence.
To meet CAN/ULC-S527 requirements, refer to the EST Canadian Marketplace Manual
(P/N 3102245-EN) for configuration and operating instructions. Chubb Edwards technicians
can download the manual from the Insight website for Canadian Technical Support on the
Technical Documentation > EST3/3X page.
AND groups and the Not Active (NA) device state
The example rule shown below uses an AND group as an input event to light an LED if a
damper door fails to open during a smoke alarm. The AND group is configured as follows:
The AND group contains two devices, Damper_Control and Damper_Monitor. The
Damper_Control has active state Q4 checked. The Damper_Monitor has active
states Q4 and NA checked. The AND group is defined with an Activation Number of
two.
The first device (Damper_Control) is a relay that opens the damper door. The
second device (Damper_Monitor) verifies that the damper opened. When the
Damper_Control relay activates, this increments the activation number by one. The
Damper_Monitor device is not active at this point which also increments the
activation number by one and therefore satisfies the activation number of two. This
causes the AND group to activate.
Note: A ten second delay is programmed in the rule to allow the damper to open. If the
damper does not open after 10 seconds the LED lights steady.
When the damper door opens, the Damper_Monitor device activates and subtracts
one activation number. The AND group activation number is now one, thus the AND
group does not activate and the LED does not light.
[Smoke alarm open damper]
Alarm 'Smk*_Fl<n:1-3>':
Open 'Damper_Control_Fl<n>';
[Light LED if damper does not open]
Monitor 'AND_Group*_Damper_Monitor_Fl<n:1-3>':
+Delay 10,
Steady 'Damper_Not_Open_Fl<n>_LED';
CMS general reporting
These examples show how to program the system for general central monitoring station
reporting. By general reporting we mean reporting these events:
Common fire alarm event
Common supervisory event
Common trouble event
Low battery event
Zoned alarm
Common fire alarm event
[Common fire alarm - Contact ID]
FirstAlarm:
+Send 'Account_Label' MSG "111000000",
-Send 'Account_Label' MSG "311000000";
[Common fire alarm - SIA DCS]
FirstAlarm:
+Send 'Account_Label' MSG "FA",
-Send 'Account_Label' MSG "FH";
Common supervisory event
[Common supervisory - Contact ID]
FirstSupervisory:
+Send 'Account_Label' MSG "120000000",
-Send 'Account_Label' MSG "320000000";
[Common supervisory - SIA DCS]
FirstSupervisory:
+Send 'Account_Label' MSG "ST",
-Send 'Account_Label' MSG "SJ";
Common trouble event
[Common trouble - Contact ID]
CMSFirstTrouble:
+Send 'Account_Label' MSG "130000000",
-Send 'Account_Label' MSG "330000000";
[Common trouble - SIA DCS]
CMSFirstTrouble:
+Send 'Account_Label' MSG "FT",
-Send 'Account_Label' MSG "FJ";
Low battery event
Note: For projects with more than one panel, create an AND group for the battery trouble
pseudo points. Set the Activation Number to 1. Use this AND group in place of the battery
trouble pseudo point in the following rules.
[Low battery - Contact ID]
LocalTrouble 'Batt_trbl_*':
+Send 'Account_Label' MSG "130200000",
-Send 'Account_Label' MSG "330200000";
[Low battery - SIA DCS]
LocalTrouble 'Batt_trbl_*':
+Send 'Account_Label' MSG "YT",
-Send 'Account_Label' MSG "YR";
Zoned alarm event
For zoned alarm reporting, replace the FirstAlarm rule with one of the following:
[Zoned alarm - Contact ID]
Alarm Zone '*<n:1-99>':
+Send 'Account_Label' MSG "1110<n:2>000",
-Send 'Account_Label' MSG "3110<n:2>000";
[Zoned alarm - SIA DCS]
Alarm Zone '*<n:1-999>':
+Send 'Account_Label' MSG "ri<n>FA",
-Send 'Account_Label' MSG "ri<n>FH";
[AND alarm - Contact ID]
Alarm AND '*<n:1-99>':
+Send 'Account_Label' MSG "1110<n:2>000",
-Send 'Account_Label' MSG "3110<n:2>000";
[AND alarm - SIA DCS]
Alarm AND '*<n:1-499>':
+Send 'Account_Label' MSG "ri<n>FA",
-Send 'Account_Label' MSG "ri<n>FH";
Connecting calls on the 3-MODCOM
These rules permit manual connection of calls received by the 3-MODCOM.
This rule activates a light-emitting diode when the MODCOM receives a call.
[Incoming Call on MODCOM]
LocalMonitor 'Incoming_Ring_01_05':
Fast -low 'LED1';
This rule connects the call to the local phone.
[Accept Call on MODCOM]
Switch 'Switch1':
On 'Manual_Answer_Control_01_05',
Steady -high 'LED1';
Setting up a 3-MODCOM failover
This topic presents rules that illustrate dynamic failover for 3-MODCOMs. The sample
project has two 3-MODCOM modules in two separate panels. These report fire alarms to a
central monitoring station (CMS). Here are the details of the configuration:
The first 3-MODCOM is in Panel 1, Slot 5
The second 3-MODCOM is in Panel 9, Slot 7
PrimaryAccount is an off-site monitoring station account on the first 3-MODCOM
BackupAccount is an off-site monitoring station account on the second 3-MODCOM
PrimaryAccount and BackupAccount have the same connection phone numbers and
Account IDs
The example uses an AND group labeled SwitchToBackupModcom. The activation count of
the AND group is 1. The member devices:
First 3-MODCOM network comm fault for the 1st 3-MODCOM (Comm_Fail_01)
First 3-MODCOM line faults (Telephone_Line_1_01_05, Telephone_Line_2_01_05)
First 3-MODCOM comm fault (Rail_Module_Communications_Fault_01_05)
PrimaryAccount
The AND group's activation type is Trouble. When any one of the faults occurs, the AND
group goes active, which enables BackupAccount and disables PrimaryAccount.
For simplicity this example only sends Fire Alarm and Trouble signals. The messages are
coded for a SIA DCS protocol.
[Fire Alarm]
FirstAlarm:
+Send 'PrimaryAccount' "FA1",
-Send 'PrimaryAccount' "FH1",
+Send 'BackupAccount' "FA1" {Duplicate of Primary message}
-Send 'BackupAccount' "FH1" {Duplicate of Primary message};
[Trouble]
FirstTrouble:
+Send 'PrimaryAccount' "FT1",
-Send 'PrimaryAccount' "FJ1",
+Send 'BackupAccount' "FT1" {Duplicate of Primary message},
-Send 'BackupAccount' "FJ1" {Duplicate of Primary message};
[Switch to Backup Account]
LocalTrouble 'SwitchToBackupModcom':
-Send 'PrimaryAccount' "YK1" {Communication Restore},
Disable 'PrimaryAccount',
Enable 'BackupAccount',
+Send 'BackupAccount' "YS1" {Communication Trouble};
[Startup]
Startup:
Disable 'BackupAccount' {At startup use PrimaryAccount until
fault detected};
Disabling IP accounts
These examples show you how to disable a single IP account or all IP accounts linked to an
Ethernet card by using a switch. The CMS is notified when an account is disabled or
enabled.
Disabling a single account
The following rule disables a single IP account linked to an Ethernet card and notifies the
CMS.
[Disable IP account]
Switch 'Switch_Label':
+SendIP 'Account_Label' MSG "155100000" {Disable account
message},
-SendIP 'Account_Label' MSG "355100000" {Enable account
message},
Disable 'Account_Label';
Disabling all accounts
The following rule disables all IP accounts linked to an Ethernet card and notifies the CMS.
[Disable all IP accounts]
Switch 'Switch_Label':
+SendIP 'Account_Label <N:001-255>' MSG "155100<N:3>" {Disable
account message},
-SendIP 'Account_Label <N:001-255>' MSG "355100<N:3>" {Enable
account message},
Disable 'Ethernet_Card_Label';
See also
SendIP command
Common security alarm function
This rule emulates a common security alarm function. When the project includes a local bell,
you can use a rule similar to this to ensure that all security input devices have an output
response.
The rule is triggered when the Common_Security_Alarm command list is activated. It
disables the command list object so that multiple activations are suppressed, rings the
security bell for fifteen minutes, then turns off the bell and enables the command list for
further events.
[Common Security Alarm]
Activation 'Common_Security_Alarm':
Disable 'Common_Security_Alarm',
On -set 'Security_Bell_*',
Delay 900,
Off -set 'Security_Bell_*',
Enable 'Common_Security_Alarm';
Performing a closing confirmation
Security systems that include central monitoring station reporting might require confirmation
that the station has received a closing (partition arming) message. This is called closing
confirmation or ring back. You can use the KPDISP sounder or a local security bell to
provide audible confirmation.
To program closing confirmation, use the Confirm parameter of the Send command to
activate a command list. Write rules to operate the audible device using the Activation event
for that command list.
Here is an example of how the Send command would be written, using the Confirm
parameter. This rule uses SIA DCS format to send a closing message to the CMS. The
send command uses the Confirm parameter to activate a command list when the CMS
confirms receipt of the message.
[Closing]
SecurityExitTimer 'Partition_<n:1-3>':
+Send 'CMSAccount<n>' Msg "CL" Confirm 'Confirm_Closing_<n>';
The next rule uses the security bell to signal confirmation of the closing. The rule is
triggered when the Confirm_Closing command list is activated. It disables the command list
object so that multiple activations are suppressed, rings the security bell for ten seconds,
then turns off the bell and enables the command list for further events.
[Confirm closing with bell]
Activation 'Confirm_Closing_<n:1-3>':
Disable 'Confirm_Closing_<n>',
On -set 'Security_Bell_<n>',
Delay 10,
Off -set 'Security_Bell_<n>',
Enable 'Confirm_Closing_<n>';
The next rule uses the KPDISP sounder to signal confirmation of the closing.
[Confirm closing with KPDISP sounder]
Activation 'Confirm_Closing_<n:1-3>':
Disable 'Confirm_Closing_<n>',
On -high 'Keypad_Buzzer_<n>'
Delay 10,
Off -high 'Keypad_Buzzer_<n>',
Enable 'Confirm_Closing_<n>';
Programming a general ACFail event response
When programming for an AC failure, the ACFail device must be part of an AND group. The
following programming example illustrates how to set up AND groups for a general ACFail
event.
{******************** GENERAL ACFAIL ********************}
[GENERAL ACFAIL – RULE 1]
ACFAIL 'AC_Brownout_0<N:1-8>_02' : ON 'LOGIC_ACFAIL' ;
[GENERAL ACFAIL – RULE 2]
RLYCFG 'LOGIC_ACFAIL' : ACTIVATE 'AND_ACFAIL' ;
[GENERAL ACFAIL – RULE 3]
CMSFIRSTTROUBLE : ACTIVATE 'AND_ACFAIL' ;
[GENERAL ACFAIL – RULE 4]
MON 'AND_ACFAIL' : +SEND 'ACCT_1' MSG "130100000" ,
-SEND 'ACCT_1' MSG "330100000" ;

To program a general AC Fail event response:

1. Create an AND group. Label the AND group: AND_ACFAIL. Do not assign any
members, set Activation Number to 2, and set Activation Event to Q4 – Monitor (All
Others).
2. Create a logical output. Label the logical output: LOGIC_ACFAIL.
3. Write a rule that activates the logical output (LOGIC_ACFAIL) when any AC Fail
device type activates. See General ACFail – Rule 1. Note: In this example there are
eight control panels (eight AC Brownout pseudo points, one for each panel).
4. Write a rule that increments the AND group activation counter when the
LOGIC_ACFAIL logical output is activated. See General ACFail – Rule 2.
5. Write a rule that increments the AND group activation counter when the CMS First
Trouble Response pseudo point activates. See General ACFail – Rule 3.
6. Write a rule that transmits (sends) the general AC Fail event activation code when
the AND group activates, and the general AC Fail event restoration code when the
AND group restores. See General ACFail – Rule 4.
Security bell test from KPDISP
This rule executes a security bell test from the KPDISP.
Activation 'Test_Bells':
on 'Security_Bell' { Activate the NAC circuit },
Delay 6 { Short delay to verify bell operation },
Off 'Security_Bell' { Shut the bell off again };
Controlling the indicator light on a warden station
6830-NY-S/F warden stations require a rule to control the indicator light. The light should be
toggled on whenever a connection is established from the remote telephone station to the
firefighter’s telephone in the fire command and control center. This is done by energizing the
control relay module. Modify and use the sample rule given below to perform this function.
[FIREPHONE LED]
RLYCFG 'Firephone_Floor1':
ON 'Firephone_relay_Floor1';

To adapt the rule for your own use:

1. In place of Firephone_Floor1, substitute the label that you have assigned to the
remote telephone signal module.
2. In place of Firephone_relay_Floor1, substitute the label that you have assigned to
the control relay (SIGA-CR or SIGA-CRT) that connects the firephone LED to the
24 volt riser.

To substitute the short form of the CallIn input event

Using the short form of the RelayConfirmation input event, the rule can be rewritten like this:
[FIREPHONE LED]
RLYCFG 'FIREPHONE_FLOOR1':
ON 'FIREPHONE_RELAY_FLOOR1';

To use an n-variable
If your object labeling plan permits, you could rewrite the rule using an n-variable to
represent the level or floor number. Doing so allows a single rule to control multiple remote
firefighter’s telephones.
The following sample rule is for a 15-story building with one remote firefighter’s telephone
on each floor.
[FIREPHONE LED]
RLYCFG 'FIREPHONE_FLOOR<n:1-15>':
ON 'FIREPHONE_RELAY<n>';
For more information on working with <n> variables, see Using N-variables.
CRC load shedding
This rule provides load shedding for the maglocks and card readers attached to the CRCs
on this panel. Disabling both readers will cause the CRC to power down the readers. With
the readers powered down, the strike will effectively be load shed as well.
The <n:1-2:2> on the left hand side will match labels containing '01' & '02'. The <n:2> will
match '01' & '02' on the right hand side. So the single rule will have power on the local panel
control load shed for the CRCs connected to that panel.
[CRC Load Shed]
LocalTrouble 'AC_Brownout_<n:1-2:2>_03':
Delay 60 { Short AC fail debounce delay },
On 'Door_Unlock_<n:2>*' { Unlock all doors },
Delay 14340 { 4 hours delay },
On '*Reader_Disable_<n:2>*' { Disabling all readers will load
shed };
Downloading files
To complete the system programming process, you must download the application code,
bootloader code, converted database files that contain rules, and configuration data into
their respective rail modules.
Downloading is required whenever you:
Bring a system up for the first time
Upgrade the microcode (application and bootstrap) used in the programmable rail
modules
Make any changes to the project database (project configuration, hardware
configuration, or rules file)
When you begin a download session, the panel receiving the SDU takes the data files out of
service temporarily, until the download finishes. When you download data files over the
network to multiple panels, the SDU takes each panel individually out of service and brings it
back into service only after the download session has finished transferring files to all of the
panels.
Note: A panel that is programmed for standalone operation will activate its alarm signaling
outputs even while out of service.
The SDU provides a single-step mode and network mode for downloading files. Use the
single-step mode when you want to download files to individual rail modules through a direct
connection on the module. Use network mode when downloading files to rail modules over
the rail bus or over the network.
See also
Compile and download
Downloading to a single rail module
Downloading files across the network
Assigning a panel address for first-time installations
When a system is first installed, you must download the CPU database for each panel
separately to give each panel its correct panel address. After each panel has its correct
address, you can perform subsequent downloads over the network. Depending on firmware
revision compatibility, the first time you download the database you may also need to
download the bootloader code and application code at the same time.
Note: The target panel must have a 3-RS232 option card installed on the 3-CPU1.
To assign a panel address for first-time installations:
1. On the 3-CPU1, disconnect the network data riser on the Network A and B
terminals.
2. Connect the download cable assembly from SDU computer to the modular phone
jack on the 3-CPU1.
3. From the Tools menu, select Communications.
4. Set the display filters for the following:
File Display Filter: Application Code, Bootloader Code, and Database
LRM Type Display Filter: CPU1
Cabinet Filter: the cabinet number for the target panel
5. For each record displayed, double-click the Action boxes and select Download.
6. Click Single Step download mode.
7. Click Download/Upload.
8. On the LRM Communications dialog box, click Start.
9. Verify that you are connected to the correct module, then click OK. SDU displays a
dialog box indicating that the selected module and actual module have different
cabinet numbers.
10. Do one of the following:
If the new cabinet number is correct, click Force operation then click OK.
If the new cabinet number is not correct, click Abort communications then click OK.
11. Follow any instructions displayed on the screen and close all dialog boxes after
completing the download.
12. On the 3-CPU1, reconnect the network data riser on the Network A and B terminals.
13. Disconnect the download cable assembly from the modular phone jack on the 3-
CPU1.
Tip: Save a version of your project that only includes cabinets for the specific purpose of
assigning panel addresses. Do not include rail modules, devices, or rules. Downloading a
cabinet-only version is quicker and then you can load everything else over the network.
Downloading files across the network
The network download mode lets you download application code, bootloader code, and
database files over the rail bus to rail modules in a single panel or to any panel on the
network data riser.
If you want to download data to every panel across a class B network data riser, the
download panel must be the first connection on the network data riser (the one with no
connection on the Network A terminals.) With Class A network wiring make sure to connect
to the first panel in the network. Class B wiring only allows downloading to panels
downstream of the panel to which you are connected.
Note: You can download the application code, bootloader code, and database files
separately or in any combination.

To download files across the network:

1. Connect the download cable assembly from SDU computer to the modular phone
jack on the CPU.
2. From the Tools menu, select Communications.
3. Set the Action boxes to Download for each rail module and data file type you want
to download.
4. Click Network download mode.
5. Click Download/Upload.
6. On the LRM Communications dialog box, click Start.
7. Follow any instructions displayed on the screen and close all dialogs after
completing the download.
8. Disconnect the download cable from the CPU.
See also
Downloading files
Downloading to a single rail module
Downloading to a single rail module
The single step download mode lets you download application code, bootloader code, and
database files to rail modules individually through a direct connection to the rail module. You
can download to one rail module in a single download session or you can download to
multiple rail modules. When you download to multiple rail modules, the SDU prompts you
when to change download connections.
Note: You can download the application code, bootloader code, and database files
separately or in any combination.
To download to a single rail module:
1. Connect the download cable assembly from SDU computer to the modular phone
jack on the target rail module.
2. From the Tools menu, select Communications.
3. Set the Action boxes to Download for each rail module and data file type you want
to download.
4. Click Single Step download mode.
5. Click Download/Upload.
6. On the LRM Communications dialog box, click Start.
7. Follow any instructions displayed on the screen and close all dialogues after
completing the download.
8. Disconnect the download cable from the rail module.
See also
Downloading files
Downloading files across the network
SDU reports
The SDU provides a number of predefined reports to help you configure and document your
project. Using the built-in report generator, you can view information about your project
online and print a hard copy.
To start the report generator, select Reports On the menu bar and choose one of the
predefined reports from the drop-down menu.
SDU provides the following predefined reports.

Report Description
Cabinets Displays a list of cabinets and their configuration
properties.
R-Series Annunciators Displays a list of remote annunciators for each associated
Report cabinet, listing for each annunciator its type, banner text,
and expander settings.
CMS Messaging Report Displays a list of messages that can be sent to the off-site
monitoring station, their activating event, and activating
device location. The report is based on the cabinet,
MODCOM, receiver, and account you select.
Compiler/Conversion Displays a list of warnings and error messages generated
Messages from the rules compiler based on the selected message
type and priority.
IP Dialer and Email > CMS Displays the configuration of the IP service type you have
Report selected.
IP Dialer and Email > IP Displays the configuration of the receiver account you
Accounts Report have selected.
IP Dialer and Email > Email Displays the configuration of the email account you have
Accounts Report selected.
IP Configuration Report Displays the configuration of the DHCP, DNS, port, and
Ethernet card type for the cabinet you have selected.

IP Dialer and Email > CMS Displays a list of messages that can be sent to the off-site
Messaging Report monitoring station, their activating event, and activating
device location. The report is based on the cabinet, dialer,
receiver, and account you have selected.
Logic Group Membership Displays a list of logic groups and their members.
Loop Controller Devices > Displays a list of detectors or modules and their device
Signature Barcode address in bar code format. This report is used by
Worksheet equipment installers and the system programmers.
Loop Controller Devices > Displays a list of Signature detectors and modules and
Signature their configuration.
Detectors/Modules
Loop Controller Devices > Displays a list of analog addressable sensors and modules
Analog Addressable Devices and their configuration.
Loop Controller Devices > Displays a list of Edwards analog sensors and modules
Edwards Analog Devices and their configuration (if applicable to the current
marketplace).
LRM Displays a list of LRMs for the selected cabinet.
Modcom > Accounts Displays a list of MODCOM accounts base on the
MODCOM you have selected

Modcom > Receivers where Displays a list of MODCOM receivers base on the
used MODCOM you have selected

Msg Annunciation Routing > Displays, for each annunciation group, the type, address,
Msg Annunciation Group cabinet label, LRM label, and object label of each member.
Membership
Msg Annunciation Routing Displays, for each annunciation group, the logical address,
>Object Annunciation device type, label, and message annunciation label.
Correlation
Objects Displays a list of SDU objects and their logical addresses
for all or selected LRMs
Objects Without Labels Displays all the objects in the project database that have
not been assigned a label
Project Configuration Displays the configuration parameters of the currently
open SDU project

Project History Displays a historical list of selected events within the open
project
Rule Related > Input/Output Displays the inputs and the outputs for each rule in the
By Rules SDU. You can select to see all rules or only an individual
rule.
Rule Related > Input/Output Displays a list of devices by their logical address and the
Correlation devices that respond to their rule activation. The report lets
you filter the selection of devices that you want to display.
Rule Related > Object in Displays all the rules containing a specific object label
Rules
Rule Related > Unused Displays all objects that are not used in any rule
Object Labels
Security and Access Control Displays all security type devices that are not included in
> Security Devices not in a any partitions
Partition
Security and Access Control Displays a list of devices connected to a 3-SAC and their
> device addresses in bar code format. This report is used
3-SAC Barcode Worksheet by equipment installers and the system programmers.
See also
Project comparison report
Creating a project comparison report
Managing existing project comparison reports
Project comparison report
The Project Compare Utility (PCU) generates a report that compares the SDU project
currently open with a previous version of the same SDU project. The PCU report shows the
differences between the two project versions.
Each project comparison report is divided into sections and subsections based on
differences between the two project versions. Sections and subsections are identified by
headers. All section headers are displayed as black rows with white text.
Subsection headers are displayed within sections and identify additions, deletions, or
changes. Subsection headers might or might not be displayed based on the differences
between the projects and the level of detail chosen for the report. Subsection headers are
displayed as white rows with black text.
Note: If nothing has changed between the two projects for a section, that header is not
displayed in the report.
Compare Project Information sections
Each PCU report starts with the Compare Project Information section header. See the
figure below. This section displays detail information about the two projects being
compared. Listed below are definitions of the compare project information provided.
Project Name: Displays the name of the projects as they are saved in the SDU
CU Version: Displays the version number of the 3-SDU software
Project Version: Displays the version number of SDU projects
Revision: Displays the number of times the project has been saved in its current
version
Conversion: Displays the date and time when the last CPU database (DB)
conversion was performed on the project. If a CPU DB conversion has never been
performed, the row is blank.
Last Updated: Displays the date and time when the projects were last saved
User Label: Displays the user label of SDU projects. The same label is also
displayed on the LCD screen of a green panel.
Description: Displays the project description text you entered in the Project
Parameters dialog
Firmware section
The Firmware section shows the differences between the downloaded firmware versions
for the CPU and installed rail modules.
Project Data section
Project Data Changes subsection
The Project Data section shows the differences between project properties for the two
projects. Project properties are configured in the SDU by clicking the Project command on
the Configure menu. If nothing has changed between the two projects, the Project Data
header is not displayed in the report.
Routings section
The Routings section shows all network and partition routing differences between the two
projects. Routing differences are displayed in the three subsections named Routing
Additions, Routing Deletions, and Routing Changes.
If nothing has changed between the two projects for a given subsection, the header and
subsection body are not displayed in the report.

Routing Additions subsection

The Routing Additions subsections list all network and partition routes that have been added
to the current project.

Routing Deletions subsections

Routing Deletions subsections list all network and partition routes that have been deleted
from the current project.

Routing Changes subsections

Routing Changes subsections list all network and partition routes that have been modified in
the current project. Each network and routing change is followed by an individual property
table detailing the change. The property table identifies which cabinets or partitions have
been added or deleted from the route.
Logic Groups section
The Logic Groups section shows logic group differences between the two projects. Logic
groups include the following: AND, command lists, guard patrol, instructional text, matrix,
partition, service, time control, and zone. Logic group differences are displayed in the
subsections named Logic Group Additions, Logic Group Deletions, and Logic Group
Changes.
In addition to differences in logic groups, the PCU also shows differences in the members
of a logic group. Members are the devices that make up the logic group. Logic group
member differences are displayed in the subsections named Member Additions, Member
Deletions, and Member Changes. If nothing has changed between the two projects for a
subsection, that header is not displayed in the report.
Logic Group Additions subsections
Logic Group Additions subsections list new logic groups that have been added to the
current project.

Logic Group Deletions subsections

Logic Group Deletions subsections list all logic groups that have been deleted from the
current project.

Logic Group Changes subsections

Logic Group Changes subsections list all logic groups that have been modified in the current
project. Each logic group change is followed by an individual property table detailing the
changes or a list of added, deleted, or changed members.

Member Additions subsections

Member Additions subsections list all members added to a new logic group or an existing
logic group. If a member has been added to a new logic group, member additions are
displayed underneath the subsection header for Logic Group Additions. If a member has
been added to an existing logic group, member additions are displayed underneath the
subsection header for Logic Group Changes.

Member Deletions subsections

Member Deletions subsections list all members removed from an existing logic group or a
deleted logic group. If a member has been deleted from an existing logic group, member
deletion is displayed underneath the subsection header for Logic Group Changes. If a logic
group has been deleted, all members associated with that logic group are also deleted.
Member deletions are then displayed underneath the subsection header for Logic Group
Deletions.

Member Changes subsections

Member Changes subsections list all members whose properties have changed within a
logic group. Each member change is followed by an individual property table detailing the
changes.
Cabinet sections
The Cabinet sections show all cabinet, LRM, device, and rule response differences
between the two projects. Cabinet differences are displayed in three sections named
Cabinet Additions, Cabinet Deletions, and Cabinet Changes. LRM differences are displayed
underneath the cabinet that they are associated with. Device changes are shown
underneath the cabinet and LRM that they are associated with. Rule response changes are
displayed underneath the cabinet, LRM, and device that they are associated with. If nothing
has changed between the two projects for any subsection, that header is not displayed in
the report.
Cabinet Changes sections list cabinets that have been modified in the current project. Each
cabinet change is followed by an individual property table detailing the changes or a list of
added, deleted, or changed LRMs.
LRM subsections
LRM Additions subsections
LRM Additions subsections list all LRMs added to a new cabinet or an existing cabinet. If
an LRM has been added to a new cabinet, LRM additions are displayed underneath the
section header for Cabinet Additions. If an LRM has been added to an existing cabinet,
LRM additions are displayed underneath the section header for Cabinet Changes.

LRM Deletions subsections

LRM Deletions subsections list all LRMs removed from an existing cabinet or a deleted
cabinet. If a LRM has been deleted from an existing cabinet, LRM deletion is displayed
underneath the section header for Cabinet Change. If a cabinet has been deleted, all LRMs
in that cabinet are also deleted. LRM deletions are then displayed in the Cabinet Deletions
section.

LRM Changes subsections

LRM Changes subsections list LRMs that have been modified within the current project. The
cabinet that the LRM belongs to is displayed above the LRM change. All LRM changes are
followed by an individual property table detailing the changes or a list of added, deleted, or
changed devices.
Device subsections
The Device subsections are broken down into Device Additions, Device Deletions, and
Device Changes. The Device subsections not only shows differences in devices, but also
show differences in pseudo points. Pseudo points differences are displayed for LRMs, logic
groups, and projects.

Device Additions subsections

Device Additions subsections list new devices that have been added to the current project.
If devices were added to a new LRM, device additions are displayed underneath the
subsection header for LRM Additions. If devices were added to an existing LRM, device
additions are displayed underneath the subsection header for LRM Change.

Device Deletions subsections

Device Deletions subsections list devices that have been deleted from the current project.
The cabinet and the LRM that the device has been deleted from are displayed above the
device deletion.

Device Changes subsections

Device Changes subsections list devices that have been modified within the current project.
The cabinet and the LRM that the device belongs to are displayed above the device
change. Each device change is followed by an individual property table detailing the change.
Response subsections
Responses are the system input events or device responses that are created by
programming rules. Additions, deletions, or changes to rules that determine responses are
listed in the Response subsections. Responses are always displayed below the device that
the rule effects. The action column of the response shows if the rule was added, deleted, or
changed.

The Response subsections

The Response subsections list responses that have been changed or added for a device. If
a response was added for a new device, the response is displayed underneath the
subsection header for Device Additions. If a response was changed for an existing device,
the response is displayed underneath the subsection header for Device Changes.
See also
Creating a project comparison report
Managing existing project comparison reports
Creating a project comparison report
The Project Compare Utility (PCU) generates a report that compares SDU project currently
open with a previous version of the same SDU project. The PCU report shows the
differences between the two project versions. This report is helpful to system installers and
AHJs for testing and verification.
On the Project menu, the Compare command launches SDU Project Compare Utility dialog
box. The PCU dialog lets you select any previous version of SDU project you want to
compare. You can only compare the current project with a previous saved version of the
same project. The dialog also provides you with the following descriptive information about
the two projects being compared:
Project Name
Project Version
Revision
Conversion date and time
Last update date and time
User Labels
Description
Each report can be viewed in one of three levels of detail. These are:
Cabinet Level: Shows cabinet additions, deletions, and changes. A cabinet is listed
as changed if any cabinet property, LRM, or device in the cabinet has changed.
LRM Level: Shows cabinet and LRM additions, deletions, and changes. An LRM is
listed as changed if any LRM property or device on the LRM has changed.
Device: Shows all changes down to the device level including cabinets changes,
LRM changes, and device changes.
Note: Project properties, routing, and logic groups are displayed in all PCU report levels.
To create and print a project compare report:
1. On the Project menu, click Compare.
2. In the Project Version list, click the project version you want to compare.
3. Click the Start Compare button.
4. Click OK when the report has been created.
5. Click the level of detail for the report. The default is Detail.
6. Click the View Report button. The report is displayed in the Preview Form dialog
box.
7. To print the Comparison Report, click the Print toolbar button.
8. To close the report, click the Close button.
9. On the Project menu, click Save to save the CPU report for later viewing.
See also
Project comparison report
Managing existing project comparison reports
Managing existing project comparison reports
SDU Project Compare Utility (PCU) lets you manage your previously created project
comparison reports. By "manage" we mean that you can view, print, and delete any PCU
reports created and saved in the SDU. All PCU reports relate only to the current, open
version of SDU project. The reports are displayed in the Manage Existing Reports dialog
box. The reports are displayed in the order they were created. Each row of the table
represents a single report. The table displays the following information about the report:
Current Revision
Compare Version
Compare Revision
Detail Level
Date Generated
Note: If SDU project is not saved after the creation of a PCU report, the report will not be
displayed in the Manage Existing Reports dialog box.
To view and print existing project compare reports:
1. On the Project menu, click Compare.
2. Click the Manage Existing Reports button. The Manage Existing Reports dialog is
displayed.
3. Click the report that you want to view.
4. Click the View Report button. The report is displayed in the Preview Form dialog
box.
5. To print the Comparison Report, click the Print toolbar button.

To delete existing project compare reports:

1. On the Project menu, click Compare.
2. Click the Manage Existing Reports button. The Manage Existing Reports dialog is
displayed.
3. Click the report that you want to delete.
4. Click the Delete Report button. The report is deleted from your project.
See also
Creating a project comparison report
Project comparison report
AC power fail monitoring
In this application, if a control panel loses AC power or if its AC power falls below the
brownout level, the AC fail power monitoring feature turns off the Power LED on the control
panel and all remote annunciators powered by the control panel. The Power LED on all
other control panels and remote annunciators remain on.
Likewise, if a remote booster supply is used to power a remote annunciator and it loses AC
power or its AC power falls below the brownout level, the AC fail power monitoring function
turns off the Power LED on the remote annunciator.

Typical AC power fail monitoring application diagram

(1) Control panel

(2) Remote booster power supply
(3) CT1 module used to monitor AC power failures on the remote booster power supply
(4) Remote annunciator panel powered by the remote booster power supply
(5) Remote annunciator panel powered by the control panel

To set up AC power fail monitoring on a remote annunciator powered by a control

panel:
1. On the Configure menu, click Cabinet to open the Cabinet Configuration dialog box.
2. On the Cabinet tab, select the remote annunciator then click the Options tab.
3. On the Options tab, click the AC Power Monitored By box then click the control
panel’s AC brownout pseudo point
To set up AC power fail monitoring on a remote annunciator powered by a remote
booster power supply:
1. On the Configure menu, click Cabinet to open the Cabinet Configuration dialog box.
2. On the Cabinet tab, select the remote annunciator then click the Options tab.
3. On the Options tab, click the AC Power Monitored By box then click the CT1 module
used to monitor the AC power failures on the remote booster power supply.
Interlocks
Typically, interlocks are used in smoke control applications to display the status of
controlled equipment (CE), such as damper actuators and fan on/off controls. The diagram
below shows a typical interlock application.
Note: The interlock feature is available only for the China (Local and Prop) marketplaces.

Typical interlock application diagram

(1) Control panel

(2) Interlock output device. Typically a CC1 or MCC1 module
(3) Interlock feedback device. Typically a CT1, CT2, or MCT2 module
(4) Controlled equipment

When an interlock output device is activated, the control panel receives a signal within the
feedback response time, indicating that the controlled equipment operated correctly. If not,
the control panel posts an interlock feedback failure.
Defining an interlock
Interlocks are defined on the Assign Interlockfeedback Devices to Interlock Devices dialog
box. Interlock feedback devices that are assigned to another interlock output device are
displayed in red. You can assign one or more interlock feedback devices to only one
interlock output device.

To define an interlock:
1. On the Configure menu, click Cabinets.
2. On the Cabinet Configuration dialog box, select the required control panel then click
the Modules tab.
3. On the Modules tab, select the required loop controller, click LRM Config, and then
click the Loop x Modules tab for the required loop (the signaling line circuit) with the
interlock output and interlock feedback devices.
4. On the Loop x Module tab, click Assign Interlockfeedbacks.
Note: The Device Type must be set as "Interlockfeedback" for the Assign
Interlockfeedbacks button to be available.
5. Select the interlock output device on the left side of the dialog box, and then click the
check box of the required interlock feedback devices on the right side of the dialog
box.
6. Click Close when you are finished.
Specifying the interlock feedback response time
The project's Feedback Response option determines how much time is allowed for
controlled equipment to operate correctly before the control panel indicates a failure.

To specify an interlock feedback response time:

1. On the Configure menu, click Project.
2. Click the Timing tab.
3. In the Feedback Response box, type or select a value from 10 to 120 seconds.
Select a value that is equal to or greater than the longest response time required by any
controlled equipment in the system.
See also
Interlock device type
InterlockFeedback device type
InterlockFailure event
Positive alarm sequence
This topic describes how to program a positive alarm sequence feature that meets UL 864
9th edition requirements. Before you begin, you should also have a good understanding of
the following:
Command lists
Logical outputs
AND groups
Priorities
Activate and Restore commands
Disable and Enable commands
This topic presents one method for programming this application. It is not the only method.
It is your responsibility to make adjustments as needed to suit your particular project and to
thoroughly test the application before putting it to use at the site.
Positive alarm sequence operation
UL 864 9th edition defines positive alarm sequence as an automatic sequence that results in
an alarm, even when manually delayed for investigation, unless the system is reset.
Detailed description
System configuration
For this application, you will need to configure the following:
One toggle switch and LED for bypassing positive alarm sequence. Label the
switch: Swi_PAS_Bypass. Label the LED: LED_PAS_Bypass.
One momentary switch and LED for acknowledging positive alarm sequence. Label
the switch: Swi_PAS_Ack. Label the LED: LED_PAS_Sequence.
One logical output. Label the logical output: LogicOutput_PAS_Ack_Switch_Active.
Two command lists. Label the command lists: Cmd_List_PAS_General_Alarm and
Cmd_List_PAS_NonPAS_Devices.
Three AND groups. Configure the AND groups as follows:

AND Group 1 Label: AND_Group_PAS1

Activation Number: 2
Activation Event: Q1 - Alarm
Devices in Selected Group: All PAS devices
AND Group 2 Label: AND_Group_PAS2
Activation Number: 1
Activation Event: Q1 - Alarm
Devices in Selected Group: All PAS devices
AND Group 3 Label: AND_Group_PAS3
Activation Number: 2
Activation Event: All check boxes cleared
Devices in Selected Group: None

In addition:
Ensure that the Restore Event on Disable check box is not checked (Configure >
Project > Operations). If checked, the system will not bypass the positive alarm
sequence.
Set the Silence Inhibit option for 0 minutes (Configure > Project > Timing).
Configure all outputs as Audible or Visible device types as required. Do not
configure outputs as CommonAlarmOutput device types.
For all PAS smoke detectors, set the Alarm Verify option and the Alt Alarm Verify
option to None.
Set the message routing options for the switches and AND Group 3 to the no
message routing group. Set the message routing options for AND Group 1 and AND
Group 2 to the all message routing group. If you do not, the SDU compiler may stop
(depending on your marketplace setting).
Programming
This section provides the rules required to program this application. It also includes a
description of the logic behind the rules.
Notes
We labeled the PAS smoke detectors as *_PASSmk_* and the non-PAS devices as
*_Smk_*, *_Pull_*, *_Heat_*, etc.
You can only use smoke detectors to initiate a positive alarm sequence.
General alarm rules

[Non-PAS Smokes General Alarm - Rule 1]

Alarm Smoke '*_Smk*' :
Activate 'Cmd_List_PAS_NonPAS_Devices' ;

[Non-PAS Heats General Alarm - Rule 2]

Alarm Heat '*_Heat*' :
Activate 'Cmd_List_PAS_NonPAS_Devices' ;

[Non-PAS Pulls General Alarm - Rule 3]

Alarm Pull '*_Pull*' :
Activate 'Cmd_List_PAS_NonPAS_Devices' ;

[Non-PAS Flows General Alarm - Rule 4]

Alarm Waterflow '*_Flow*' :
Activate 'Cmd_List_PAS_NonPAS_Devices' ;

[Non-PAS Devices Active CmdList]

Activation 'Cmd_List_PAS_NonPAS_Devices' :

Activate 'And_Group_PAS1' , {== Activates PAS 1

AND Group twice to force a general
alarm. ==}
Activate 'And_Group_PAS1' ,
Disable 'And_Group_PAS2' ; {== Disables the
PAS2 AND Group without generating the
phase 1 sequence
when a non-PAS device is alarmed. ==}

{== AND Group PAS1 activation of 2 Alarm ==}

[PAS Active General Alarm - AndGroup]
Alarm 'And_Group_PAS1' : {== At this point,
the system is in the
PAS General Alarm
state, meaning that
phase 1 and 2
timers have expired. ==}
Activate 'Cmd_List_PAS_General_Alarm' , {== Puts the
system in the PAS
General Alarm
active state. ==}
Dly 0 ,
-Enable 'Cmd_List_PAS_General_Alarm' ;

[PAS General Alarm Active CmdList]

Activation 'Cmd_List_PAS_General_Alarm' :
Disable 'Cmd_List_PAS_General_Alarm' {== Disables the Gen
Alarm command
list, as we do not
wish to run this
again if other
detectors go active ==}
Steady 'LED_PAS_General_Alarm' , {== Instead of an
LED, all
corresponding
audibles and visibles
may be turned ON
here ==}
LEDoff 'LED_PAS_Sequence' , {== Indicates that
the PAS sequence is not active
and we are
currently in the General Alarm state. ==}
Disable 'Swi_PAS_Ack' , {== Disables the PAS
Ack switch so
that the user may not
interrupt the system.
 A reset is required
at this point. ==}
Disable 'Swi_PAS_Bypass' ; {== Disables the PAS
Bypass switch.
The bypass no longer
applies in this state.
A reset is required
at this point. ==}

PAS bypass rules

[PAS Bypass Toggle Switch]

SW 'Swi_PAS_Bypass' :
Activate 'And_Group_PAS1' , {== Activates the
PAS1 And Group. This allows for any
single active PAS
sensor to put the system in alarm
rather than waiting
for two, as the sequence is now
bypassed. ==}
Steady 'LED_PAS_Bypass' , {== Indicates the
fact that the PAS sequence is bypassed.
==}
Off -High 'LED_PAS_Sequence' ; {== Turns Off the PAS
Sequence LED with High priority so
that any PAS device
doesn't turn it On in any phase. ==}

PAS sequence rules

[PAS Startup]
Startup :
Disable 'Swi_PAS_Ack' ; {== Disable the PAS
Ack switch upon startup, as there
is nothing to
acknowledge until the system is alarmed. ==}
{== AND Group PAS2 activation of 1 Alarm ==}
[PAS Phase 1 Active]
Alarm 'And_Group_PAS2' :
Enable 'Swi_PAS_Ack' , {== Enable the PAS
Ack switch to allow the user to
acknowledge the
alarm. ==}

Fast 'LED_PAS_Sequence' , {== Indicate that PAS

phase 1 is active. ==}
Disable 'Swi_PAS_Bypass' , {== Disable the
bypass switch so that the user may not
bypass the PAS
sequence once started. ==}
+Dly 15 , {== Delay for 15
seconds to allow user to acknowledge the
alarm. ==}
Activate 'And_Group_PAS1' ; {== Ack timer has
expired. The system is now in the PAS
General Alarm state.
Activating AND Groups PAS1 again,
will make it go
active, thus PAS General alarm active ==}

{== Momentary Switch ==}

[PAS Ack Switch - Rule 2]
Switch 'Swi_PAS_Ack' :
+On -High 'LogicOutput_PAS_Ack_Switch_Active' ; {==
Acknowledge the PAS alarm. This will start PAS
phase 2. ==}

[PAS Phase 2 Active]

RlyCfg 'LogicOutput_PAS_Ack_Switch_Active' :
+Restore 'And_Group_PAS2' , {== Restoring
AND Group PAS2 prevents the system

from going
into the PAS General Alarm state. ==}
 Activate 'And_Group_PAS3' , {== Activates
AND Group PAS3 to set its activation
counter to
1, thus allowing the reset rule to

cancel the
PAS Gen Alarm. ==}
Slow 'LED_PAS_Sequence' , {== Indicates
that PAS phase 2 is active. ==}
+Dly 180 , {== Delay 180
seconds to allow a system reset
before going
into the PAS General Alarm state. ==}
Activate 'And_Group_PAS1' ; {== PAS phase
2 timer expired. Put system in PAS
General
alarm state. ==}

[PAS Reset - RULE 1]

Reset : Activate 'And_Group_PAS3' ; {== AND Group
PAS3 activation of 2 None ==}

[PAS Reset - RULE 2]

Monitor 'And_Group_PAS3' :
+Off -High 'LogicOutput_PAS_Ack_Switch_Active' ; {== Reset
has occurred. Restores the PAS sequence
operations
by restoring the logical output. ==}
About the SIGA-REL module
The SIGA-REL module is used to actuate the release of fire extinguishing agents (e.g.,
foam, carbon dioxide, dry chemical, or clean agents). It is also used to actuate the release
of water in sprinkler systems.

The SIGA-REL module provides the following:

One abort switch input
One manual release switch input
Two prerelease circuits
Two release circuits
One prerelease relay output
Field-configurable automatic release sequence, manual release sequence, and abort
sequence
Status LEDs to indicate power, local trouble, normal and active communications,
active prerelease circuits, and active release circuits
Notes
The manual release switch circuit and the abort switch circuit are used only in
extinguishing agent release applications.
You cannot disable the prerelease circuits or the release circuits
Addressing
The SIGA-REL uses six addresses; one for each circuit. A serial number is assigned to
each address. The serial number for the first address (the abort switch circuit) is the same
as the serial number on the SIGA-REL module. The serial numbers for the remaining
addresses are calculated.

Address Circuit Terminal

1 Abort switch TB3-3, TB3-4
2 Manual release switch TB3-1, TB3-2
3 Release circuit 1 TB4-1, TB4-2
4 Release circuit 2 TB4-3, TB4-4
5 Prerelease circuit 1 TB5-1, TB5-2
6 Prerelease circuit 2 TB5-3, TB5-4
Automatic release sequence
The automatic release sequence controls the activation of the release circuits when the
SIGA-REL is activated by two events from the automatic fire detection system. The
duration of the automatic release sequence is field-configurable.
How does it work?
Manual release sequence
The manual release sequence controls the activation of the release circuits when the SIGA-
REL is activated by the manual release station. The duration of the manual release
sequence is field-configurable.
How does it work?
Abort sequence
The abort sequence controls the activation of the release circuits when the abort station is
activated. The duration of the abort sequence is field-configurable and is determined by the
abort mode, the abort delay timer, and by how long the abort station is held active.
How does it work?
Note: Activating the abort station does not prevent the manual release station from
activating the release circuits. Manual release overrides an abort.
Adding a SIGA-REL module
This topic provides instructions for adding a SIGA-REL module. We recommend adding the
SIGA-REL module to the SDU first, then configuring the SIGA-REL module, then uploading
the loop map, and then matching the SIGA-REL module in the map to the SIGA-REL
module in the SDU.
Adding the SIGA-REL module to the SDU
Configuring the SIGA-REL module
Uploading the loop map
Matching the SIGA-REL modules
Changing the SIGA-REL module device addresses (if required)
Extinguishing agent release system
This topic describes how to program a SIGA-REL module and other equipment to activate
an extinguishing agent release system. Before you begin, you should have a good
understanding of the following:
AND groups
The Activate command
SIGA-REL operation
Priorities
This topic presents one method for programming this application. It is not the only method.
It is your responsibility to make adjustments as needed to suit your particular project and to
thoroughly test the application before putting it to use at the site.
WARNING: Attempting to program the SIGA-REL without a complete understanding of its
operation, and the health risks of the fire extinguishing agent used, can lead to property
damage, accidental exposure, and serious injury, including death. Consult all applicable
NFPA documentation and the local authority having jurisdiction (AHJ) for more information.
Automatic release
Typically, the first automatic fire detector in the suppression zone to go into alarm activates
the SIGA-REL module's prerelease circuits and the second automatic fire detector in the
suppression zone to go into alarm activates the SIGA-REL module's release circuits. Some
applications may require more than two automatic fire detectors to activate releasing
circuits.
Using two automatic detectors to initiate an alarm response
This application uses two AND groups to automatically activate the releasing circuits.
Configure the first AND group with an activation count of 1 and label it AND_Group1_-
_REL01_PRERELEASE. Configure the second AND group with an activation count of 2 and
label it AND_Group2_-_REL01_RELEASE. Do not assign members to the AND groups.
Instead, use the Activate command to increment the AND group activation counters.
Manual release
Some applications may require the ability to manually activate the releasing circuits. The
SIGA-REL manual release sequence is automatic. Programming is not required for the
manual release station to activate the release circuits. However, for the control to restore
points in the proper sequence you must include a rule that activates a manual release.
Programming
For this application, you need to include rules for programming an automatic release, a
manual release, status indicators, and for resetting the SIGA-REL.
Rules for programming an automatic release
Rules for programming a manual release
Rules for programming status indicators
Rules for resetting the SIGA-REL module
Double interlock electric release preaction sprinkler system
This topic describes how to program a SIGA-REL module and other equipment to activate a
double interlock electric release preaction sprinkler system. Before you begin, you should
have a good understanding of the following:
AND groups
The Activate command
SIGA-REL operation
Priorities
This topic presents one method for programming this application. It is not the only method.
It is your responsibility to make adjustments as needed to suit your particular project and to
thoroughly test the application before putting it to use at the site.
WARNING: Attempting to program this application without a complete understanding of the
SIGA-REL and its operation, and the health risks of the fire extinguishing agent, can lead to
property damage, accidental exposure, and serious injury, including death. Consult all
applicable NFPA documentation and the local authority having jurisdiction (AHJ) for more
information.
Automatic release
A double interlock electric release preaction sprinkler system requires an alarm event from
the automatic fire detection system and a supervisory event from the deluge valve low
pressure switch to actuate the release of water. Either of the two events activate the SIGA-
REL module's prerelease circuits, but it takes both of these events to activate the SIGA-
REL module's release circuits.
This application uses three AND groups to automatically activate the releasing circuits.
Configure the first AND group with an activation count of 1 and label it AND_Group1_-
_REL01_PRERELEASE. Configure the second AND group with an activation count of 1 and
label it AND_Group2_-_REL01_RELEASE_A. Configure the third AND group with an
activation count of 2 and label it AND_Group3_-_REL01_RELEASE_B.
Do not assign members to the AND groups. Instead, use the Activate command to
increment the AND group activation counters.
Programming
For this application, you need to include rules for programming an automatic release, status
indicators, and for resetting the SIGA-REL,
Rules for programming an automatic release
Rules for programming status indicators
Rules for resetting the SIGA-REL module
Running diagnostics on a PS10-4B power supply
On a CAB6, you can monitor the power supply and collect metrics that you can then use to
diagnose battery issues.
You can run diagnostics on a PS10-4B power supply to monitor the current drawn on the
NAC/AUX outputs, line voltage fluctuations, and the amount of charge currently being drawn
from the battery.
To run diagnostics on a PS10-4B power supply:
1. Click Tools > Power Supply > Diagnostics. The Power Supply Diagnostics form
opens to the NAC/AUX Current tab.
2. In Connection Type, select RS-232 or TCP/IP. Note: TCP/IP is only available if you
have an Ethernet option card installed, and if you set the C-CPU Ethernet Card
option on the on the Configure > Cabinet >IP Configuration tab to a value other than
"Not Installed."
3. Select the Download Mode:
Use the single-step mode when you want to run power supply diagnostics on the
panel to which you are directly connected.
Use network mode when you want to run power supply diagnostics on other
panels over the network.
4. If you are using a serial connection, complete the following fields:
Communications Port: Select the COM port you are using for communications.
Baud Rate: Select the Baud rate you are using for communications.
Or, if you are using an IP connection, complete the following fields:
IP Address: Enter the IP address of the panel.
Port Address: Enter the IP port number used to communicate with the panel.
The default port number is 2501.
5. In Cabinet, select the cabinet where the PS10-4B is installed.
6. Set the Delay option for how often you want the system to refresh the data (on all
tabs).
7. Click Connect.
8. To view the real-time current draw values for each NAC/AUX, click the NAC/AUX
Current tab. The system displays the following information for each NAC.
Note: For the following fields, the system uses 24 hours of data only if the system has
been active for that amount of time. If, for example, the system was turned off for 14
hours, these numbers would instead represent 10 hours instead of 24 hours of data.
Actual: Shows the real-time current draw, as of the last update. The frequency of
 updates is based on the Delay setting.
Min: Shows the lowest recorded current draw over the past 24 hours.
Max: Shows the highest recorded current draw over the past 24 hours.
24 Hr Avg: Shows the average current draw over the past 24 hours.
1 Hr Avg: Shows the average current draw over the past hour. Note: The system
averages over the past 60 minutes only if the system has been active for that
amount of time. If, for example, the system was turned off for 20 minutes, this
number would instead represent an average over 40 minutes instead of an hour.
Total Current: Shows the total current draw for all NACs over the past 24 hours.
Max Current in Alarm: Shows the highest recorded current draw while the
system was in alarm for all NACs over the past 24 hours.
9. To monitor the current AC voltage of the power supply, click the Input AC Voltage
tab. This tab shows the fluctuation of the input AC voltage.
Voltage: Shows a plot of the input AC voltage over time.
Time: Shows a plot of the time against which the system reports the AC voltage
usage. This time period is a maximum of 24 hours.
10. To monitor the current battery charge information, click on the Battery tab.
The upper graph shows the amount of charge currently being drawn from the
battery.
The lower graph shows the current charger voltage.
11. Click Close.
Signature Diagnostics - Current Status tab
Use the Current Status tab to monitor the Signature loop controller's activity in real time.
Note than an active status point does not necessarily indicate a problem; some status
points turn on and off during normal operation.
Loop status indicators
The Current Status tab gives status information about the signaling line circuit (loop).
Map Disabled
Mapping Pending
Mapping in Progress
Map Fault
Balanced Map
New Device Starts in Progress
Smoke Power Fault
Line Fault
Line Initialization
Device Reset
Unprogrammed Trouble
Unprogrammed Alarm
Dirty Device
Device Ground Fault
Data Card Startup Fault
Device Supervision
Sensor Initialization
Data Ground Fault
Data Card Comm. Fault
Data Card Internal Fault
Map Mismatch
Too Many Devices
Device Reset Active
Address 0 Found
General status indicators
The Current Status tab also provides general status information about the controller.
Internal Fault
Annunciator Fault
RAM Fault
Stack Fault
Code Checksum Trouble
Data Checksum Trouble
Bootloader Mode
Stand Alone
Stand Alone Alarm
File CRC Fault
Connect button
See also
Configuring a Signature loop controller module
FAQs
Here is a list of frequently asked questions compiled by our training and technical support
staff to date.
What are objects?
What is a device type?
Is the order that rules appear in the rules file important?
What happens when the input restores in the middle of a rule?
Why do I get a "Record already locked by this session" error message?
When must I compile and download the CPU database?
I can't download my 3-ASU database. Why?
What is network routing and how does it work?
What is a device type?
A device type is the classification given to an object in the project database that defines the
operating characteristics of the device the object represents.
Use device types in rules mainly to:
Shorten the compile process by limiting the number of objects the compiler has to
check
Make rules simpler. For example, when you want to write a rule for when any
manual pull station is activated, you only have to include the PULL device type in the
rule instead of having to specify the devices by their object labels.
Is the order that rules appear in the rules file important?
Yes. When you have more than one rule with the same input activating separate output
responses, the compiler groups them as though they were a single rule containing multiple
output statements.
Further, the compiler groups the output responses in the order that the rules appear in the
rules file. However, the compiler may re-order the individual output statements in each rule
in order to optimize speed and space requirements.
For example, say you have a rules file with the following three rules:
[Rule 1]
ALARM SMOKE 'LVL5_SMK1' :
DELAY 30,
FANON 'STAIRWELL_PRESSURE_2';
[Rule 2]
ALARM SMOKE 'LVL5_SMK1' :
FAST 'CAB1_PNL1_LED1';
[Rule 3]
ALARM SMOKE 'LVL5_SMK1' :
ON AUDIBLE 'LVL5_HORN',
FANOFF 'SUPPLY_FAN';
After compiling, the rules may be rearranged as though they were written as:
[Compiled Rule]
ALARM SMOKE 'LVL5_SMK1' :
DELAY 30,
FANON 'STAIRWELL_PRESSURE_2',
FAST 'CAB1_PNL1_LED1',
FANOFF 'SUPPLY_FAN',
ON AUDIBLE 'LVL5_HORN';
In the compiled version of the rules file Rule 2 follows Rule 1 and Rule 3 follows Rule 2.
Notice that placing Rule 1 before Rule 3 results in a 30–second delay before sounding the
horn. Also notice that the compiler placed the second output statement of Rule 3 before its
first output statement.
Tips
By writing rules with multiple output statements to begin with, situations such as this
are more easily recognizable and can be avoided.
You can force one output statement to follow another by placing a delay command
between them, even if it is a delay of 0.
What happens when the input restores in the middle of a
rule?
What happens when an input restores in the middle of a rule depends on whether the rule
has any delays in it. If the input restores, at the next delay the rule will begin restoring
without continuing to the next line in the rule. Otherwise the panel will activate each line in
the rule until it reaches the end and then restore each line in reverse order.
For example, say you have the following rule:
[Rule 1]
ALARM SMOKE 'LVL5_SMK1':
ON AUDIBLE 'LVL5_HORN',
ON VIS 'LVL5_STROBE',
FANOFF 'SUPPLY_FAN',
DELAY 60,
FANON 'PRESSURE_FAN_1',
FANON 'PRESSURE_FAN_2';
If the smoke detector goes into alarm and then should restore during the 60–second delay,
the panel will turn the supply fan on, then turn off the strobe, and then turn off the horn. The
pressure fans will never turn on.
Why do I get a "Record already locked by this session"
error message?
You get this error message when you have two windows open that are trying to change the
same information in the underlying database table. This generally happens with the Object
Configuration, Cabinet Configuration, and Mapping dialog boxes.
To avoid getting this error message, don't have more than one window open at the same
time.
When must I compile and download the CPU database?
You must compile and download the CPU database the first time you bring up a panel and
any time afterwards when you:
Make a change that affects the content of the object configuration table in the SDU
(such as adding or removing a device, change a device's property settings, etc.)
Make a change to the rules file
For example, say you have a Signature module defined as an alarm input and you change it
later to a supervisory input. You then compile the loop controller's database and download it
into the Signature controller module without doing the same for the CPU database.
When that input is activated, the loop controller signals a supervisory condition causing the
CPU to place the device location message into the supervisory queue on the LCD and
activate the common supervisory outputs. The database in the CPU module still lists the
device as an alarm input so the CPU activates any alarm responses associated with the
device.
See also
Downloading files
Downloading to a single rail module
Downloading files across the network
I can't download my 3-ASU database. Why?
You probably have a blank 3-ASUMX Memory Expansion card installed on the 3-ASU
controller board. If this is the case, disconnect the two gray ribbon cables from the rail
chassis interface card and try downloading the database again.
Another reason may be that the 3-ASUMX Memory Expansion card is write protected. To
check this you'll have to remove the 3-ASU cover assembly to get to the 3-ASUMX. To
disable the write protection use a small, nonmetallic, pointed object to slide the write
protect switch to the right. The write protect switch is located on the top left edge of the 3-
ASUMX when it is installed in the 3-ASU.
What is network routing and how does it work?
Network routing lets you direct state changes, common switch commands, and partition
event messages between control panels.
Network routes
A network route is a group of control panels defined as the destination for panel state
changes, system commands, or partition event messages. You can define up to 255
network routes per project. A network route can include every panel in the network, no
panels, or any combination in between. A panel can belong to more than one network route.
Panel state changes
A cabinet's State network route determines the cabinets whose state changes will cause it
to change state. When a panel changes state, its state change message is broadcast over
the network. Each remote cabinet on the network checks the State boxes of its Network
Routing settings. If the network route specified for State includes the panel whose state has
changed, then the remote panel will change its state accordingly.
If you want Panel B to go in to alarm when Panel A goes into alarm, then panel B's State
network route must include Panel A.
System commands
The following network routes are tied to a panel's common control switches: Reset, Alarm
Silence, Pane/Trouble Silence, Drill, and Alternate Sensitivity. When an operator presses a
system command button on a panel's LCD module, the command is sent to other panels
according to the network routing group specified for that command.
If you want to reset Panel B when you press the Reset button on Panel A, then Panel A's
Reset network routing group must include Panel B.
A panel's Display & Printer Partition Filtering network route specifies the group of partitions
whose event messages it will display or print.
Location Messages
3-CPU1 Versions earlier than 3.6
In earlier versions of the 3-CPU1 central processing unit, each database object is assigned
a location message, and a primary and alternate network routing group. When a device
goes active, its location message is distributed to the panels in the primary or alternate
network route, according to the message routing setting that is currently in effect.
Use the primary routing boxes to specify where you want to send location messages when
the protected site is occupied. Use the alternate routing boxes to specify where you want to
send location messages when the protected site is not occupied.
If you want the location message for a device on Panel A to go to Panel B, then the
device's network routing group must include Panel B and Panel B's State network route
must include Panel A.

3-CPU1 Version 3.6 and later

Starting with version 3.6, you can also route object location messages to individual Keypad
Displays and printers. Each database object is assigned a location message, and a primary
and alternate Message Annunciation route. When a device goes active, its location
message is distributed to the panels, Keypad Displays, and printers in the primary or
alternate message annunciation route, according to the message routing settings that is
currently in effect.
Use the primary routing boxes to specify where you want to send location messages when
the protected site is occupied. Use the alternate routing boxes to specify where you want to
send location messages when the protected site is not occupied.
Customize SDU Environment - Behavior tab
Use the Behavior tab to set your preferences on a system-wide basis.
Auto Open last project
Ignore Rules Compile warnings
Ignore Signature Conversion warnings
Loop selection stays resident:
Overwrite warnings on Export
Prompt on Audio Message Deletion
Clear communications actions
Ignore Correlation Warnings After 30 seconds
Microcode Version Updates
Determines how you want to update the active project, when newer versions of the
microcode are available in the SDU.
Update manually
Warn when not the latest
Automatically update to the latest
After Microcode Version Updates
Determines when the system displays Change Report options.
Do not display Change Report
Prompt user for Change Report
Display Change Report
Object Configuration Options
Use Object Config LRM Tree View
User Changed Pseudo Point Color
Reset default window sizes and positions
Post Rules Compile Action
Determine how the SDU acts after compiling your rules file.
Do nothing
Auto convert all 3-CPU databases
Auto convert all Databases
See also
Customizing SDU operation
Customize SDU Environment - Configuration tab
Use the Configuration tab to change the way that SDU performs configuration functions.
Fill all cabinet rails
Default Cabinet Type
Configure LRM on addition to cabinet
Communications
Upload Signature Loop before mapping
Self Start Uploads/Downloads
Default COM port
Default Baud Rate
Auto Continue with next module
Default LRM Labels
The Default LRM Labels section allows you to control the default labels for LRMs.
Old Style for automatically added LRMs
Old Style for all LRMs
New <LRM Type>_Cab#_Slot#
Rules Editor
Use Default Editor
Parameters
See also
Customizing SDU operation
Customize SDU Environment - Fonts & Languages tab
Use the Fonts & Languages tab to change the font the SDU uses to display the primary or
secondary language.
Language
Font Name
Font Size
Change Font button
See also
Customizing SDU operation
Alarm Silence functional description
The Alarm Silence function temporarily turns off active NACs (Notification Appliance
Circuits) when an operator presses the Alarm Silence switch. Which NACs are turned off
depends on how the system is programmed.
By default, the system turns off NACs assigned the Audible device type and
CommonAlarmOutput device type Project parameter settings determine whether NACs
assigned the Visible device type are turned off.
The LED on the LCD module automatically flashes when the Alarm Silence function is active
and the panel is in alarm.
In networked systems, the Alarm Silence function silences active alarm notification
appliance circuits on the local panel and on any panel in the network route with which the
local panel shares the AlarmSilence command.
Drill functional description
The purpose of the Drill function is to turn on a panel's alarm notification appliance circuits.
Note: The Drill function does not put the panel into alarm.
When an operator presses a toggle switch programmed to execute the Drill command, the
panel activates the Drill event which in turn activates all circuits with the Audible or Visible
device types, depending on the project configuration. In addition the panel activates any
rules written against the Drill event and lights the Drill LED on the LCD module.
Pressing the Drill switch a second time restores the Drill function and turns the alarm
notification appliance circuits back off.
In networked systems, the Drill function turns on alarm notification appliance circuits on the
local panel and on any panel in the network route with which the local panel shares the Drill
command.
Project Parameters - Time Synchronization tab
Use the Time Synchronization tab to specify how the system synchronizes its time settings
for the project.
System Time Source
Check time after each network communications
Time Zone
Ignore time differences less than
See also
Configuring time synchronization
Cabinet Configuration - Cabinet tab
Use the Cabinet tab to add cabinets to the project and to specify which chassis types are in
a cabinet.
Cabinet Label
Cabinet Type
Rail 1 Type
Rail 2 Type
Rail 3 Type
See also
Adding cabinets to the database
Tips for configuring cabinets
Ethernet terminology
Ethernet follows a simple set of rules that govern its basic operation. To better understand
these rules, it is important to understand the basics of Ethernet terminology.
DHCP: Dynamic Host Control Protocol.
DHCP Server: Automatically assigns IP addresses to hosts on network. Has an
expiration time (lease) of usually 10-30 days, then the DHCP Server revokes the
address until you reboot at which time it assigns another address to that host.
DNIS: Dialed Number Identification Service. Provides a call source identification
number to the central monitoring station.
DNS: Domain Name System.
DNS Server: Translates domain names into IP addresses. DNS servers MUST have
static IP addresses.
Domain: Managed groups. Secure. Larger business networks operate with
domains.
Dynamic IP Address: An address assigned by a DHCP server (See DHCP).
ECP: Short for External Command Protocol. This protocol is used for Point-to-Point
(PPP) communication between an FACP and external equipment such as a
FireWorks workstation.
Hub: A multi-port device used to connect PCs to a network. Each networked PC
using Ethernet or Fast Ethernet is cabled to a hub, which can have multiple ports
and can transmit data at up to 1000mbps or dual speed. A hub transmits packets it
receives to all ports. Hubs can be cabled together for network expansion. A hub's
primary advantage is that its LEDs signal problems with any networked PC, while a
network's operation is not impacted by problems on any one PC.
LAN: Local Area Network. A computer network that spans a relatively small area.
Most LANs are confined to a single building or group of buildings.
Medium: Ethernet devices attach to a common medium that provides a path along
which the electronic signals will travel. Historically, this medium has been coaxial
copper cable, but today it is more commonly a twisted pair or fiber optic cabling.
Megabits per second (Mbps): A measure of data transmission speed over
communication lines, in one million bits per second.
Node: Devices that attach to that segment are stations or nodes (aka Hosts).
Octet: Is comprised of eight bits. Octet is sometimes used instead of the term byte
to avoid confusion, because not all computer systems use bytes that are eight bits
long.
Protocol: Refers to a set of rules that govern communications. Protocols are to
computers what language is to humans. Since the class material is in English, to
understand it you must be able to read English. Similarly, for two devices on a
network to successfully communicate, they must both understand the same
protocols.
Router: A device that forwards data packets along networks. A router is connected
to at least two networks, commonly two LANs or WANs or a LAN and its ISP's
network. Routers direct network traffic and are typically located at gateways, the
places where two or more networks connect. Routers can link networks using
different protocols and can link local and remote networks.
Segment: A single shared medium is an Ethernet segment.
SMTP: Simple Mail Transfer Protocol. The Internet standard for email transmission.
Static IP Address: An address permanently assigned that will never expire. Some
systems need static IP addresses so: 1) the address never expires; 2) you always
know where to find the hosts or servers.
Switch: A special type of hub that efficiently controls the way multiple devices use
the same bandwidth so that each can operate at full bandwidth resulting in faster
performance than with a hub. Rather than transmitting packets it receives to all ports
as with a hub, a switch transmits packets to only the receiving port.
TCP/IP: Transmission Control Protocol/Internet Protocol. The standard Internet
communication protocol.
WAN: Wide Area Networks. A computer network that spans a relatively large
geographical area. Typically, a WAN consists of two or more LANs.
Workgroups Peer To Peer Networks: A workgroup is a collection of computers
that are logically grouped together for a common purpose. Home networks and
other small LANs use workgroups. All hosts belong to the same workgroup. Little or
no security.
See also
Basic network addressing
Subnet masks
Networking protocols
Basic network addressing
The IP addressing scheme supports up to 5 different classes: A, B, C, D, and E. Whether
you’re building a stand-alone network or tying into existing infrastructure determines which
class of network to use.

The MSB (Most Significant Bit, left-most bit) of an address indicates the class of the
network.

The IP addressing scheme is made up of “Network” and “Host” numbers.

See Also
Subnet masks
Networking protocols
Ethernet terminology
Subnet masks
A subnet mask is a hexadecimal number used to determine to which TCP/IP subnet a
device belongs (1=Network, 0=host).
When a TCP/IP device tries to communicate with another device the bits of the destination
address are "ANDed" to the internal network’s subnet mask.
In the following example, the first three octets are 1’s and therefore dictate the octets used
for the AND operation. The resulting address is compared to a list and routing decisions are
made. If the address is a local address, the data stays on the local network (and can be
broadcast); if the addresses are different, the data must be forwarded outside the local
network.

All PCs belonging to the same workgroup should have an identical subnet mask.
See Also
Basic network addressing
Networking protocols
Ethernet terminology
Cabinet Configuration - Ports tab
Use the Ports tab to configure the panel's serial ports. You must have installed an RS-232
option card in the CPU module for the serial port to operate.
Port Type
Baud Rate
Message Annunciation Group
Port Enabled settings
Determines which event messages routed to the panel are sent out the serial port to
external equipment. The device or circuit that signaled the event must belong to a panel in
the network routing group with which the cabinet shares state information.
The system classifies event messages into the following types; this varies depending on
your marketplace setting.
Alarm
Supervisory
Trouble
Monitor (All Others)
Service Group
Service Device
Commands
Partition Events
Guard Station Events
Acknowledgements
Restorations
Gateway/RDU Settings
The Gateway/RDU options appear when you set the Port Type option to Gateway or
Remote Diagnostics. For these options the system sends all event message types through
the port.
Primary
Alternate
Port connection is a Control Center
Card Access Events
Command Logging
Cabinet Configuration - Options tab
Use the Options tab to set the general options for a cabinet, including: Display Enabled,
Battery Type, Supervise Class A Audio, Rail Band Rate, LCD Configuration, Log to History,
and AC Power Monitored By options.
Note: Some of these options may not apply to the marketplace you are using; if so the
system does not show the corresponding fields on the Options tab. Thus, there may be
some fields described here that you cannot see or use.
Display Enabled
The Display Enabled options let you specify which events routed to the panel you want the
system to queue on the LCD. The device or circuit that signaled the event must belong to a
panel in the network route with which the cabinet shares state information.
Alarm
Fire
Supervisory
Fault
Trouble
Test and Disable
Monitor (All Others)
Service Group
Service Device
Battery Type
The Battery Type options let you configure the battery charging circuit, based on the
ampere-hour rating of the standby batteries installed in the control panel. For more
information, see Configuring the battery charging circuit.
<30 Amp Hours
>30 Amp Hours
Supervise Class A Audio
Check the Supervise Class A Audio check box if you want to supervise Class A audio wiring
in this cabinet. Note: For details on setting up Class A audio supervision for all panels in a
project, see = 4 && typeof(BSPSPopupOnMouseOver) == 'function')
BSPSPopupOnMouseOver(event);" class="BSSCPopup"
onclick="BSSCPopup('../Project_configuration/Configuring_Class_A_audio_supervision.htm');r
false;">Configuring Class A audio supervision.
Rail Baud Rate
The Rail Baud Rate options enable you to configure the speed at which the local rail
modules communicate with the CPU card.
Baud Rate
All LRM firmware is V3.0 or later
Update Baud Rate/Firmware in all cabinets in project
3-LCD Configuration
The 3-LCD Configuration options let you configure the LCD.
Enable Security Control Functions
Use as a Control Center
Access Level Override
Use as a Master Panel
Message Annunciation Group
Log to History
The Log to History options let you specify which events the system records in this cabinet's
history file. For example, you can choose to record all events or only alarm events. Note:
Not available in all marketplaces.
Alarm
Supervisory
Trouble
Monitor
Service Group
Service Device
Commands
Partition Events
Guard Station Events
Acknowledgements
Restorations
AC Power Monitored By
Select the point that indicates when the control panel or remote booster supply used to
power the remote annunciator loses primary power. Note: Not available in all marketplaces
or on control panel cabinets.
Control-display Module Configuration
Use the Control-display Module Configuration dialog box to set up a control-display module.
Switch Label
Switch Type
LED Label
See also
Configuring control-display modules
3-IDC8/4 jumper settings
Jumper selections on the 3-IDC8/4 module determine whether the 3-IDC8/4 supplies 24
Vdc to the output circuit or 24 Vdc is supplied from an external 24V source.
Note: Configuration jumper settings have no effect when IDC/NAC circuits are used as input
circuits.
JP1–1 to JP1–2 and JP2–1 to JP2–2:
Output circuits 1 and 2 get 24 volts from external source by way of NAC IN 1/2 terminal
connections
JP1–2 to JP1–3 and JP2–2 to JP2–3:
Output circuits 1 and 2 get 24 volts from 3-IDC8/4 module
JP3–1 to JP3–2 and JP4–1 to JP4–2:
Output circuits 5 and 6 get 24 volts from external source by way of NAC IN 5/6 terminal
connections
JP3–2 to JP3–3 and JP4–2 to JP4–3:
Output circuits 5 and 6 get 24 volts from 3-IDC8/4 module
3-IDC8/4 Configuration
Use the 3-IDC8/4 Configuration dialog box to connect the eight dedicated Class B circuits to
traditional (nonaddressable) two-wire and dry contact initiating devices. You can also
connect four of the circuits (1, 2, 5, and 6) to supervised output devices.
Hard Zone Type
Class
Verification retard/reset/restart timing
See also
Configuring a 3-IDC8/4 module
3-ZAxx Amplifier Configuration
These properties determine the operating characteristics of the 3-ZA15, 3-ZA20, 3-ZA30,
3-ZA40, 3-ZA90, and 3-ZA95 amplifier modules.
Amplifier Output
Assigned to ASU in cabinet
Backup Amplifier
See also
Configuring a 3-ZAxx amplifier module
Configure 3-MODCOM - General tab
Use the General tab to configure the Public Service Telephone Network, Line Properties,
Dial In Phone Number, and Counters and Timers for the 3-MODCOM.
Public Service Telephone Network
DACT Settings
Line 1 Installed
Enable Line 1 Supervision
Enable Line 1 Enable Force Dial
Line 2 Installed
Enable Line 2 Supervision
Enable Line 2 Enable Force Dial
Ignore Monitor events when determining system status
Line Properties
Default Dialing Method to Use
Ring Cycle Type to Detect
Dial In Phone Number
Country Code
Area Code
Number
Counters and Timers
Auto-Answer Ring Cycle Count
Wait Time To Detect Dial Tone
Wait Time for Calling Party Disconnect
Wait Time for Line Cut Monitor Sensing
Wait Time Before Force Dialing
See also
Programming a 3-MODCOM
Configure 3-MODCOM - Receivers tab
Each 3-MODCOM can have up to 80 different receivers. The Receivers tab lists the
receivers you've already defined for the project, and lets you create new receivers, or edit
or delete receivers in the list.
Index
Receiver label
Description
Insert
Edit
Delete
See also
Programming a 3-MODCOM
Receiver Properties
Use the Receiver Properties dialog box to configure the properties of a 3-MODCOM
receiver, including its label, phone numbers, receiver protocol, counters and timers, and
default messages.
Receiver
When you insert a new receiver or edit an existing receiver, the system displays the
Receiver Properties dialog box, which contains all the configurable variables for a receiver.
It also lets you enter message text for the receiver's default messages, using the protocol
you have specified for the receiver.
Receiver Label
Description
Phone Number 1
Phone Number 2
Receiver Protocol
Counters and Timers
Max Dial Attempts
Wait Time On-Hook Between Attempts to Same Number
Receiver Default Messages
This area lets you define the default messages the 3-MODCOM uses.
Set Messages to Default Values button
Comm Fail With 3-CPU
Comm Fail Restore
General Fire Backup
General Fire Backup Restore
Normal Dialer Test
Abnormal Dialer Test
See also
Programming a 3-MODCOM
Configure 3-MODCOM - Accounts tab
Each 3-MODCOM can have up to 255 accounts. The Accounts tab lists the accounts you've
already defined for the project, and lets you create new accounts, edit, or delete accounts
in the list. On this tab, the system displays summary information about the accounts in a
table.
Index
Account label
Description
Insert
Edit
Delete
See also
Programming a 3-MODCOM
Account Properties
Use the Account Properties dialog box to specify information regarding the account in the
project database and rules.
Account Name
Account label
Description
Receiver Label
Receiver Protocol
CMS Account Number
Auto Generate Events

Dial Test Timers

Enable Dial Test Timers
Dialer Test Interval
Dial Test Time of Day
See also
Programming a 3-MODCOM
3-SAC and SPUR Configuration - CRC Cmd Lists tab
The CRC Cmd Lists tab allows you to activate command lists based on specific card
access events. This lets you develop rules that run each time the event occurs.
Note: Access Granted is a normal card access event; the rest are abnormal events.
Access Granted
Access Granted Irregular
Access Granted Antipassback
Access Granted Muster
Access Denied Unknown
Access Denied Reader Disabled
Access Denied Ranks Not Active
Access Denied Outside Schedule 2
Access Denied Outside Schedule 1
Access Denied Partition Armed
Access Denied PIN Not Entered
Access Denied PIN Not Valid
Access Denied 2 Person Timeout
Access Denied Antipassback
Access Denied Escort
Default SPUR Address
Make Default button
Copy from Default button
Copy Cmd Lists from Default button
See also
Using command lists
Configuring a 3-SAC module
3-SAC and SPUR Configuration - CRC Config tab
Use the CRC Config tab to configure the 3-SAC CRC.
Address
Label Text
Serial No.
Lock Type
Reader Partition
Presence tracking/Muster Support
Muster Station
Anti Passback
2 Person Rule
Relay Device Type
See also
Configuring a 3-SAC module
3-SAC and SPUR Configuration - CRC Input Circuits tab
Use the CRC Input Circuits tab to set up the characteristics of the input circuit.
Label Text
Device Type
Input Circuit Partition
Max Delta Count
Delays
Application
Personality
Delayed Egress Time
See also
Configuring a 3-SAC module
3-SAC and SPUR Configuration - KPDISP Config tab
Use the KPDISP Config tab to configure the 3-SAC and SPUR behavior.
Address
Label Text
Serial No.
Partition
Login Retries
User Timeout
User Lockout
Label 1
Label 2
Buzzer Resound Time
KPDISP Buzzer Tones button
See also
Configuring a 3-SAC module
3-SAC and SPUR Configuration - KPDISP Filtering tab
Use the KPDISP Filtering tab to configure the 3-SAC and SPUR behavior.
Message types to display
Partitions
Reset
Panel Silence
Alarm Silence
Bell Test Instruction
Partition Routing button
Cabinet Routing button
See also
Configuring a 3-SAC module
Signature Series Configuration - Detectors tab
Use the Detectors tab to program the detectors for the loop specified.
Address
Serial Number
Label Text
Device Type
Model
CO Setting
Base Type
Sensitivity
Alt Sensitivity
Alarm Verify
Alt Alarm Verify
Pre Alarm
Alt Pre Alarm
Supervisory Duct Detector
Group Name
Follow Local Alarm
Follow Alarm Verification
Follow Local Pre-alarm
Device Alarm Overrides Silence
SA Alarm Verification
SA Local Alarm
SA Local Pre-alarm
Personality Code
Operation
Alternate Operation
Short Address
Assign Groups button
Add Detectors button
Delete Detector button
Delete All Detectors
See also
Configuring a Signature loop controller module
Configuring a SIGA2-PHS device
Configuring CO devices
Configuring detectors on a nonmapping loop
Understanding DS and DH detectors
Signature Series Configuration - Modules tab
Use the Modules tab to program the modules for the loop specified.
Address
Serial Number
Label Text
Device Type
Model
Personality Code
Alarm Verify
Alt Alarm Verify
Standalone Alarm
Timer
Delay
Max Delta Count
Short Address
Short Address Group
Add Modules button
Delete Modules button
Delete All Modules
See also
Configuring a Signature loop controller module
Signature Group Assignment
Use the Signature Group Assignment dialog box to create, edit, or delete user-defined
Signature groups (for relay/sounder bases only). You can also use this dialog box to add or
remove devices from a predefined or user-defined group.
Note: If you assign a relay/sounder to a group, be aware that sounder bases do not
activate as a group when in stand-alone mode.
Assignment Group
Device Pool
Move buttons
New button
Edit button
Delete button
Close button
See also
Programming Signature detector bases
Accompany Data
Use the Accompany Data dialog box to select the lines of data that the system shows for
each device in the Actual Data Wiring Diagram, and in what order the data appears. You
can choose to display up to six lines of data under the device icon, display the serial number
in four to ten digits, and change the wiring diagram position in the mapping window. You can
save the current settings as the new default settings.

To open the Accompany Data dialog box:

1. On the Mapping toolbar, click the Change Associated Display Data button.
2. You can change the following data: (The "Space Indent" option will be available in a
future release.)
Line x
Serial number width
Justification
Default
Save Settings
Change
Clear
Cancel
See also
Matching actual data with expected data
Using the mapping interface
Configuring detectors on a nonmapping loop
To configure nonmapping detectors (such as the DS or DH) in the China or International
marketplaces, first add the detectors and then reconcile the loop that contains them.
When you reconcile the loop, the procedure varies according to the method you want to use
to add the devices to the database; either by scanning the devices' bar codes and letting
the SDU assign the addresses, or by manually assigning addresses using the SIGA-PRO
service tool and then uploading that data from the loop controller into the SDU project
database.
For the smoothest installation regardless of the method you use, we recommend that you
program the device addresses on the devices before installing them. This can later reduce
the need to resolve conflicts due to duplicate device addresses on the loop, and thus could
save you time by eliminating the steps needed to reconcile devices.
Notes
For DS or DH devices you must use a 3-SSDC1(C) or 3-SDDC1(C) loop controller
running application code version 04.00.00 and bootloader code version 04.00.67 or
later, in an EST3 cabinet.
When configuring a DS or DH detector, you must select a valid marketplace on the
Project Parameters – Operations tab before the SDU lists them on the Add
Detectors to Loop dialog box. For more details, see Understanding DS and DH
detectors.
You cannot mix mapping and nonmapping devices (DH or DS) on a mapped loop.
When you add a nonmapping device, the SDU classifies the entire loop as
nonmapped. If you eliminate the nonmapping devices, the SDU reclassifies the loop
as mapped.

To configure a nonmapping detector:

1. Click Configure > Cabinet.
The Cabinet Configuration dialog box opens.
2. Select the appropriate cabinet, and then click the Modules tab.
3. Select the 3-SxDC1(C) loop controller where the nonmapping device resides, and
then click the LRM Config button.
The Signature Series Configuration dialog box opens.
4. Click the Loop Detectors tab, and then click the Add Detectors button.
5. In the Model column, select the nonmapping model from the drop-down list. The
SDU fills in the corresponding Detector Type, Base, and default Personality Code
values. Change the base or personality code as necessary, and then click OK.
6. On the Loop Detectors tab, scroll to the right and change the default detector
settings as needed.
Note: When you select a DS or DH detector, the SDU removes the Enable Mapping
check box from the Signature Series Configuration – Signature Series Parameters tab
and replaces it with the Inhibit Normal Flash check box. If you later remove all of the DS
or DH detectors from the loop, the SDU displays the Enable Mapping check box again
and removes the Inhibit Normal Flash check box.
7. Click Close in the Signature Series Configuration window.
8. Reconcile the loop, according to the method you want to use to add the devices to
the database. See either = 4 && typeof(BSPSPopupOnMouseOver) == 'function')
BSPSPopupOnMouseOver(event);" class="BSSCPopup"
onclick="BSSCPopup('To_reconcile_the_loop_using_the_scanning_method.htm');retur
false;">To reconcile the loop using the scanning method or = 4 &&
typeof(BSPSPopupOnMouseOver) == 'function') BSPSPopupOnMouseOver(event);"
class="BSSCPopup"
onclick="BSSCPopup('To_reconcile_the_loop_using_the_manual_address_assignmen
false;">To reconcile the loop using the manual address assignment method.
See Also
Understanding DS and DH detectors
Devices incompatible with 3-AADC
The following devices are compatible with model 3-AADC1 of the analog addressable loop
controller but are incompatible with model 3-AADC:

Model Model Description Product Market(s)

1251E Ionization Smoke Sensor Europe
1251EM Ionization Smoke Sensor Europe
1551E Ionization Smoke Sensor Europe
2251EM Photoelectric Smoke Sensor Europe
2251TEM Optical/Thermal Multi Sensor Europe
2551EM Photoelectric Smoke Sensor Europe
5251EM Fixed Thermal Sensor Europe
5251HTEM High Temperature Fixed Europe
Thermal Sensor
5251REM ROR Thermal Sensor Europe
5551E Fixed Thermal Sensor Europe
5551HTE High Temperature ROR Europe
Thermal Sensor
5551RE ROR Thermal Sensor Europe
FTX-P1 Filtrex Optical Smoke Sensor Europe
FTX-P1A Filtrex Optical Smoke Sensor Europe
M201E (High Single Output Module (High Europe
Current) Current)
M201E (Standard) Single Output Module Europe
(Standard)
M201E Single Output Module Europe
(Unsupervised) (Unsupervised)
M201E-240 Relay Module Europe
M210E Single Input Module Europe
M220E Dual Input Module Europe
M221E Dual Input / Single Output Europe
Module
M500CHE Control Module Europe
M500KAC Manual Call Point Europe
M500ME Monitor Module Europe
M501ME Mini-Monitor Module Europe
M503ME Micro Monitor Module Europe
RZB series modules Remote Zone Interface Module All
UIO-12 Universal Input/Output Module All
TC809E1050 Dual Input Module Honeywell Europe
TC809E1068 Dual Input / Single Output Honeywell Europe
Module
TC810E (High Single Output Module (High Honeywell Europe
Current) Current)
TC810E (Standard) Single Output Module Honeywell Europe
(Standard)
TC810E Single Output Module Honeywell Europe
(Unsupervised) (Unsupervised)
TC810E1040 Relay Module Honeywell Europe
TC840M Acclimate Sensor Honeywell All except Europe
TC840ME Optical/Thermal Multi Sensor Honeywell Europe
TC844A Filtrex Optical Smoke Sensor Honeywell All
TC846A Pinnacle Laser Sensor Honeywell All
Device types
The Configuration Utility uses the following device types.
12SW/12LED device type
12SW/24LED device type
2StageSignal device type
24LED device type
24VRiser device type
3-AADC device type
3-AADC1 device type
3-ANNSM device type
3-ASU device type
3-CPU device type
3-CPU1 device type
3-DSDC device type
3-DSDC1 device type
3-EADC device type
3-EASC device type
3-EVDVR device type
3-FTCU device type
3-IDC8/4 device type
3-LCD device type
3-LDSM device type
3-MODCOM device type
3-OPS device type
3-PS/M device type
3-SAC device type
3-SDDC device type
3-SDDC1 device type
3-SSDC device type
3-SSDC1 device type
3SW/3LEDX6 device type
3SW/4LEDx4 device type
AccessDoorControl device type
AccessOutput device type
AccessTrouble device type
ACFail device type
AlarmSilence device type
AllCall device type
AllCallMinus device type
AlternateLanguage device type
AlternateMsg device type
AlternateSensitivity device type
AlternateSensitivityMode device type
Amp device type
AND device type
Audible device type
AudioRiser device type
AuxPowerSupply device type
C-CPU device type
C-LCDXL device type
CardDBIncompat device type
CfgMismatch device type
Channel device type
City_Tie device type
CmdList device type
CMSFirstTrouble device type
CMSNonsupervisedOutput device type
CMSSupervisedOutput device type
COAlarm device type
COMonitor device type
COSupervisory device type
CommFailure device type
CommonAlarmOutput device type
CommonMonitorOutput device type
CommonSupervisoryOutput device type
ControlledAuxOutput device type
CRC device type
DamperControl device type
DamperFeedback device type
DoorControl device type
DoorFeedback device type
Drill device type
EMailAccount device type
Ethernet_Card device type
Evacuation device type
ExtDBIncompatibility device type
Failsafe device type
FanControl device type
FanFeedback device type
Firephone device type
FirstAlarm device type
FirstDisable device type
FirstMonitor device type
FirstSupervisory device type
FirstTrouble device type
GAInhibit device type
Gatevalve device type
GenAlarm device type
G_Audible device type
G_Visible device type
G_AudibleVisible device type
G_CommonAlarmOutput device type
G_CommonMonitorOutput device type
G_CommonSupervisoryOutput device type
GenSmoke device type
GroundFault device type
Guard device type
GuardPatrol device type
Heat device type
Interlock device type
InterlockFeedback device type
IPAccount device type
Isolator device type
KPDISP device type
LampTest device type
LED device type
LocalAlarm device type
LocalMonitor device type
LocalRelay device type
LocalTrouble device type
LogicalOutput device type
LoopControllerResetExt device type
Matrix device type
MComAccount device type
MComCompany device type
Monitor device type
MSG device type
NetworkOverflowFault device type
None device type
NonsupervisedOutput device type
NSAudibleOutput device type
NSCommonAlarmOutput device type
NSCommonMonitorOutput device type
NSCommonSupervisoryOutput device type
NSCommonTroubleOutput device type
NSVisibleOutput device type
PanelCommFault device type
Partition device type
PartitionRouting device type
PhoneRiser device type
Power device type
PS/NAC device type
Pull device type
R1 device type
R2 device type
R3 device type
RebootFault device type
Reset device type
Security device type
Security24Hour device type
SecurityDay device type
SecurityIMonitor device type
SecurityInterior device type
SecurityPerimeter device type
SecurityPMonitor device type
ServiceDeviceSupervision device type
ServiceGroup device type
ServiceGroupActive device type
SignalSilenceInhibit device type
Smoke device type
SmokePre device type
SmokeVfy device type
SprinklerSupervisory device type
StageOne device type
StageTwo device type
Startup device type
SupervisedOutput device type
Supervisory device type
Switch device type
SystemMonitor device type
Tamper device type
TaskFailure device type
Temperature device type
Text device type
TimeControl device type
TimedAccessOutput device type
TroubleSilence device type
TwoStageTimerActive device type
TwoStageTimerExpiration device type
UserTrouble device type
Visible device type
Waterflow device type
Zone device type
3-AADC1 device default settings
You specify the device default settings described below on the Card Parameters tab of the
AADC configuration dialog box. SDU automatically enters these settings as you add devices
to the controller database.
Note: Changing the default values does not affect the operating settings for devices already
added to the controller database. To avoid programming errors, make sure the default
settings are correct before adding multiple devices.
Object Label: Specify a label modifier that is common to all devices on the circuit.
Note: Including the # character in the label automatically inserts the device address.
Including the % character in the label automatically inserts the cabinet number.
Sensitivity: Use this boxes to specify one of three sensor sensitivity level settings: Most,
Normal, and Least.
Alternate Sensitivity: Use this box to specify an alternate sensitivity level setting.
Alarm Verification: Use this box to specify one of fifteen sensor alarm delay times from 4
to 56 seconds.
Alternate Alarm Verification: Use this box to specify an alternate sensor alarm delay time.
Pre Alarm: The sensitivity level that the sensor uses to detect a prefire condition during
business hours (when the protected area is occupied). Pre Alarm can be set to one of three
levels but must be set equal to or greater than the Sensitivity setting.
Alt Pre Alarm: The sensitivity level that a smoke detector uses to detect a prefire condition
after business hours (when the protected area is less occupied). Alt Pre Alarm can be set
to one of three levels but must be set equal to or greater than the Alt Sensitivity setting.
Device Type: Use this boxes to specify a particular device type.
Class A check box: Use this box to specify whether the module is wired in a Class A
configuration.
Soft Short check box: Allows the AADC to differentiate between a alarm condition and a
wire-to-wire short. A wire-to-wire short would be indicated as a fault and not a alarm.
AADC Configuration - Card Parameters tab
Use the Card Parameters tab to specify how you want the AADC or AADC1 loop controller
to operate.
Wiring Class
Device Series
Polling LED Action
Supervisory
Device Link Graphics
See also
3-AADC1 device default settings
Configuring a 3-AADC module
Configuring a 3-AADC1 module
Tips for configuring a 3-AADC1 module
About the UIO-12 universal input-output module
This topic provides general information about the UIO-12 universal input-output module. For
instructions on adding and configuring this module, see Adding a UIO-12 to a 3-AADC1 loop
controller.
Monitoring and data conversion
This component lets you connect up to twelve circuits to the 3-AADC1 loop controller. The
UIO-12 converts information received from normally open contacts, nonpowered alarm
initiating device circuits (IDCs), and notification appliance circuits (NACs), to a format that is
compatible with the 3-AADC1 loop controller. This permits the monitoring of twelve IDC or
NAC circuits with minimal hardware.
Circuits provided
The model UIO-12 universal input output module provides twelve (12) supervised circuits.
All circuits are Class B. Each circuit can be configured independently of the others. The
circuits can be configured as any of the following:
Class B IDC
Single channel, Class B (Class B, Style Y) NAC
Form C dry contact relay
Addressing
The UIO-12 requires twelve consecutive addresses, one for each circuit provided.
Compatibility
UIO-12 module version 1.2 or greater
3-AADC1 module application code version 3.6 or greater
Note: The UIO-12 does not support conventional two-wire smoke detectors.
About the RZB series remote zone interface module
RZB series remote zone interface modules let you connect conventional two-wire alarm
initiating devices or notification appliances to a 3-AADC1 loop controller. Four models are
available:

RZB series model numbers

Model Description
RZBV12 Verified smoke circuits, two-channel output
RZBV12-6/3 Verified smoke circuits, three-channel output
RZBN12 Non-verified smoke circuits, two-channel output
RZBN12-6/3 Non-verified smoke circuits, three-channel output
Data conversion
The RZB series remote zone interface converts information received from as many as eight
conventional two-wire IDCs and NACs to a format compatible with the 3-AADC1 loop
controller.
Circuits provided
The RZB series of modules provides eight supervised circuits. All are Class B. Each circuit
can be configured independent of the others. The following circuit types are included:
Eight circuits configurable as IDCs, Class B (Class B, Style B)
Four (4) circuits configurable either as above, or as NACs, Class B. If model
RZB(N/V)12-6 is configured for notification appliance circuits (NACs), two are single
channel, and two are dual channel. If model RZB12-6/3 is configured for NACs, two
are single channel, and two are 1, 2, or 3 channel outputs
Two (2) circuits configurable as nonsupervisory dry contact relay control circuits
Two (2) circuits configurable as riser select relay control circuits
Addressing
The RZB module occupies eight consecutive sensor addresses and eight consecutive
module addresses, one for each circuit provided. Sensor and module addresses must
correspond. For example, if sensor addresses 1 to 8 are assigned, the SDU assigns
module addresses of 101 to 108.
Compatibility
RZB series module version 1.6 or greater
3-AADC1 module application code version 3.6 or greater
Matching hardware settings and device types for the RZB
module
When you configure an RZB(V/N)12-6/3 module in the SDU, the device types you can
assign are determined by the RZB(V/N)12-6/3 module's switch and jumper configuration
settings. Use the tables below to help you select the appropriate device types.
IN1 to IN8
You can configure IN1 to IN8 only as initiating device circuits for connecting smoke
detectors, alarm dry contact devices, or nonalarm dry contact devices. Table 1 below lists
the device types you can select for each type of circuit configuration. Refer to the
RZB(V/N)12-6/3 installation sheet for switch and jumper settings.

Table 1: IN1 to IN8 device types

Configuration Device types
Alarm Input GENALARM
(Smoke) SMOKE
SMOKEVFY
Alarm Input GENALARM
(Dry Contact) HEAT
PULL
WATERFLOW
Nonalarm Input DAMPERFEEDBACK
(Dry Contact) DOORFEEDBACK
FANFEEDBACK
GATEVALVE
GUARD
MONITOR
POWER
SECURITY
SUPERVISORY
TAMPER
TEMPERATURE

Note: Use the SMOKE device type only on RZBN12-6/3 modules and
the SMOKEVFY device type only on RZBV12-6/3 modules.
I/O1 to I/O4
You can configure I/O1 to I/O4 as initiating device circuits for connecting alarm dry contact
devices or nonalarm dry contact devices, or as supervised output circuits for connecting
horns and strobes, speakers, firefighter telephones, and control relays. Table 2 below lists
the device types you can select for each type of circuit configuration. Refer to the
RZB(V/N)12-6/3 installation sheet for switch and jumper settings.

Table 2: I/O1 to I/O4 device types

Configuration Device types
Alarm Input GENALARM
(Dry Contact) HEAT
PULL
WATERFLOW
Nonalarm Input DAMPERFEEDBACK
(Dry Contact) DOORFEEDBACK
FANFEEDBACK
GATEVALVE
GUARD
MONITOR
POWER
SECURITY
SUPERVISORY
TAMPER
TEMPERATURE
Supervised Output AUDIBLE
COMMONALARMOUTPUT
COMMONMONITOROUTPUT
COMMONSUPERVISORYOUTPUT
DAMPERCONTROL
DOORCONTROL
FANCONTROL
FIREPHONE
NONSUPERVISEDOUTPUT
NSCOMMONALARMOUTPUT
NSCOMMONMONITOROUTPUT
NSCOMMONSUPERVISORYOUTPUT
NSCOMMONTROUBLEOUTPUT
SUPERVISEDOUTPUT
VISIBLE
K5 and K6
You can use K5 and K6 as dry contact relay outputs or as unsupervised riser inputs for
three channel audio applications. They are not configured using switches or jumpers. Table
3 lists the device types you can use for each relay.
Note: K5 and the PWR SUPV circuit (TB3-11 and TB3-12) share the same address.
Always configure K5 as a SUPERVISEDOUTPUT device type when the PWR SUPV circuit
is used to monitor an external power supply. K5 is always an unsupervised output
regardless of the device type setting.

Table 3: I/O1 to I/O4 device types

Configuration Device types
Dry contact relay DAMPERCONTROL
DOORCONTROL
FANCONTROL
NONSUPERVISEDOUTPUT
NSCOMMONALARMOUTPUT
NSCOMMONMONITOROUTPUT
NSCOMMONSUPERVISORYOUTPUT
NSCOMMONTROUBLEOUTPUT
SUPERVISEDOUTPUT
Riser selector for NONSUPERVISEDOUTPUT
three-channel audio NSCOMMONALARMOUTPUT
ASU Configuration - Channels tab
Use the Channels tab to specify the channel's function.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
The system assigns the first five channels as on the 3-ASU as Evacuation, Alert, Page,
Auxiliary, and General message channels, respectively (you should never need to change
these channels). Only designate one channel as the Evacuation channel.
Channel Type
See also
Configuring a 3-ASU Audio Source Unit
ASU Configuration - Options tab
Use the Options tab to configure paging settings on the 3-ASU.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
Memory
Remote Microphone
Preannounce Tone
Page Deactivation
Page Cancel
Phone Page Trouble
See also
Configuring a 3-ASU Audio Source Unit
Object Configuration - Object Configuration tab
Use the Object Configuration tab to configure the settings for objects in your project.
Using the Filters
Pick
Cabinet Label
LRM Label
Device Type
Address
Label Text
Abbreviation
Coder
Message
Serial Number
Module
Personality
Sensor
Base
Msg Annunciation Route Label
Alt Msg Annunciation Route Label
Pick All button
Un-Pick All button
Prefab Labels button
Edit Message button
Msg Annunciation Routing button
Msg = Label button
See also
Labeling database objects
Overview of message annunciation routing
Prefabricated Text Editor - Label Text tab
Use the Label Text tab to add, change, or delete labels in the Prefab Label library. You can
then use the Prefab Label library to quickly add or replace labels in rules. Labels in the
Prefab Label library can consist of text, wildcards, or both.
Line 1
Prefab Label
Add button
Change button
Delete button
Replace button
Before button
After button
Blank button
Wild Cards
Increment *
Decrement *
Start * Value
* Width
# Width
% Width
> Width
Use # substitution
See also
Using the Prefabricated Text Editor
Using wildcards in labels, messages, and abbreviations
Prefabricated Text Editor - Message Text tab
Use the Message Text tab to add, change, or delete messages in the Prefab Message
library. You can then use the Prefab Message library to quickly add or replace device
messages. Messages in the Prefab Messages library can consist of text, wildcards, or
both.
Line 1
Line 2
Prefab Line 1
Prefab Line 2
Add button
Change button
Delete button
Wild Cards
Increment *
Decrement *
Start * Value
* Width
# Width
% Width
> Width
Use # substitution
See also
Using the Prefabricated Text Editor
Using wildcards in labels, messages, and abbreviations
Prefabricated Text Editor - Abbreviation Text tab
Use the Abbreviation Text tab to add, change, or delete abbreviations in the Prefab
Abbreviation library. Abbreviations are short forms of the names given to devices, and are
used to identify devices in the command menu on the LCD module where space is limited.
You can use the Prefab Abbreviation library to quickly add or replace device abbreviations.
Abbreviations in the Prefab Abbreviation library can consist of text, wildcards, or both.
Line 1
Prefab Abbreviation
Add button
Change button
Delete button
Wild Cards
Increment
Decrement
Start * Value
* Width
# Width
% Width
> Width
Use # substitution
See also
Using the Prefabricated Text Editor
Using wildcards in labels, messages, and abbreviations
Prefabricated Text Editor - Device Types tab
Use the Device Types tab to change the short form (or abbreviation) for the device type
wildcard (<). For example, the default short form for the 12SW/12LED device type is
12S12L, but you could change this to 12SW/12LED.
Substitution Value
Assign Default Device Type Abbreviations button
User-Defined Device Type Substitution
Add button
Change button
Delete button
Wild Cards
Increment *
Decrement *
Start * Value
* Width
# Width
% Width
> Width
See also
Using the Prefabricated Text Editor
Using wildcards in labels, messages, and abbreviations
Prefabricated Text Editor - Substitution Legend tab
The Substitution Legend tab provides a brief description of each wildcard character, for
easy reference.
See also
Using the Prefabricated Text Editor
Using wildcards in labels, messages, and abbreviations
IP Receiver Service Configuration
Use the IP Receiver Service Configuration dialog box to configure communication with a
central monitoring station.
Prerequisite
Before starting to configure the IP Receiver service, you will need to gather configuration
settings from the local IT administrator and the CMS administrator. Through the My-Eddie
website, you can download the EST3X IP Dialer-Email Configuration Worksheet (P/N
3102338-EN) that will guide you through the information to gather. To access the website,
enter my-eddie.com in your web browser, and then locate the worksheet in Media Type >
Installation Sheets.
IP Service
Service Type
Label
Description
Receiver
Receiver Protocol
Primary IP
Enable
Secure Communication
IP Address / Domain Name
Port No
Encryption Key
Response Time
Receiver Account Code

Alternate IP
Note: Configuring an alternate central monitoring station is optional.
Enable
Secure Communication
IP Address / Domain Name
Port No
Encryption Key
Response Time
Receiver Account Code
DNIS
Enable DNIS
Counters and Timers
Heartbeat
Supervision Time
Maximum Attempts
Test Messages
Note: We recommend that you always specify Normal and Abnormal test messages, even
if the system does not require periodic tests, because the IP dialer can use the test
messages to exercise the connection after the system detects faults.
Normal Message
Abnormal Message
Ignore Monitor events when determining system status
Email Service Configuration
Use the Email Service Configuration dialog box to configure communication with an SMTP
server.
Prerequisite
Before starting to configure the Email service, you will need to gather configuration settings
from the local IT administrator. If no local IT administrator or no local SMTP server is
available and a public email service will be used, you will need to contact the Internet
service provider for configuration settings. Through the My-Eddie website, you can
download the EST3X IP Dialer-Email Configuration Worksheet (P/N 3102338-EN) that will
guide you through the information to gather from the local administrator or Internet service
provider. To access the website, enter my-eddie.com in your web browser, and then locate
the worksheet in Media Type > Installation Sheets.
Email Service
Service Type
Label
Description
SMTP Primary
Enable
IP Address / Domain Name
Port No
Response Time
SMTP Alternate
Note: Configuring an alternate SMTP server is optional.
Enable
IP Address / Domain Name
Port No
Response Time
Settings
Maximum Attempts
Timeout
Event Buffer Time
User Name
Password
SSL
No Supervision
From Email Address
Root Certificate
ECP Service Configuration
Use the ECP Service Configuration dialog box to configure an ECP Service that allows the
panel to send system events to a UL Listed FireWorks workstation.
Prerequisite
Before starting to configure the ECP service, you will need to gather configuration settings
from the FireWorks workstation administrator. Through the My-Eddie website, you can
download the EST3X IP Dialer-Email Configuration Worksheet (P/N 3102338-EN) that will
guide you through the information to gather. To access the website, enter my-eddie.com in
your web browser, and then locate the worksheet in Media Type > Installation Sheets.

ECP Service
Service Type
Label
Description
Port Type

ECP Configuration
Encrypted Communication
Passphrase
FireWorks
Enable
Primary IP / FireWorks PC
Alternate IP / FireWorks PC
Port
Keep the default port number or enter a user-defined FireWorks workstation port number
that the panel will use to communicate with FireWorks.
Possible values: 1 to 65535
Default setting: 1000x (Where x is the Service ID number)
Gateway / RDU Settings
Primary
Alternate
Port connection is a Control Center
Command Logging
Card Access Events
Receiver Account Properties
Use the Receiver Accounts Properties dialog box to configure account properties that are
used in the project database and rules.
Account
Label
Description
Receiver
CMS Account Number
Auto Generate Events
Test Timers
Enable Test Timers
Test Interval
Test Time of Day
Email Account Properties
Use the Email Accounts Properties dialog box to configure account properties that are used
in the project database and rules.
Account Name
Account Label
Description
Service
Email Message
SMS Text
Subject Text
Instruction Text
Specify Time of Day for Email Distribution
Specify Time of Day for Email Distribution
Start Time
Stop Time
Available Emails List
Lists email addresses that can be added to the Distribution List.
Add button
Delete button
Arrow buttons

Distribution List
Lists addresses that will receive the messages generated by this account (20 max.).
No. of Email Addresses
Specifies the number of email addresses in the Distribution List.
Object Configuration - Guard Patrol tab
Use the Guard Patrol tab to determine the operating characteristics of a guard patrol
group. When you create a guard patrol group, the SDU adds an object to the object
configuration table with the GuardPatrol device type.
Guard Patrol Groups
Label
Number of Routes
Group Description
Available Groups
Available Groups
Devices in Selected Group
Allows you to specify which inputs can activate the group.
Label Text
States (Q1, Q2, Q3, Q4)
Device/Station Info
Settings in effect for the device and route selected. Use this display to review the settings
for each route.
Route
Station ID
Min Time to Station
Max Time to Station
View Guard Patrol button
Buttons
New Group button
Add Devices button
Remove Devices button
Clear Devices button
Edit Message button
Delete Group button
Pick Devices button
Additive
See also
Configuring a guard patrol group
Deleting a guard patrol tour
Object Configuration - Matrix tab
Use the Matrix tab to specify how you want a matrix group to function. A matrix group
becomes active when any two devices within the search radius change to the active state,
or when the number of device activations equals or exceeds the Activation Number.
Note: You would typically use matrix groups for specialized applications such as releasing
extinguishing agents.
Matrix Groups
Label for Matrix Group
Activation Number
Radius
Activation Event
Group Description
Available Groups
Available Groups
Devices in Selected Group
Label Text
Active States (Q1, Q2, Q3, Q4)
Device Info
X Coordinate
Y Coordinate
View Matrix button
Buttons
New Group button
Add Devices button
Remove Devices button
Clear Devices button
Edit Message button
Delete Group button
Pick Devices button
Additive
See also
Configuring a matrix group
Defining a matrix grid
Object Configuration - Partitions tab
Use the Partitions tab to control the settings for any given partition.
Note: Partition groups are not supported in a networks consisting only of 3X panels (3X
Only networks). The SDU removes any existing partition groups from projects that contain
only 3X cabinets (CAB6s). On EST3/Combination networks, the SDU does not remove
partition groups.
Partitions
Label
Max Bypassed
Entry Delay Timer
Exit Delay Timer
Group Description
Available Groups
Available Groups
Devices in Selected Group
Label Text
Standard
Warning
Error
Buttons
New Group button
Add Devices button
Remove Devices button
Clear Devices button
Edit Message button
Delete Group button
Pick Devices button
Additive
See also
Configuring a partition
Object Configuration - Service tab
Use the Service tab to create and configure a service group. When you create a service
group, the SDU adds an object to the object configuration table with the SERVICEGROUP
device type.
Service Groups
Label for Service Group
Group Description
Available Groups
Available Groups
Devices in Selected Group
Label Text
Buttons
New Group button
Add Devices button
Remove Devices button
Clear Devices button
Edit Message button
Delete Group button
Pick Devices button
Additive
See also
Configuring a service group
Object Configuration - Zone tab
Use the Zone tab to define zone groups. When you create a zone group, the SDU adds an
object to the object configuration table with the ZONE device type.
Zone Groups
Label
Group Description
Enable Trouble Zone
Available Groups
Available Groups
Devices in Selected Group
Label Text
Buttons
New Group button
Add Devices button
Remove Devices button
Clear Devices button
Edit Message button
Delete Group button
Pick Devices button
Additive
See also
Configuring a zone group
Object Configuration - AND tab
Use the AND tab to determine the operating characteristics of an AND group. When you
create an AND group, the SDU adds an object to the object configuration table with the
AND device type.
AND Groups
Label for AND Group x
Activation Number
Activation Event
Group Description
Available Groups
Available Groups
Devices in Selected Group
Allows you to specify which inputs can activate the group.
Label Text
States (Q1, Q2, Q3, Q4)
Not Active (NA)
Buttons
New Group button
Add Devices button
Remove Devices button
Clear Devices button
Edit Message button
Delete Group button
Pick Devices button
Additive
See also
Configuring an AND group
Rules for AND groups and the Not Active device state
Object Configuration - Instruction Text tab
Use the Instruction Text tab to create an instruction text group and define its operating
characteristics. When you create an instruction text group the SDU adds an object to the
object configuration table with the TEXT device type.
Instruction Text Groups
Label for Instruction Text Group
Group Description
Available Groups
Available Groups
Devices in Selected Group
Label Text
Active States (Q1, Q2, Q3, Q4)
Buttons
New Group button
Add Devices button
Remove Devices button
Clear Devices button
Edit Message button
Delete Group button
Pick Devices button
Additive
See also
Configuring an instruction text group
Audio Message Configuration - Audio Messages tab
The Audio Messages tab lets you configure audio messages that the system plays during
an alarm.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
ASU
Messages
Script for
Play, Record, Pause, Stop
Current Position
Message Length
See also
How to use the Audio Message Recorder
Adding content to an audio message record
Editing and deleting audio messages
Audio Message Configuration - Audio Clips tab
The Audio Clips tab allows you to configure audio clips you can use to build messages that
the system plays during an alarm.
Note: The audio source for the 3X panel is the EAEC card. Use the ASU options to
program the EAEC.
Clip Library
Clips
Script for
Play, Record, Pause, Stop
Current Position
Clip Length
See also
How to use the Audio Message Recorder
Working with audio clip libraries
Adding new audio clips
Editing and deleting audio clips
Project Parameters - Operations tab
Use the Operations tab to select project-level settings.
Market Place
Market Place Description button
Primary Language
Secondary Language
Date Format
Water Flow Silence
Zone Resound Inhibit
Standalone Mode
Allow Disables
Alarm Silence
Drill
Restore Event on Disable
Allow Alarms During dB Download (EST3 only)
Re-evaluate SET Priorities on Restore
Control Center Comm Fault Access Level Override
Relay Confirmations and Monitors Events that are set to "No Cabinets"
See also
Configuring CPU operation
Configuring panel display operation
Daylight saving time around the world
The table below lists the dates when daylight saving time take effect in various countries
around the world. During daylight saving time, clock time is one hour ahead of standard
time. All time changes takes effect between midnight and 3 am.
Note: This table should only be used as a reference. For the exact days and times for
daylight saving time in your area, check with the local authorities.

Continent Country Set clocks ahead one Set clocks back one
hour hour

Africa Egypt Last Friday in April Last Thursday in

September

Namibia First Sunday in September First Sunday in April

Asia Iraq April 1 October 1

Iran First day of Farvardin First day of Mehr

Lebanon Last Sunday in March Last Sunday in October

Mongolia Last Sunday in March Last Sunday in September

Palestine First Friday on or after April First Friday on or after

5 October 5

Syria April 1 October 1

USSR, States of Last Sunday in March Last Sunday in October

the former

Australasia Australia Last Sunday in October Last Sunday in March

Australia - First Sunday in October Last Sunday in March

Tasmania

Fiji First Sunday in November Last Sunday in February

New Zealand First Sunday in October Third Sunday on or after

March 5

Tonga First Sunday in October First Sunday on or after

April 15

Europe European Union Last Sunday in March Last Sunday in October

USSR, States of Last Sunday in March Last Sunday in October

the former

North Bahamas Second Sunday in March First Sunday in November

America

Canada Second Sunday in March First Sunday in November

Caicos Second Sunday in March First Sunday in November

Cuba Second Sunday in March First Sunday in November

Greenland Second Sunday in March First Sunday in November

Mexico Second Sunday in March First Sunday in November

St. Johns Second Sunday in March First Sunday in November

 Turks Second Sunday in March First Sunday in November

United States Second Sunday in March First Sunday in November

South Brazil [1] First Sunday in November Third Sunday in February

America

Chile Second Saturday of Second Saturday of March

October - at midnight - at midnight

Falklands First Sunday on or after First Sunday on or after

September 8 April 6

Paraguay First Sunday in September First Sunday in April

[1] Rules vary quite a bit from year to year. Also, equatorial Brazil does not observe DST.
Networking protocols
The following are examples of network protocols.
Net BEUI: Short for NetBios Extended User Interface. It is an enhanced version of
the NetBios protocol used by Windows for Workgroups, Windows95 and
WindowsNT operating systems to name a few.
IPX: Short for Internetwork Packet Exchange, a networking protocol used by the
Novell NetWare operating systems.
TCP/IP (most common): The suite of communications protocols used to connect
hosts on the Internet. TCP/IP uses several protocols, the two main ones being TCP
and IP. TCP/IP is built into the UNIX operating system and is used by the internet,
making it the de facto standard for transmitting data over networks. Even network
operating systems that have their own protocols, such as NetWare, also support
TCP/IP.
See Also
Ethernet terminology
Basic network addressing
Subnet masks
Cabinet Configuration - Port Type: Remote diagnostics and
Gateway types
When configuring your cabinet to communicate to external equipment using the ECP
protocol, select Remote Diagnostics or a Gateway type as the Port Type. The SDU will set
ECP protocol characteristics based on your selection. Refer to the table below to
determine which selection to choose. The table indicates whether the listed characteristic
will be on, off, or user defined.

ECP protocol Gateway Gateway Gateway Gateway Gateway Remote

characteristic Type II Type II with Type III Type III with Diagnostics
Text Text

Send event activations On On On On On Off

and restorals

Send event activations Off Off On Off On Off

and restorals with text

Send low priority event On Off Off On Off Off

activations and restorals
[1]

Send supervisory events On On On On On Off

Slow interface timing Off On On Off Off On

Send all normal Access User Off Off User Off Off
(CRC card reader) defined defined
events [2] (default (default
Off) Off)

Send abnormal Access User Off Off User Off Off

(CRC card reader) defined defined
events [2] (default (default
Off) Off)

[1] Low priority events include relay confirmations, as well as background (disarmed)
security device state changes.
[2] Normal Access (CRC card reader) events are the Access Granted event (Type 0) and
Access Granted Muster event (Type 4). Event types other than these are considered
abnormal Access event types.
Short address groups
In 3-SDU V5.40 and higher, when output modules are added to a Signature loop, each
module is assigned a short address in addition to a device address. For dual address
modules, two short addresses are assigned. Once added to the database, the SDU
automatically places up to 16 consecutive short addresses into one of eight available short
address groups. This allows the system to activate and deactivate all the modules in the
same group at the same time. For example, for modules that control paging circuits and are
in the same group, the page is activated (or deactivated) by a single command when the 3-
ASU paging microphone PTT switch is pressed.
Utilizing short address groups is important for optimizing the response time of paging
outputs but this feature is not limited to paging devices. All output devices can benefit by
placing outputs that you want to activate and deactivate together in the same group.
However, because of significance that short addressing has on paging, the SDU attempts
to automatically assign audible output modules to separate groups from other output
module types.
By default, short addresses fall into one of eight groups based on their short address. The
table below shows the address ranges available within each group.

Short Address Short Addresses

Group
1 129-143 (*)
2 144-159
3 160-175
4 176-191
5 192-207
6 208-223
7 224-239
8 240-254 (*)

* Short addresses 128 and 255 are not used

To change a device's short address group:

1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the loop controller for the device being configured,
and then click the Modules tab.
3. On the Hardware Layer tab, select the loop controller, and then click LRM Config.
4. In the Signature Series Configuration dialog box, click the Loop Modules tab.
5. Select the output module being configured, and then select the desired group in the
Short Address Group list. Note that the short address changes when you move the
 module to a different group.
Note: If all short addresses in the desired group are used, a message will appear saying
that the group is full. To free up an address, move one of the existing modules to another
group.
6. Click Close.
See also
Signature Series Configuration - Modules tab
Signature Series Configuration - Detectors tab
Configuring a Signature loop controller module
Configuring a 3-AADC module
You can configure a 3-AADC module with up to 99 sensors and 99 modules connected to
its signaling line circuit. To make configuring a 3-AADC module easier, you can set default
values for each type of addressable analog device. As you add each device, the default
values are automatically entered into the configuration table.
You can also add more than one device at one time. When you add multiple devices, the
devices are assigned a contiguous block of addresses starting at the selected (lowest)
address.
To configure a 3-AADC module:
1. On the Configure menu, click Cabinet.
2. Select the cabinet that contains the 3-AADC being configured and then click the
Modules tab.
3. On the Hardware Layer tab, select the 3-AADC, and then click LRM Config.
4. On the Card Parameters tab, perform the following steps:
Under Wiring Class, click Class A or Class B depending on the required
performance of the loop controller's signaling line circuit.
Under Device Series, click A Series or B Series depending on the type of devices
connected to the signaling line circuit.
Under Polling LED Action, click Blink or No Blink depending on the required action of
the device's light-emitting diode while the loop controller polls the device.
Under Supervisory, click Latching or Non Latching depending on whether supervisory
states are latched on the loop controller.
5. On the Sensors tab, add all of the sensors that are connected to the signaling line
circuit. To add a sensor:
Locate the device's assigned address in the configuration table. If addresses have
not been assigned, go to the first available address.
Double-click the Model list box for the desired address then click the model name of
the device being added. The SDU adds the devices to the configuration table and
automatically enters the default values for the device properties.
6. On the Modules tab, add all of the modules that are connected to the signaling line
circuit. Add modules the same way as you did sensors.
7. Click OK.
See also
AADC Configuration dialog box - Parameters tab
Changing addresses on addressable analog devices
Setting default properties for addressable analog devices
Tips for configuring a 3-AADC module
Tips for configuring a 3-AADC module
Here are some tips for configuring a 3-AADC module:
Before adding any devices, make sure that the device default settings are set for
the correct values.
If you need to add devices with different default settings, arrange them in blocks,
change the default value settings on the Card Parameters tab, and add them using
the Add Multiple option.
When adding multiple devices, make sure the number of devices does not exceed
the number of free contiguous addresses. If the block size overlaps existing devices
in the configuration table, the existing devices will be overwritten with the new
devices.