Driver Manual
(Supplement to the FieldServer Instruction Manual)
FS-8705-16
Mircom FX2000 Fire Alarm Panel
APPLICABILITY & EFFECTIVITY
Effective for all systems manufactured after May 1, 2001

1.  Mircom FX2000 Fire Alarm Panel Serial Driver Description

The FX2000 driver is a passive client driver intended for connection to the serial printer port of a FX2000 Panel. A passive client driver waits for messages to be sent to it (by the panel). The driver cannot send messages to the panel and hence it cannot request the state of any point in the panel.

The driver can process alarm and trouble events and the system reset message. All other messages and events are ignored.

The driver can only be used as a client. Minimal server functionality is provided only to support our ongoing quality assurance program by facilitating automated testing of the driver. It is not documented or supported.

Synchronization

A consequence of the fact that this is a passive client driver, is that the FieldServer must be synchronized with the panel by clearing all abnormal states, resetting the panel and then restarting the FieldServer/Sending the FieldServer a command to reset the data.

Driver Functionality

When an alarm occurs the panel reports the alarm with a message which identifies the loop and address. The driver will store a 1 in a Data Array location mapped for that point. When the condition causing alarm is cleared, the panel does not send a message reporting this. Thus the driver will not know the condition has been cleared until a panel reset is performed. When a reset is performed the driver will clear all the alarm states, previsouly stored, to zero. For those points where the alarm condition has not been cleared, the panel sends a new alarm notification which the driver will recognize and store a 1 in a Data Array location mapped for that point.

Thus for the two scenario’s

Alarm condition cleared before reset

Alarm Event                  - Driver Store a 1

Alarm condition cleared  - Driver is not informed (no message from panel)

Reset Initiated              - Driver clears the 1 to zero (for all alarms)

Alarm condition not cleared before reset

Alarm Event- Driver Stores a 1

Reset Initiated- Driver clears the 1 to zero (for all alarms)

Panel now sends re-notifications of active alarms

Re-notification of Alarm Event – Driver Stores a 1

For troubles, the panel sends a message when the trouble event occurs and it also sends a message when the event is cleared even if a panel reset has not been performed. The driver will store a 1 when the trouble event occurs and a zero when it is cleared. This will not be affected by a reset.

Max Nodes Supported

2. Driver Scope of Supply

2.1  Supplied by FieldServer Technologies for this driver

2.2  Provided by the Supplier of 3rd Party Equipment

2.2.1 Required 3rd Party Hardware

2.2.2  Required 3rd Party Software

2.2.3 Required 3rd Party Configuration

None Known.

3.  Hardware Connections

Multiple upstream protocols and connection supported. See list of FieldServer Drivers.

3.1  Hardware Connection Tips / Hints

Blank Section

4.  Configuring the FieldServer as a FX2000 Fire Alarm Panel Passive Client

For a detailed discussion on FieldServer configuration, please refer to the FieldServer Configuration Manual. The information that follows describes how to expand upon the factory defaults provided in the configuration files included with the FieldServer (See “.csv” sample files provided with the FS).

This section documents and describes the parameters necessary for configuring the FieldServer to communicate with a FX2000 Panel

4.1  Data Arrays/Descriptors

The configuration file tells the FieldServer about its interfaces, and the routing of data required. In order to enable the FieldServer for FSC – Electronic Siren Controllers Serial Driver communications, the driver independent FieldServer buffers need to be declared in the “Data Arrays” section, the destination device addresses need to be declared in the “Client Side Nodes” section, and the data required from the servers needs to be mapped in the “Client Side Map Descriptors” section. Details on how to do this can be found below.

Note that in the tables, * indicates an optional parameter, with the bold legal value being the default.

Example

4.2  Client Side Connection Descriptions

Create one connection for each FX2000 port. Each connection can only be used to connect to a single FX2000 interface/port.

___________________

¹ Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction manual for details of the ports available on specific hardware.

Example

4.3  Client Side Connections

Create one Node per connection only.

Example

4.4  Client Side Map Descriptors

4.4.1 FieldServer Related Map Descriptor Parameters

4.4.2  Driver Related Map Descriptor Parameters

4.4.3  Timing Parameters

4.4.4 Map Descriptor Example 1 .

Only one Map Descriptor is required to process all messages from the panel. The driver stores data in specially named Data Arrays.

4.5  How Point Data is Stored.

For the purposes of this discussion we will call a loop-address combination a point (which represents a field device such as a pull station, a smoke detector etc.).

The driver stores data representing panel events in specially named data arrays. They are named as follows:

DA_FX2000LOOPxx

Where xx = Loop Number

Example: DA_FX2000LOOP01, DA_FX2000LOOP02, DA_FX2000LOOP03 etc.

It is your responsibility to define data arrays for each loop that can report events.

When the driver receives a message reporting an event for a loop-address point it updated the data array named after the loop. The position in the data array that is updated is based on the address.

Example:  Event for Loop 2 Address 90

Driver updates DA_FX2000LOOP02[90] ie. Offset 90 of the Data Array called DA_FX2000LOOP02

Each of these location is treated as byte with 8 bits. Which bits get updated indicates the kind of event.

Example:

Alarm Event for Loop 2 Address 90

Driver updates DA_FX2000LOOP02[90] = 5

Indicates alarm state is active (bit 0)

Indicates alarm/trouble active (bit 2)

Example:

Trouble Event for Loop 2 Address 90

Driver updates DA_FX2000LOOP02[90] = 6

Indicates trouble state is active (bit 1)

Indicates alarm/trouble active (bit 2)

Example:

Restored Trouble Event for Loop 2 Address 90

Driver updates DA_FX2000LOOP02[90] = 0

Indicates trouble state is normal (bit 1)

Indicates alarm/trouble not present (bit 2)

4.6  How Most Recent Event Data is Stored.

Each time an event is processed the driver stores data about the most recent event is a specially named data array. All you need to in the configuration is define the Data Array with named “DA_FX2000”

Example:

Data_Arrays

Data_Array_Name ,Data_Format ,Data_Array_Length

DA_FX2000,       UINT16,      20

The driver uses offsets 1-10 to store summary data.

The driver looks for this array and stores the following table of data:

4.7  Driver Limitations and Event Processing

The driver can only process the following events

You can change the list of keywords that the driver recognizes. Preapre and download a file called fx2000.ini (case sensitive file name). After the download the driver will load and use the table of keywords.

This is a sample for fx2000.ini. If you were to prepare and use this sample then there would be no change to the driver’s default behavior since this list of keywords is the same as the one the

driver recognizes by default.

Example 1:

TROUBLE RESTORED, 1 , 1 ,

OPEN CIRCUIT TRB, 2 , 1 ,

TRB, 2 , 1 ,

TROUBLE, 2 , 1 ,

MISSING DEVICE, 2 , 1 ,

ALARM ACTIVATED, 3 , 1 ,

PRIORITY ALARM, 3 , 1 ,

SYSTEM RESET COMPLETE, 4 , 0 ,

Note the format.

1. Caps for keywords

2. No spaces to left or right of the keywords. Ie no space before comma

3. Column 2 represents the event type.

a. 1=Restore

b. 2=Trouble

c. 3=Alarm

d. 4=Reset

4. Column 3 tells the driver if a loop/address should be expected. 1=yes. 0=No.

For example. Say you wanted the driver to recognize a new alarm event which will be recognized by the text ‘Initial Alarm’. Then 1) Prepare the file with all the lines from example 1 and then add the line from example 2.

Example 2:

INITIAL ALARM, 3 , 1 ,

The driver processes these lines in order from top to bottom. That is why the ‘Trouble Restored’ line is placed before the line with ‘Trouble’. If it were the other way around the driver would match the word trouble and thus recognize the ‘Trouble Restored’ message incorrectly as a trouble.

5.  Configuring the FieldServer as a FX2000 – Security Intercom System Server

This driver cannot be used to emulate a FX2000 panel.

Appendix 1. Advanced Topics

This section is blank.

Appendix 1.1. Driver Error Messages

Revision History