5.4.1 Zone Status .......................................................................................................................................... 14
5.4.2 Device Status ........................................................................................................................................ 14
5.4.3 Panel Information ................................................................................................................................ 14
5.4.4 History Events ...................................................................................................................................... 14
5.4.6 Map Descriptor Example 1. (All Zones Data) ....................................................................................... 16
5.4.7 Map Descriptor Example 2.(Specific Zone Data) .................................................................................. 16
5.4.8 Map Descriptor Example 3 – Zone Status as a numeric value ............................................................. 17
5.4.9 Map Descriptor Example 4 – All Devices .............................................................................................. 18
5.4.10 Map Descriptor Example 5 (Specific Device) ........................................................................................ 19
5.4.11 Map Descriptor Example 6 - Device States as a Numeric Value .......................................................... 19
5.4.12 Map Descriptor Example 7 – Panel Data ............................................................................................. 20
5.4.13 Map Descriptor Example 8 – History Data (All Devices) ...................................................................... 20
5.4.14 Map Descriptor Example 9 – Full History Event Record – Specific Device ............................................ 21
5.4.15 Map Descriptor Example 10 – Full History Event Record – Any Device ................................................ 21
5.4.16 Map Descriptor Example 11 – Alarm Ack ............................................................................................. 22
6 Configuring the FieldServer as a Cheetah Device Server ............................................................................... 23
Appendix A. Useful Features ................................................................................................................................ 24
Appendix B. Vendor Information ......................................................................................................................... 25
Appendix B.1. Fike Cheetah Panel Firmware version sensitivity ............................................................................. 25
Appendix B.2. Fike XI Panel Limitations and capabilities ......................................................................................... 25
Appendix C. Troubleshooting ............................................................................................................................... 26
Appendix D. Reference ........................................................................................................................................ 29
Appendix D.3. Storing Panel Data ............................................................................................................................ 29
Appendix D.4. How History Events are Stored ........................................................................................................ 30
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
The Cheetah Protocol driver allows the FieldServer to transfer data to and from devices over either RS-232 or RS485 using the Cheetah device protocols (Legacy Cheetah Classic and the current Cheetah Xi).
The driver supports messages sent from the Cybercat panel. Specifically, the driver supports message 1.02 which
reports panel, zone and device states.
The FieldServer can emulate either a Server or Client but it should be noted that it can only process unsolicited
messages from the Cheetah devices. Thus, it does not provide an active Client driver. It is best to consider this
driver as a consumer only driver with the data being produced by a Cheetah controller.
2 DRIVER SC O P E OF SUPP LY
2.1 Suppli e d by FieldServer T e c hnologies for t his driver
2.2 Provid e d by Supplie r of 3
rd
Part y Eq uipment
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
RJ11
MIM
Black wire RX pin 2
Green wire TX pin 4
Yellow wire GND pin 5
RJ45
FieldServer
Orange/White wire TX pin 8
Brown wire RX pin 1
Blue/White wire GND pin 4
3.4Conn e cting the Fie l d Se r v er to the MIM (M u l ti -Inte r f ace Module)
The RS-232 port of the FieldServer connects to the P5 (RJ11) RS-232 port of the MIM board.
3.4. 1 Conn e ction Notes
The Peripherals menu of the Fike Panel needs to be updated:
Hit ‘ESC’ until “Top Level Menu” is on the screen Hit ‘F1’ for “Config” Hit ‘F6’ for “Menu 2” Hit ‘F6’ for “Menu 3” Hit ‘F1’ for “Periph” Hit ‘F1’ for “Device” Choose address of MIM
Set “Type” to “Computer” Set “Supervise” to “No”
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
Provide data format. Each Data Array can only
take on one format. The Cheetah driver always
sets Data Array elements to a zero or one. Thus,
the use of bit arrays is suggested but is not
mandatory.
Number of Data Objects. Must be larger than
the data storage area required by the Map
Descriptors for the data being placed in this
array.
1-10,000. If you use the 'All' keyword
when setting the parameter
Cheet_Zone/Device then the minimum
length is 128.
// Data Arrays
Data_Arrays
Data_Array_Name
, Data_Array_Format
, Data_Array_Length
ZONE_ALARMS
, Bit
, 256
PANEL_DATA
, Float
, 1000
DA_HIST
, Float
, 1000
DEVICE_L1_STATE
, Float
, 256
4 DATA ARRAY P A R A METERS
Data Arrays are “protocol neutral” data buffers for storage of data to be passed between protocols. It is necessary
to declare the data format of each of the Data Arrays to facilitate correct storage of the relevant data.
Example
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
Specify which port the device is
connected to the FieldServer
P1-P8, R1-R22
Baud*
Specify baud rate
9600 (Vendor limitation)
Parity*
Specify parity
None, (Vendor limitation)
Data_Bits*
Specify data bits
8 (Vendor limitation)
Stop_Bits*
Specify stop bits
1 (Vendor limitation)
Protocol
Specify protocol used
Cheetah (makes the port the exclusive domain of
Cheetah devices.) This keyword is not required when
specifying the port.
MIM_Enabled*
Enable multi-panel
communications via the MIM
module
Yes, No
// Client Side Connections
Port
, Baud
, Protocol
, Parity
, Data_Bits
, Stop_Bits
, MIM_Enabled
P1
, 9600
, Cheetah
, None
, 8
, 1
, Yes
2
5 CONFIGURING T HE F I ELDSERVER A S A C H E E T AH DEVICE 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 FieldServer)
This section documents and describes the parameters necessary for configuring the FieldServer to communicate
with a Cheetah Device Client.
The configuration file tells the FieldServer about its interfaces, and the routing of data required. In order to enable
the FieldServer for Cheetah Device 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 “Server Side
Nodes” section and the data required from the Client needs to be mapped in the “Server 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.
5.1 Cli e nt S ide Connection Param et e r s
Example
Not all ports shown are necessarily supported by the hardware. Consult the appropriate Instruction manual for details of the ports available
on specific hardware.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
A Map Descriptor may be used to store data for one, all or no
zones. To store data from multiple zones, multiple Map
Descriptors must be declared, each specifying the zone of
interest. When specifying “All”, the data for zone 0 is stored in
the first element of the Data Array defined by the
Data_Array_Name & Data_Array_Offset and the data for zone
127 in the 128th element of the Data Array.
Depending on the firmware version of the Cheetah panel some or
all of the following states are available. Abort, Trouble,
Supervisory, Zone Disable, Pre-Alarm, Alarm, Pre-Discharge,
Release, Process.
To store data for multiple states, multiple Map Descriptors must
be declared - One per state of interest.
None, All, 0-127
Must be None when
Cheet_Device is not equal
to None.
Cheet_Device*
Define one or more Map Descriptors to store data from the 0-127
addressable devices. Each Map Descriptor must have the
Cheet_Zone set to None.
Devices belong to one of 4 possible loops. Thus when
Cheet_Device is set to All or to a specific device number, the
Cheet_Loop number must be set to a value from 1 to 4.
If Cheet_Device is set to All then 128 states are stored. The data
for device 0 is stored in the first element of the Data Array
defined by the Data_Array_Name & Data_Array_Offset and the
data for device 127 in the 128th element of the Data Array.
None, All, 0-127
Must be None when
Cheet_Zone is not equal
to None.
Cheet_Loop
Specify this parameter when the value of Cheet_Device is not
equal to none.
None, 1-3
Must be None when
Cheet_Zone is not equal
to None.
Cheet_DT*
Data Type. Multiple Map Descriptors are required to store
multiple states in one/more Data Arrays.
Only Alarm and Trouble
are valid when storing
device data
Length
The length of the Data_Array that will be used to store the
information. Ensure that the length is sufficient to store all
information (e.g. for Zone Data the minimum length is 241
(Enough space for Zones 0-240).
1-10,000
Cheet_Func*
Use for active Map Descriptors only
Port Response, -
5.3. 2 Driv e r Specific Map Descr i ptor P arameters
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
Full details of the most recent event (any device) may be stored in
the data array DA_HIST_EVENT. See sections 5.4.14 and 5.4.15.
Appendix D.3 maps the layout of this data.
DA_Hist_Event
5.4 Map D e scriptor Examples
The driver processes messages from the panel that relay the panel’s current status as well as new history events.
These messages contain composite data and the contents cannot simply be stored in a Data Array to read by a
Client device.
Map Descriptors are used to store portions of this composite data from the following categories. At least one Map
Descriptor is required for each category.
5.4. 1 Zone Status
There are two methods of storing Zone status data:
The driver can store the state (trouble, alarm, pre-alarm...) of each zone in a separate array as a a bit state
(1 or 0). See sections 5.4.6 and 5.4.7. A separate Map Descriptor is required per zone state (9 possible).
The driver can store a number to indicate normal or abnormal state of each zone. (The value of the
number indicates the states.) See section 5.4.8. All data is stored in a single Data Array and one Map
Descriptor is required for all zones.
5.4. 2 Device S tatus
There are two methods of storing Device status data.
The driver can store the state (trouble, alarm, pre-alarm...) of each device in a separate array as a bit state
(1 or 0). See sections 5.4.9 and 5.4.10.. A separate Map Descriptor is required per zone state (9 possible).
A separate set of Map Descriptors is required for each loop (4 possible).
The driver can store a number in a separate Data Array to indicate normal or abnormal state of each
device. See section 5.4.11. All data is stored in a single Data Array and one Map Descriptor is required for
all zones.
5.4. 3 Pane l Information
Information about the panel itself such as evento counters, board status and LED status c an be stored by the
driver. See section 5.4.12. This data is stored in consecutive array locations. Appendix D.3 maps the layout of this
data.
5.4. 4 His t o ry Events
History events can be stored in two formats:
Event codes for all devices are stored in a single data array at a location based on the source device’s
address. This gives an array of the most recent events for all devices. See section 5.4.13
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
The entire history event record for the most recent event (any device or a specific device) can be stored in
the Data Array DA_HIST_EVENT which must be defined as described in Section 4. Appendix D.3 maps the
layout of this data.
5.4. 5 Ack n o w ledging Alar m s
There are significant limitations on the driver’s ability to send alarm acknowledgements to the panel. Refer to
Appendix A.1 for more information. Section 5.4.16 describes a Map Descriptor which can be used to get the driver
to acknowledge alarms.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
The data is stored
into a Data Array
called DA_1 for
zone 1 and DA_2 for
zone 2...
Starting at element
zero.
A separate Map Descriptor is
required for each Data Type.
Data for All Zones is stored
(241 data elements)
5.4. 6 Map D e s criptor Example 1. (Al l Zones Data)
This Map Descriptor may be used to store Zone data sent by the panel. The message sent by the panel is dependent on the panel’s firmware version. This
Map Descriptor will use 241 consecutive array locations to store data for the zones. Zone 0’s data will be stored at the first location and Zone 240’s state will
be stored at the 241st location. The base location in the array is determined by the Data Array offset,
5.4. 7 Map D e s criptor Example 2.(Spe c ific Zone Data)
In this example the Map Descriptors store data for one zone each. This variation allows the manipulation of the arrangement of data in Data Arrays.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
This data type tells the driver that this Map Descriptor must be used to
store zone status data of any type.
The driver writes a number into the array location for each device. The
value of the number indicates the status of the zone. The value is
based on which bits in the binary number are set.
Bit 0: Abort State
Bit 1: Trouble State
Bit 2: Supervisory State
Bit 3: Zone is disabled
Bit 4: Pre Alarm State
Bit 5: Alarm State
Bit 6: Pre-Discharge State
Bit 7: Release State
Bit 8: Process State
Example : Value = 32 indicates an alarm state
Example : Value = 96 indicates an alarm & pre-discharge state
For the driver to effectively report the
status as a number the Data Array format
must be suitable for storing the number.
UINT16, UINT32 and FLOAT formats are
supported.
5.4. 8 Map D e s criptor Example 3 – Zone S t atus as a num e r i c value
In this example, the driver stores zone data for any zone. It will store data for all possible states that the panel reports for each of the zones in the form of a
number in the Data Array. The number can be interpreted to determine which states are active.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
Each Map Descriptor in this example reads
data for one device only. Thus each Map
Descriptor must point to a different Data
Array or as is the case in this example, to a
different location in the same Data Array.
They are passive
because this driver is
a data consumer.
When storing device
data the Cheet_Zone
must be set to None.
The driver is node independent; however
Node_A ties this Map Descriptor to a Node
Descriptor which thus connects the Map
Descriptor to a protocol and to a port.
The alarm
state is being
stored.
The Device number
is 20.
The device
belongs to loop1
The Any keyword tells the driver to store the device state as a number
The value of the number indicates the device state. The number is a binary
number and its value is determined by which bits are set.
Bit 0: Alarm
Bit 1: Pre-Alarm
Bit 2: Trouble
The array’s format must be suitable for
storing the state number which can range
from 0-15.
Thus BYTE, UINT16, UINT32 and FLOAT are
suitable formats for the Data Array.
5.4. 1 0 Map Descript o r E x a m ple 5 (Specific Devic e )
In this example, a Map Descriptor has been defined for the storage of the state of one specific device. (Device 20)
5.4. 1 1 Map Descript o r E x a m ple 6 - Device States a s a Numeric V a l ue
In this example the normal or abnormal state of all the devices of loops 1-4 will be stored by this Map Descriptor.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
The Panel keyword is used to store
the panel data using this Map
Descriptor.
Map Descriptor will store
History data
History events relate to
devices and thus the zone
must be set to None.
One Map Descriptor is
required per loop.
5.4. 1 2 Map Descript o r E x a m ple 7 – Panel Data
This example provides a Map Descriptor which tells the driver where to store the non-zone/device specific data obtained from a panel. Appendix D.3 of the
manual maps how the data is stored. Ensure that the Data Array is long enough to store all the data.
5.4. 1 3 Map Descript o r E x a m ple 8 – History Data ( A ll D e v ices)
In this example, 4 Map Descriptors process all history events on all four loops. One Data Array is used and loop #2’s data is stored at an offset location of 240
(max number of devices per loop) in the Data Array. The Device is set to ALL to tell the driver to process all devices on the loop using this Map Descriptor. If a
history event for device 100 on loop 3 is received then the driver will store the event code at location 480(=base offset for loop 3)+100 (=device address). The
event code will be stored as a number and the meaning of the number may be obtained by reading Appendix D.3
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
Event history records are stored in this Data Array.
The contents of the Data Array locations are
described in Appendix D.3. Each event record
uses at least 65 consecutive elements of the array
so the choice of an offset must be made carefully.
One device is processed using this Map
Descriptor. Thus only events relating to
device 20 of loop 1 will be stored using
this Map Descriptor. Events relating to
other devices will be discarded unless
additional Map Descriptors are defined.
Differs from Example 9 in that the
device is specified as ALL - now the
driver stores the event for any
device at the same location.
5.4. 1 4 Map Descript o r E x a m ple 9 – Full History E v e nt Record – Specific D e v i ce
Full History Event records contain composite data which require at least 65 consecutive Data Array locations for storage. If the Data_Array_Offset is not
carefully specified the storage areas will overlap.
5.4. 1 5 Map Descrip t o r E x ample 10 – Full Hi s t o r y Event Record – Any Dev i c e
Only the most recent history event is stored using this Map Descriptor. The full record is stored but is overwritten when a new event is received irrespective of
the event’s device address.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
This tells the driver
that this Map
Descriptor is to be
used for
acknowledging alarms.
The Map Descriptor
must always be
passive. This is
because this Map
Descriptor is used to
respond to the port
supervision query.
Only one element of this
Data Array is used.
The value determines how
the Cheetah panel will be
affected.
If bit 0 is set then the panel
will be reset.
If bit 1 is set then the panel
will be silenced.
If bit 2 is set then the panel
will be acknowledged.
5.4. 1 6 Map Descrip t o r E x ample 11 – Alarm Ac k
This example illustrates a Map Descriptor which can be used to acknowledge / silence or reset the panel. Read Appendix A.1 to understand the limitations of
this functionality. The value of the array element at offset zero in the array named DA_ACK is used to send a signal to the Cheetah panel.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
6 CONFIGURING T H E FIELDSERVER AS A C HEETAH DEVICE SERVE R
This Driver cannot act as a Server, i.e. it cannot write data to the Cheetah controller or devices. Thus it cannot be
used to acknowledge alarms or reset states.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
This driver can be used to acknowledge alarms, reset or silence the Cheetah panel.
This functionality is limited. For this function to operate the Cheetah panel must be configured to supervise the
port that the FieldServer is connected to. In addition to enabling this function, port supervision means that the
panel will go into alarm if the FieldServer does not respond to the supervision messages. In fact the request to ack
/reset/ silence the panel is included in the driver’s response to the supervision poll from the panel. The panel
ignores unsolicited messages. A consequence of this is that the driver cannot control the timing of when the ack
/reset/ silence message is sent to the panel.
In using this functionality you should also understand that the Cheetah panel protocol does not acknowledge
message receipt so this driver cannot report whether the message was received by the panel and whether it was
acted on.
The port supervision response message is sent even if you do not define a Port Response Map Descriptor in the
CSV file. In this case the command data will always be zero. Once you define a Map Descriptor then the driver
uses one Data Array element to determine the command data to send to the panel. The value from this array
element determines the action the panel will take.
Example: To Silence the Panel, then set the value of the Data Array element to 2.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
Appendix B.1. Fike Cheetah Panel Firmware version sensitivity
The following limitations to older firmware have been identified. FieldServer is unable to correlate this change
with a particular Fike firmware version number at the current time.
Messages 1.1 and 6.0 (graphics update msg) are sent by older panels. Only message 6.0 contains information that
can be used by the driver to reflect zone and device states. The 6.0 message is sent infrequently (typically 1 in 60
messages) and this results in a zone/device state update every few minutes.
Appendix B.1.1. Messa ge 6 . 0 li m it a t i o n s
Can only report data for 127 zones. Data is limited to Alarm, Trouble, Pre-Discharge and Released statesCan only report data for 127 devices on loops 1-4. Data is limited to Alarm, Trouble states.
Appendix B.1.2.Messa ge 1 . 1 - Ol d er f i r m w a r e
No useful information about zones or devices.
Appendix B.1.3.Messa ge 1 . 1 - Ne wer F i r mwa r e
Supports zones 1-240. For zones the following states are reported: Abort, Trouble, Supervisory, Disabled,
Report these messages to FieldServer Technologies.
Cheetah:#2 Simulation
function unknown.
Cheetah:#3 Protocol Error
(Start), Incoming msg
ignored - Waiting for next
msg.
Warning messages only. An incoming message was discarded because the
identifiers which mark the beginning of a message could not be found. You
cannot take any action to correct this message. If it occurs often check wiring,
noise and installation.
Cheetah:#4 Protocol Error
(Stop), Incoming msg
ignored - Waiting for next
msg.
Cheetah:#5 Protocol Error
(Chksum), Incoming msg
ignored - Waiting for next
msg.
Cheetah:#6 Protocol Error
(Unknown), Incoming msg
ignored - Waiting for next
msg.
Report this error to FieldServer Technologies.
Cheetah:#7a Err. Zone=%d
Max=%d
Cheetah:#7b MapDesc
Error. Zone value error.
(%d)
Cheetah:#7c FYI. Warning.
Zone=%d. Max zone is panel
type dependent. Read
Manual.
An invalid zone has been specified. The zone causing the problem is printed in
parenthesis.4
The largest possible zone number is 255. Only Cybercat panels support this
number of zones. Legacy panels support up to zone 239. Very old panels that
can only send message #6 can only report information for 127 panels.
If you are connected to a Cybercat panel and you get the FYI message you can
ignore it. If you are connected to some other panel and you get either the Err or
FYI message then you will need to correct the CSV file.
Cheetah:#8 MapDesc Error.
Device value error. (%d)
An invalid device has been specified. The device causing the problem is printed
in parenthesis.4
Cheetah:#9 MapDesc Error.
Loop value error. (%d)
An invalid loop has been specified. The loop causing the problem is printed in
parenthesis. 44
4
Appendix C. Troubleshooting
Appendix C.1. Driver Error Messages
Multiple protocol drivers may exist on a FieldServer. Each driver may produce its own error messages and the
FieldServer itself may produce error messages.
All messages produced by this driver begin "Cheetah:"
Modify the CSV file, download to the FieldServer and restart the FieldServer for the changes to take effect.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
Cheetah:#10 MapDesc
Error. Zone & Device
Specified.
One Map Descriptor cannot be used to store data for zones and devices. Either
the keyword Cheet_Zone or Cheet_Device must be set to None4.
Cheetah:#11 MapDesc
Error. With devices only
alarm & trouble available.
For devices only the alarm & trouble states are available. Set the Cheet_DT
values appropriately in the configuration file.4
Cheetah:#12 Message on
Cheetah port but no
mapDesc found.
A port has been reserved for the Cheetah protocol and a message has been
received on this port but there is no Map Descriptor defined for this port.5
Cheetah:#13 Data Array to
short. MapDesc=<%s>
RQD=%d.
The Data Array associated with the Map Descriptor in question is too short.
Adjust the length as required by the error message. Note that the error may be
repeated for a single Map Descriptor when a new zone or device is stored
because the storage location may be based on the zone or device number.
Generally for zone storage the array must have at least 240 locations (and 128 for
older Cheetah firmware.)5
Cheetah:#15 Err. MD length
is required - defaulting to 1
The Map Descriptor length must be sufficient to store all the data. The maximum
device number is 255 and the maximum zone number is 255, therefore to store
all zones and devices the MD's must be 256 elements long. Some legacy panels
and message don’t support the full number of devices/zones. For example some
panels only support 241 zones. Try and determine the correct length otherwise
please use 256. If you are unsure ask tech support to provide the template file
server.csv
Cheetah:#17. Err.
DIAG_USER_1
An internal diagnostic has been activated. This should not happen on a live
system. Take a log and contact tech support
Cheetah:# 18 Err. Bad msg
start= %#x
Messages are expected to begin with a Carriage return or SOH (0x01). The
message has been rejected because it starts with the reported byte. Perhaps the
vendor has changed firmware. If this error occurs repeatedly then take a log and
contact tech support. If it occurs rarely then assume it is noise and ignore it if
you are satisfied you are getting good data updates.
Cheetah:#19 FYI. Ignoring
0x0100 messages from
Cybercat.
Cybercat panels transmit legacy message which must be ignored. This message
confirms the driver is ignoring them. No corrective action is required. If you are
connected to a Cybercat panel and never see this message printed (checked the
system and driver error message screen) then please take a log and contact Tech
support.
Cheetah:#20 Err. DA too
short. Zone=%d MD=<%s>
RQD=%d
The driver is attempting to store zone status information from a Cybercat panel.
The Data Array is too short. Adjust the length of the Data Array and the length of
the Map Descriptor.5
Cheetah:#21. Err. DA too
short. MapDesc=<%s>
RQD=%d DA=%s
The driver is attempting to store device status information from a Cybercat
panel. The Data Array is too short. Adjust the length of the Data Array and the
length of the Map Descriptor.5
Cheetah:#22 FYI. Node=%s
is a Cybercat panel.
These messages report the type of panel that the configuration is suitable for. If
this isn’t what you expect, review the configuration against the manual and make
changes as required. Refer to section 0 for more information.5
Cheetah:#23 FYI. Node=%s
is a Cheetah panel.
5
Modify the CSV file, download to the FieldServer and restart the FieldServer for the changes to take effect.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
Cheetah:#24 Error, Node_ID
must be specified when
MIM enabled!
Specify Node ID of remote panel or remove MIM enabled setting.
Note: for storing data from multiple panels MIM enabled should be specified.
Cheetah:#25 Invalid
MIM_Enabled setting
[Yes;No], defaulting to No!
Use either Yes or No for the MIM enabled setting.
Appendix C.2. Driver Stats
Cheetah panels produce data messages for slave devices to consume. The type and frequency of the messages
depends on the Cheetah firmware revision.
The driver counts all incoming messages of interest as the PLC_READ_MSG_RECD statistic. Other legal messages
which do not contain the data this driver is interested in are discarded and are counted as the MSG_IGNORED
statistic.
The PLC_READ_MSG_RECD statistic is incremented once by each Map Descriptor which extracts data from an
incoming message. Thus, one incoming message and three associated Map Descriptors would cause the statistic
to increase by three (when viewed from the connection's point of view.)
The driver ignores messages 0x0100 from Cybercat panels. These legacy messages contain contradictory
information. If the node is configured as a Cybercat panel then the driver ignores the messages and increases the
Ignored Messages stat on the connection.
Appendix C.3. Map Descriptor Specific Errors
Some errors produced by the driver are Map Descriptor specific. They can only be seen when using the Ruidebug
program and looking at the Map Descriptor debugging screens. For more information on how to do this please
refer to the FieldServer Utilities manual.
Appendix C.4. Multiple Cheetah Panels
Some of the broadcast messages produced by the Cheetah panel are node-less. This means that these messages
do not identify the node of origin. Unfortunately, the message this driver uses to determine zone and device
alarms is a node-less message. This limits the number of Cheetah panels per port to one. (If there were more than
one the driver would not be able to determine the node of origin.)
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com
This driver has implemented cheetah command #6.0. These messages are produced by a Cheetah device
controller and are consumed by this driver. The driver has no control on the frequency of the messages and thus
cannot guarantee fresh data. In addition the protocol has no method for acknowledging messages so that in the
event of this driver having to discard a corrupt message, the message producer does not know and will not re send.
Appendix D.2. Panel Firmware Versions
The driver supports older versions of panel firmware which transmit a shorter version of the Panel Status
command. This shorter version contains only panel data whereas the newer version contains panel, zone & device
data.
Appendix D.3. Storing Panel Data
Panel data is stored in consecutive locations as described in the map below. For additional explanations on the
meaning of each data element contact FIKE directly.
FieldServer Technologies 1991 Tarob Court Milpitas, California 95035 USA Web: www.fieldserver.com