The Alarms of the dataTaker allow the data from various sources to be compared with range setpoints, and to perform actions if the data exceeds these setpoints.

The different types of data which can be tested by Alarms includes

Analog input, digital input and counter channel data

Internal channel data

Day, Date and Time of the real time clock

System Timers

Channel Variables 

System Variables

The data from these different sources can be compared against one or two setpoints, which define the alarm conditions. The four different types of comparison which can be performed are

data less than a setpoint (low alarm)

data greater than or equal to a setpoint (high alarm)

data within the range of two setpoints (in range alarm)

data outside the range of two setpoints (out of range alarm)

Note : There is no test condition for equality of data to setpoint, since in a data acquisition system such as the dataTaker equality is only a brief state if it occurs at all.

The action taken by the dataTaker in response to alarm states be to

return a message text string to the host, and display the message on the display panel

switch digital output channels, or switch the warning LEDs, beeper and backlight of the display panel

execute a command or program. This allows the dataTaker to reprogram itself to operate differently when an alarm occurs

Whenever an alarm state occurs the alarm action can be performed either immediately, or after a defined period of time has elapsed for which the alarm state remains true. This allows short term nuisance alarm states to be ignored.

Alarms can be singular, or can be linked together using AND, OR and XOR logical operators to monitor complex conditions involving more than one input channel or source of data.

The Alarms are normally used for true alarms which will annunciate out of range conditions.

However the Alarms can also be used as a programming device for controlling the operation of the dataTaker. For this reason the Alarms are also interchangeably referred to as the IFs.

Some examples of applications of the alarms include

generating alarms if data from an input channel exceeds a single setpoint or a setpoint range

 controlling an external process to a setpoint (simple control)

 generating alarms if internal data for System Variables, Channel Variables, etc. exceeds a single setpoint or a setpoint range

 generating alarms before or after specified dates and/or times, or when System Timers exceed specified elapsed times

 defining windows of time during which dataTaker operations such as channel scanning for data acquisition can operate

changing the operation of the dataTaker in response to particular conditions or events

When alarm input channels or system data is being monitored for range, this test data can be returned to the host computer for inspection. This overcomes the need for separate Data Schedules to inspect this data. However the test data returned from the alarms cannot be logged into the internal data memory or a memory card.

The alarm input channels and system channels can be considered to be scanned as a background function, in that other data acquisition functions can also be carried out whenever alarms are in operation.

Scanning of the alarm input channels is continuous by default to provide the maximum sensitivity. However scanning of the alarm input channels can be scheduled on the basis of time intervals or external events if required, in the same manner as the Triggered Schedules for data acquisition.

The dataTaker can support up to 110 simultaneous alarms, with the default being 20.

Number of Channels for Alarm Commands

When Alarms are entered into the dataTaker, the source of data to be tested is entered into an internal channel table.

The dataTaker treats all sources of data for Alarms in the same manner, irrespective of whether the source is a physical input channel or system data such as a Channel Variable, Day, Date, Time, System Timers, System Variable, etc.

If the source of data is a physical input channel, then the internal channel table contains details of the input channel to be scanned including the channel number, the type of input signal, the sensor calibration, how the resultant data is to be processed, etc.

If the source of data is system data, then the internal channel table contains all details of the type of data, location of the data, how the data is to be processed, etc.

The Alarms share this internal channel table with the Data Schedules, which also keep input channel details in the table for data acquisition (See Section III ñ Schedules ).

A maximum of 110 entries can be made into this table by the Alarms and the Data Schedules.

Following initial power up, a hardware reset or execution of a RESET command, the default allocation of the internal channel table between the Alarms and the Data Schedules is as follows

20 entries are allocated for the Alarms

90 entries are allocated for the Data Schedules

Therefore a maximum of 20 Alarms can be entered into the dataTaker by default.

However allocation of the internal channel table between the Alarms and the Data Schedules can be changed to suit particular applications.

Setting the Number of Alarms 

The allocation of entries in the internal channel table between the Alarms and the Data Schedules can be specified by the Parameter30 command (See Section III ñ Parameter Commands).

This command defines the number of entries in the internal channel table which are allocated to Alarms. The balance of the entries are allocated to the Data Schedules.

Using DeTransfer, the command for example

allocates space for 50 entries in the internal channel table for Alarms, and reduces the number of entries in the table for Data Schedules to 60.

The number of the Alarm entries in the internal channel table can be set between 0 to 110, resulting in an allocation of 110 to 0 entries to the Data Schedules.

Note  : The channel table must be re-allocated by the Parameter30 command before any Alarms or Data Schedules are entered. Attempts to re-allocate the internal channel table after either Alarms or Data Schedules have been entered will result in the error message 'E8ñParameter read/set error'.

If you are using DeLogger, then you do not need to set the number of alarms. DeLogger allows up to 60 alarms to be defined in a program, and automatically sets the Parameter30 command to the highest alarm number used in a program.

 

 

Always define alarms beginning at alarm number 1, rather than randomly using alarm numbers which will waste space in the channel table.

The internal channel table can be cleared using the CSCANS and CALARMS commands.

Alarm Keywords

The Alarms have two basic command keywords which can be used interchangeably.

The ALARM keyword can be used for those Alarms which are used in the traditional manner to test input channels or system data for out of range conditions, and perform actions to annunciate and alarm.

The IF keyword can be used for those Alarms which are used as a device to control the operation of the dataTaker, or used to control the flow of applications programs (See Section III ñ Writing Programs).

The Alarms can act in either of two modes when an alarm state occurs.

In the first mode, the Alarm performs the alarm action when the alarm state actually becomes true. The alarm state must then become false, and true again before the alarm action is performed again. This mode of the Alarms is specified by the two keywords ALARM and IF.

In the second mode, the Alarm performs the alarm action repeatedly while the alarm state is true. The repetition of the alarm action is determined by the Alarm Schedule (see below). This mode of the Alarms is specified by the two keywords ALARMR and IFR.

Entering Alarms

There are four general command formats for Alarms, allowing input channels or system data to be tested in four different ways as follows

input channel or system data greater than or equal to a setpoint

ALARMn(testdata>setpoint1/delay)action
ALARMRn(testdata>setpoint1/delay)action

or

IFn(testdata>setpoint1/delay)action
IFRn(testdata>setpoint1/delay)action

input channel or system data less than a setpoint

ALARMn(testdata<setpoint1/delay)action
ALARMRn(testdata<setpoint1/delay)action

or

IFn(testdata<setpoint1/delay)action
IFRn(testdata<setpoint1/delay)action

input channel or system data outside the range of two setpoints

ALARMn(testdata<>setpoint1,setpoint2/delay)action
ALARMRn(testdata<>setpoint1,setpoint2/delay)action

or

IFn(testdata<>setpoint1,setpoint2/delay)action
IFRn(testdata<>setpoint1,setpoint2/delay)action

input channel or system data between two setpoints

ALARMn(testdata><setpoint1,setpoint2/delay)action
ALARMRn(testdata><setpoint1,setpoint2/delay)action

or

IFn(testdata><setpoint1,setpoint2/delay)action
IFRn(testdata><setpoint1,setpoint2/delay)action

where

ALARM         )
ALARMR       )  ) are the Alarm
IF                )  ) identifiers
IFR               ))
n                 is the alarm number
testdata        is the input channel or system data that is tested for alarm state
>                 operator for testdata greater or equal to setpoint
<                 operator for testdata less than setpoint
<>               operator for testdata outside setpoints
><               operator for testdata between setpoints
setpoint1       alarm setpoint1
setpoint2       alarm setpoint2 ( for <> and >< only)
/delay          is optional time period the alarm must be true before alarm state is changed
action           specifies action(s) if alarm is true

Each of these elements of the Alarms are discussed in detail in the following sections.

The Alarm Number

Each Alarm has an alarm number in the range of 1 to the number of alarms defined by Parameter30. The alarm number has several functions

identifies the alarms when the input channel or system data being tested is returned to the host

defines the sequencing of alarms when alarms are combined by logical operators AND, OR, XOR

identifies individual alarms to be halted and resumed

 identifies individual alarms to be cleared from the internal channel table

The number of alarms which can be entered in the dataTaker can be increased or decreased by the Parameter30 command (see Setting the Number of Alarms above). The default is for 20 alarms which are numbered 1 to 20.

The Alarm Test Data

All of the types of data produced by the dataTaker can be tested in the Alarms. The different data types fall into two main categories - input channel data, and internal or system data.

The input channels that can be monitored by Alarms include all of the dataTaker physical input channels

differential and single ended analog input channels

digital logic state and byte input channels

counter input channels

The internal system data sources that can be monitored by Alarms includes

internal reference channels and the battery status channels

the Date, Day and Time of the real time clock

the System Timers

the System Variables

the Channel Variables

The only internal data source that cannot be tested by the Alarm is the Text String channel.

The input channels to be tested are specified in the same manner as input channels for the Data Schedules. However only a single input channel can be specified, and channel sequences are not permitted.

Most of the channel options can be used for input channels in Alarms, including

channel configuration, gain and excitation

scale factors, Polynomials, Spans and Intrinsic Functions 

assignment to Channel Variables

data formatting and output options

bar graph display

Channel options that cannot be used for input channels in Alarms include

the data manipulation functions DF, RC, RS, and IB

the statistical AVE, SD, MX, DMX, TMX, MN, DMN, TMN and INT

the histogram function

NL option to not log data

Alarms for several types of input are shown below, and can be entered using DeTransfer 

These Alarms respectively have the following actions

ALARM1         - returns the message to the host each time the voltage measured on
  analog input channel 1 exceeds 1000mV

ALARMR2       - returns the alarm message to the host continuously while the single ended
  voltage measured on analog input channel 1 remains less than 200mV

IF4                - returns the alarm message to the host once at midday

ALARM10       - returns the alarm message to the host each time that the value from the
  current loop sensor falls below 100 units, or exceeds 500 units

IFR15             - returns the alarm message to the host continuously while the value of
  Channel Variable number 3 is outside of the range of 47.5 to 82.7

Using DeLogger, Alarms are programmed in the Alarms tab of the Program Builder. The alarm input channel is selected in the same manner as selecting a data acquisition channel, however the channel icon has an Alarm icon where the alarm tests and actions are defined. Right click on the Alarm icon and select PropertiesÖ Enter the details for the alarm test and actions, as shown in the example below.

 

 

 

Reference Channels

When input channels tested by Alarms require reference channels, such as for voltage excited bridge inputs, or thermocouple inputs from an external isothermal block, these reference channels are declared in dummy Alarms.

These dummy Alarms for the reference channels must precede the actual Alarm whose input channel uses the references.

Using DeTransfer, a reference channel is declared in a dummy Alarm as follows

which defines the bridge reference channel for a voltage powered bridge input (See also Section II ñ Measuring Bridges).

The reference channels for thermocouple inputs from an external isothermal block are declared in two dummy Alarms as follows

which defines the reference junction temperature channel and the zero voltage channel (See Section II ñ Measuring Temperature with Thermocouples).

Using DeLogger, the reference channel is first declared in a similar manner by specifying the input channel and setting the reference option via the Channel Options : ReferenceÖ dialog. Then set the Alarm number in the Alarms dialog, and set a test that will never be true.

If reference channels are not declared, then the appropriate default internal references will be used.

Difference and Statistical Data in Alarms

If alarms are required for input channels which have difference data manipulation (DF, RC. RS, IB channel options) or statistical data manipulation (AV, SD, MN, MX, INT channel options), then the appropriate data must first be obtained in a Data Schedule and assigned to a Channel Variable. The Channel Variable can then be tested in an Alarm.

The Data Schedule must execute at the same intervals as the Alarm Schedule. This is achieved by setting the Data Schedule and the Alarm Schedule (see below) for the same trigger.

Alarms are executed after the Data Schedules in each scan, and so data passed forward in this manner is appropriate to the current scan of the alarm.

Using DeTransfer, the program for example

measures rate of temperature rise sensed by a type T thermocouple in Schedule A, and assigns this to the Channel Variable. The Channel Variable is then tested in the Alarm. The Data Schedule (RA5S) and the Alarm Schedule (RZ5S) are triggering at the same intervals.

The same approach can be used to program this type of Alarm in DeLogger.

The Alarm Comparison Operators

The comparison operator defines the way in which the Alarm compares the test data with the setpoint(s).

The alarm comparison is specified by one of the relational operators 

  >      - greater than or equal to setpoint (high alarm)

  <      - less than setpoint (low alarm)

  <>    - less than setpoint1 OR greater than or equal to setpoint2 (high low alarm)

  ><    - greater than or equal to setpoint1 AND less than setpoint2 (in range alarm)

Only one alarm comparison operator can be specified in each Alarm.

The number of setpoints required depends on the comparison, with one setpoint required for simple alarms, and two setpoints required for range alarms.

Using DeTransfer, Alarm comparison operators are programmed as shown in the examples

The true alarm states for the various relational operators occur as follows

  >      - the test data increases to equal to or greater than the setpoint (high alarm)

  <      - the test data decreases to less than the setpoint (low alarm)

  <>    - the test data decreases to less than the first setpoint, or increases to equal to or
           greater than the second setpoint (high low alarm)

  ><    - the test data increases from a low value to equal to or greater than the first setpoint, or
           decreases from a high value to less than the second setpoint (in range alarm)

The alarm actions are performed when the alarm state first becomes true (ALARM and IF commands) or remains true (ALARMR and IFR commands).

Using DeLogger, the alarm comparison operator and setpoint(s) are set in the Alarms dialog.

 

 

The Alarm Setpoints

The Alarm setpoints define the limits against which the test data is compared to determine the alarm state. The alarm setpoints can be specified as numeric constants, Channel Variables, Date or Time as follows

as numeric constants in floating point format, for example 127.64, -0.2245, 1000, etc.

as numeric constants in exponential format, for example 1.276e3, -2.245e-1, 1e4, etc.

as Channel Variables in the format nCV

as Date in the date format defined by the Parameter31 command

as Time in the time format defined by the Parameter39 and Parameter40 commands

The numeric constant and Channel Variable setpoints are used for all comparisons except Date and Time. The specification of date and time setpoints are discussed below.

Using DeTransfer, Alarm setpoints are programmed as shown in the examples

Setpoint1 must always be defined, while setpoint2 is only defined where test data is monitored for in range (><) or out of range (<>) conditions.

DeLogger only allows the setpoints to be programmed as floating point numeric constants.

Using Channel Variables as Setpoints

The use of Channel Variables as setpoints allows the setpoints to be dynamically altered during the course of the application, as Channel Variables take on different values. This feature eliminates the need to re-enter the whole Alarm if varying setpoints are required.

The Channel Variables are assigned new values within Data Schedules, as a result of calculations or special manipulation of the input channel data. The Data Schedule must execute at the same intervals as the Alarm Schedule.

Alarms are executed after the Data Schedules in each scan, and so data passed forward in this manner is appropriate to the current scan of the alarm.

Using DeTransfer, Alarm setpoints are programmed as Channel Variables as shown in the examples

Note that Channel Variables can also be the Alarm test data. For example the following Alarm is legitimate

DeLogger does not support setpoints being programmed as Channel Variables.

Date and Time Setpoints

When the Date is tested in an alarm, setpoints must be specified in the current date format as defined by the Parameter31 command (See Section III ñ The Real Time Clock). Date setpoints are appropriate for the dd/mm/yy and mm/dd/yy date formats only. If the Date format is Day Number, then the setpoints are specified as a numeric constant.

Similarly when the Time is tested in an alarm, setpoints must be specified in the current time format as defined by the Parameter39 and Parameter40 commands (See Section III ñ The Real Time Clock). Time setpoints are appropriate for the hh:mm:ss time format only. If the Time format is decimal hours or seconds, then setpoints are specified as a numeric constant.

Using DeTransfer, date and time setpoints are programmed as shown in the examples

Setpoint1 must always be defined, while setpoint2 must only be defined where input channels are monitored for in range (><) or out of range (<>) conditions.

DeLogger does not support setpoints being programmed as date or time.

Setpoints for Digital Input Channels

When digital input channels are tested in Alarms, the setpoints could reasonably be expected to be specified as 0 and 1.

However because of the possibility of occasional very small errors in the floating point comparisons (a common shortcoming of floating point routines by 8 bit microprocessors), it is recommended that all digital setpoints be specified as 0.5 as follows

The Alarm Delay Period

The alarm delay period is optional, and decreases the sensitivity of alarms in both transitions as follows

the alarm comparison must be true for the delay period before the alarm state becomes true and the alarm action performed.

the alarm comparison must be false for the delay period before the alarm state becomes false.

The alarm delay period therefore allows any short term alarms or nuisance alarms to be ignored.

If a delay period is not specified for the alarm, then the alarm state will change immediately the alarm comparison becomes true or becomes false. If during the delay period the alarm state changes again, then the delay timer resets and no action is taken.

The delay period is specified by a leading / character followed by a duration in the range of 1 to 255 units of time. The units of time are specified as S for seconds, M for minutes, H for hours or D for days.

Using DeTransfer, Alarm delays are programmed as shown in the examples

The delay period cannot be specified as combinations of the time units. For example a delay period of one hour and thirty minutes cannot be specified as 1H30M, but must be specified as 90M.

Using DeLogger, the alarm delay is defined in the Delay Period box of the Alarms dialog. Select the units of time, and enter the Delay Value in the input field.

 

 

The Alarm Actions

The Alarm action defines the action to be taken when the alarm comparison is true. There are several different actions which can be performed

return an alarm message to the host computer or a printer

display an alarm message on a display panel (if fitted)

switch one or two digital output channels

switch a warning LED, beeper or LCD backlight on the display panel (if fitted)

execute dataTaker commands

The action is optional, but if not defined then no action can be taken when an alarm occurs. The different alarm actions which can be performed are described in the following sections.

Returning a Message to the Host Computer or Printer

When Alarms become true, they can return an alarm message to the host computer or printer, and display a message on the loggerís Display Panel if fitted.

Many of the examples used in the preceding sections have alarm messages defined as part of the Alarm declarations.

The length of the Alarm message is limited to 250 characters for each Alarm, and to a total of 4000 characters for all Alarm messages in the program.

When the Alarm message storage area is full, attempts to enter additional messages will result in the error message 'E52-alarm text memory full'.

The loggerís Display Panel will only display the first 16 characters of an Alarm message.

The Alarm messages are returned differently for the two operating modes of the Alarms

ALARM and IF ñ the message is returned or displayed when the Alarm first becomes true. If the Alarm subsequently clears and becomes true again, then the message is returned or displayed again.

ALARMR and IFR ñ the message is repeatedly returned and displayed while the alarm remains true.

An Alarm message is defined simply as a text string enclosed by quotes, which follows the alarm condition as follows

ALARMn(condition)"Message string"
ALARMRn(condition)" Message string "
IFn(condition)" Message string "
IFRn(condition)" Message string "

where

ALARM                  )
ALARMR                )    are the Alarm
IF                          )  identifiers
IFR                        )
n                          is the alarm number
(condition)              is the alarm comparison
"Message string"      is the alarm message

The Alarm message text string can contain control characters for ringing terminal bells, printer formatting, etc. Control characters are entered in the format ^J (LF), ^M (CR), ^G (Bell), ^[ (ESC), etc. While two characters are required to enter the control characters, only one character is stored internally.

When an Alarm message is sent to the host, a CR/LF is not appended to the message as might be expected. If a CR/LF sequence is required to terminate the messages, then these characters must be included in the Alarm message as the control characters (^M^J) .

Using DeTransfer, Alarm messages are programmed as shown in the examples

Using DeLogger, the alarm message is defined in the Action text box of the Alarms dialog. The alarms message is entered without ì  î in the input field.

 

Alarm Message Substitution Characters

The Alarm message can include a number of substitution characters to pass information about the alarm to the host computer and Display Panel (if fitted). These substitution characters and their function are

!     ñ substitute with the dataTaker address and alarm number in the alarm message. In the
case of combined alarms the logger addressñalarm number for the last alarm is given.

?    – substitute with the current value for the alarm test data in the alarm message returned to the
host. In the case of combined alarms the current value for the last alarm is given.

#    ñ substitute with the current day number or date in the alarm message. The day or date format defined by the Parameter31 command is used.

@   ñ substitute with the current time in the alarm message. The time format defined by the Parameter39 and Parameter40 commands is used.

The following examples illustrate use of substitution characters in the Alarm messages to pass variable information about the alarm to the host. These substitution characters can be used for defining Alarm messages in both DeTransfer and DeLogger.

In this case the dataTaker 1 will return the message on alarm

Alarm 1-4 High Temp 11:33:00

indicating that alarm number 4 is true on dataTaker 1 at 11:33:00.

In this case the dataTaker will return the message

Low Press 85.67 psi

indicating the present pressure level which has been low for 30 seconds.

Disabling the Return of Alarm Messages

By default the Alarm messages are returned to the host computer when the Alarm changes from false to true. However the return of the Alarm messages can be globally controlled by the Alarm Messages Switch as follows

/Z  Enable return of alarm message (default)
/z  Disable return of alarm message

The Alarm Messages Switch defaults to /Z whenever the dataTaker is initially powered up, hardware reset or executes a RESET command.

The Alarm Messages Switch has a global effect, and when used it will enable or disable returns of all Alarm messages.

The return of individual Alarm messages to the host can also be disabled by including a NR (No Return) channel option for the input channel or internal channel being tested. However the message can still be displayed on the Display Panel if fitted.

Using DeTransfer, the following alarm for example

will not return the alarm message to the host when the alarm state becomes true. However the alarm message can still be displayed. This channel option can also be used if you are programming from DeLogger.

Displaying Alarms

dataTakers fitted with a Display Panel can display Alarm states and Alarm messages (See Section III ñ Keypad and Display).

A maximum of 16 characters can be displayed on the top line of the LCD display of the Display Panel.

When Alarms without an Alarm message are entered, then default messages are displayed. For example the Alarm

will be displayed as follows when the temperature is below 100°C and therefore not in alarm

and will be displayed as follows when the temperature is above 100°C and therefore in alarm

When Alarms which have an Alarm message are entered, then the message is displayed when the Alarm is true. For example the Alarm

will be displayed as follows when the temperature is below 100°C and therefore not in alarm

and will be displayed as follows when the temperature is above 100°C and therefore in alarm

The optional channel name for the input channel or internal channel being tested can be used to display a message when the Alarm is not in alarm. When the Alarm is false the optional channel name is displayed, and when Alarm is true the Alarm message is displayed.

For example the Alarm

will be displayed as follows when the temperature is below 100°C and therefore not ion alarm

and will be displayed as follows when the temperature is above 100°C and therefore in alarm

The display of Alarm messages on the Display Panel can be globally controlled by the Alarm Display Switch as follows

/A     Enable display of alarm message
/a      Disable display of alarm message (default)

The Alarm Display Switch defaults to /a whenever the dataTaker is initially powered up, hardware reset or executes a RESET command.

The Alarm Display Switch must be enabled (/A) before the Alarms are entered into the logger, for the display of Alarm messages to be enabled. The Alarm messages will then be in the scroll list of the display (See Section III ñ Keypad and Display).

However if Alarms are entered into the logger while the Alarm Display Switch is disabled (/a), then the individual Alarms can be enabled into the display scroll list using the List Enable key of the keypad (See Section III ñ Keypad and Display).

The display of individual Alarm messages can also be disabled by the ND (No Display) channel option for the input channel or internal channel being tested.

For example the Alarm

will not display the Alarm message onto the Display Panel when the alarm becomes true. However the Alarm message will still be returned to the host. This channel option can also be used if you are programming from DeLogger.

Executing dataTaker Commands from an Alarm

The Alarms can execute dataTaker commands or a dataTaker program by loading the command(s) into the internal command buffer whenever an Alarm becomes true. The command(s) is executed as if entered directly by a host computer, and any of the dataTaker commands can be issued by this function.

This function can be used to command the dataTaker in any way on a true Alarm, including changing a scanning rate, enabling the logging of data, assigning new constants to Channel Variables, switching digital output channels, or completely reprogramming the logger.

The commands are executed differently for the two modes of the Alarms as follows

ALARM and IF         ñ the commands are executed once when the Alarm becomes true. If the
  Alarm clears and becomes true again, the commands are executed again.

ALARMR and IFR      ñ the commands are repeatedly executed while the Alarm remains true.

The dataTaker commands for a true Alarm are declared in a text string similar to the Alarm message.

 

 

 

The commands are enclosed in [square brackets] as follows

ALARMn(condition)"[commands]"
ALARMRn(condition)"[commands]"
IFn(condition)"[commands]"
IFRn(condition)"[commands]"

where

ALARM                  )
ALARMR                )  are the Alarm
IF                          )  identifiers
IFR                        )
n                          is the alarm number
(condition)              is the alarm comparison
"[commands]"         are the dataTaker commands

Only one set of [commands] is permitted in the text string, and so all commands associated with the Alarm action must be declared together.

When commands are entered into the command buffer by the Alarms, a CR/LF is appended to the commands to ensure that the command string is terminated correctly and will be executed. Therefore these line control characters do not need to be included in the command string.

The following examples can all be used in DeTransfer and DeLogger, and  illustrate the use of dataTaker commands as actions to Alarms

The first Alarm turns digital output channel 1 ON when the temperature exceeds 100°C. When the temperature falls below 100°C, the digital output channel is turned OFF by the second Alarm.

The dataTaker is programmed to log the voltages read for analog input channels 1 through 10 after 09:00:00 am.

The Alarm will repeatedly Poll trigger the Poll Schedule (RX) at the Alarm Schedule rate while the Channel Variable (assigned within another Data Schedule) is greater than 125.5 units.

The Alarm text string may contain both a message and dataTaker commands, as the following example illustrates

Pump pressure is being monitored on analog channel 2. If this exceeds 15 PSI a warning is sent to the host, and the logger is commanded to begin to acquire and log data on the high pressure.

This could also be done by using the Alarm to start a separate Data Schedule when in alarm as follows

The commands in Alarm actions are stored in the same 4000 character block of memory as the Alarm messages. When this storage area is full, attempts to enter additional Alarm text will result in the error message 'E52-alarm text memory full'.

Cautions When Commanding the dataTaker from an Alarm

There is no limit to the type or number of commands that can be specified in the action part of an Alarm. However there are several precautions which should be considered when designing commands for Alarm actions, as follows

new Alarm should not be added, or existing Alarms changed, in Alarm actions

where the commands in an Alarm action change the status of the dataTaker, the original status of the logger is not resumed when the Alarm recovers. Instead a reversing Alarm is needed to return the logger to the original status.

when both an Alarm message and commands are included in an Alarm action, the message is returned to the host before the commands are executed. This applies irrespective of the order in which the two are declared in the text string.

Switching Outputs from an Alarm

The Alarms can switch one or two of the output channels when in alarm. An output channel can be a digital output channel or a warning channel on the Display Panel (if fitted). The switched digital outputs can be used to control external devices such as a bell, light, solenoid, motor, etc. or to interface the logger to Programmable Logic Controllers, TTL/CMOS logic circuits, etc.

The warning channels on the Display Panel include the LEDs, the LCD display backlight, and the beeper.

The Alarm manages the outputs in a toggling manner, in that the output is switched ON when the Alarm is true and is switched OFF when the Alarm is false.

The output channels are set according to the Alarm comparison each time the alarm is tested. This holds the output ON while the Alarm remains true, and holds the output OFF while the Alarm remains false.

This action is the same for both the ALARM / IF and the ALARMR / IFR modes.

The output channels to be switched are declared following the alarm condition in the general formats

ALARMn(condition)FirstOutput,SecondOutput
ALARMRn(condition)FirstOutput,SecondOutput
IFn(condition)FirstOutput,SecondOutput
IFRn(condition)FirstOutput,SecondOutput

where

ALARM            )
ALARMR          ÿ)  are the Alarm
IF                   )  identifiers
IFR                  )
n                    is the alarm number
(condition)        is the alarm comparison
FirstOutput        first output channel to be switched       )  Any combination of a DSO
SecondOutput   second output channel to be switched  )  or WARN output channels

Using DeTransfer, the output channels for Alarms actions are defined in the command for example

where the Alarm will turn digital output channels 1 and 2 ON when the temperature exceeds 100°C, and turns the digital output channels OFF when the temperature is below 100°C.

where the Alarm will turn digital output channel 1 ON and warn channel 2 ON when the voltage is less than 100 mV or greater than 500 mV, and turns the output channels OFF when the voltage is between 100 mV and 500 mV.

Using DeLogger, the output channels for Alarm actions are defined in the Alarms dialog. Click on the Channels button in the Output Channels panel, then select the output channel(s) in the Output Channels dialog as follows

 

 

Cautions When Switching Outputs from an Alarm

The Alarms can be scanned up to 20 times a second at the maximum scan rate. The digital output channel is switched according to the result of the Alarm condition after each scan.

This procedure holds the output channel ON while the Alarm state remains true, and holds the output channel OFF while the Alarm state remains false.

As a general rule two or more Alarms should not manage the same output channel directly, unless the strategy is carefully planned.

Managing the same output directly from two Alarms is illustrated in the following example

where the Alarms are processed sequentially, and will set the output ON and OFF on each scanning pass depending on the state of the individual Alarms. One Alarm may be true and attempting to hold the output ON, while the other Alarm may be false and attempting to hold the output OFF.

However where the same output must be managed by two of more Alarms, then the following approach which manages the output by setting it by Alarm action commands, is recommended

Although this approach requires two additional Alarms, switching of the output channel only occurs when the alarm actually becomes true or false, and not while the Alarm remains true or false. This therefore produces a more desirable action of the output channel.

Combining Alarm Actions

These various Alarm actions can be combined to provide greater function to Alarms and more power to Alarm processing. Direct management of output channels, Alarm message strings to be returned to the host and commands for the dataTaker can all be declared in the same Alarm.

Using DeTransfer, this can be done as follows

The Alarm produces the following actions when true

ring a buzzer connected to digital output channel 4 to locally indicate the error condition

send the warning message 'Hi Freq' to the host to indicate that there is an error condition

command the dataTaker to begin logging data of the over range frequency.

The management of the digital output channel could also have been carried out using dataTaker commands in the Alarm action as follows

where the digital output is switched by direct commands. Note that two Alarms are now required, one to switch the output ON when a high alarm occurs, and the other to switch the alarm OFF when there is no alarm.

Various combinations of Alarm actions can also be created using DeLogger, in the Alarms dialog as illustrated for the various examples above.

Whenever a directly managed output channel, an alarm message for the host, and commands for the dataTaker are all included in an Alarm action, the actions are carried out in the following sequence

firstly the output channels are switched

secondly the message for the host computer is transmitted

thirdly the dataTaker commands are executed

This sequence applies irrespective of the order in which different Alarm actions are declared in the original Alarms.

The Alarm Logical Operators

Alarm logical operators allow a number of Alarms to be combined together into a single Alarm, to provide greater flexibility to Alarms and more powerful Alarm processing.

The logical operators supported are AND, OR and XOR, and are declared following the Alarm condition in the place of other Alarm actions.

The general format for using logical operators is

ALARMx(condition)logic-operator
ALARMy(condition)logic-operator
ALARMz(condition)actions

where

ALARM                  is the Alarm identifier
x, y, z                   are sequential alarm numbers
(condition)              are the alarm comparisons
logic-operator          is AND, OR or XOR logical operator
actions                   is the combined Alarm action

The Alarm actions can only be declared for the final Alarm in the sequential group, and are carried out only if the combined group of Alarms becomes logically true.

Note :  The logical operators bind the Alarm to the next sequential Alarm number defined, which may not necessarily be the next entered Alarm.

The sequential group of Alarms is evaluated logically from the lowest Alarm number to the highest Alarm number. If there are missing Alarm numbers in the sequence, then this will not be a problem unless these Alarms are defined elsewhere. If these Alarms are defined elsewhere, then they will be included in the combined alarm.

The following group of alarms

ALARM1  AND  ALARM2  OR  ALARM3  XOR  ALARM4

are evaluated logically in sequential order

( ( ( ALARM1  AND  ALARM2 )  OR  ALARM3 )  XOR  ALARM4 )

Using DeTransfer, logical operators to combine Alarms are used as follows

In this case the message 'High Temps' is returned to the host if the temperatures monitored on channel 4 AND channel 5 both exceed 55°C.

These alarms could also be entered in a single line for greater clarity. However a space separator must be included between successive alarms as follows

Alternatively for a similar group of alarms

the combined alarm is true if any of the three temperature channels is greater than or equal to 55°C.

Where a delay is required for a combined Alarm, then the delay must be specified within the last Alarm of the group as follows

Delays specified for any other alarms in the group are ignored.

Combined Alarms can also be programmed using DeLogger. The logical operator is selected from the list in the Combine panel of the Alarms dialog. DeLogger does not specifically prevent you defining other actions with logical operators, so be careful not to do this.

 

 

Caution

The logical operator binds the Alarm for which it is declared to the next sequential Alarm number defined. The next sequential Alarm does not have to be the next entered alarm.

If the following Alarms are entered in the order

the combined alarm would be processed as

The Alarm Schedule

The Alarms are processed at intervals of time determined by the Alarm Schedule. Processing of Alarms involves scanning an input channel or internal channel, or reading a Channel Variable, System Variable, System Timer, or the real time clock.

By default the Alarms Schedule is running continuously, and Alarms are processed at the maximum rate possible. This provides fastest response time for Alarms.

However the Alarms Schedule can also be triggered at defined intervals, in the same way that the Data Schedules for data acquisition can be triggered at defined intervals. Running the Alarms Schedule slower can in some cases be an advantage.

The Alarm Schedule trigger can be specified in terms of time, digital event or counter event.

The general format for the Alarm schedule trigger as time is

RZ                          ñ continuous        (Default)
RZnS                      ñ time in seconds
RZnM                     ñ time in minutes
RZnH                      ñ time in hours
RZnD                      ñ time in days
where n is any integer in the range of 1 to 65535

The general format for the Alarm Schedule trigger as digital events is

RZnE                       ñ trigger on both transitions
RZn+E                     ñ trigger on positive transitions
RZnñE                     ñ trigger on negative transitions
where n is any digital input channel, or a sequence of digital input channels

The general format for the Alarm Schedule trigger as counter events is

RZnC(count)             ñ trigger on count from a low speed counter
RZnHSC                  ñ trigger on a high speed counter pulse
where n is any counter channel, and count is the terminal count on which to trigger

The Alarm Schedule can also include the Trigger While Condition for conditional triggering (See Section III ñ Schedules Triggered While Condition).

The Alarm Schedule can be entered into the dataTaker at any time, and does not have to be entered in association with actual Alarm commands.

Only one Alarm Schedule interval can be defined at any time, and when an Alarm Schedule is entered any existing Alarm Schedule is replaced.

The Alarm Schedule can also be changed at any time from time based to event based, etc.

Using DeTransfer, the Alarm Schedule is entered for example

Using DeLogger, the Alarm Schedule is programmed in the Program Builder under the Alarms tab. Right click the Alarm button at the top of the work area, and select Set Schedule RateÖ or Set Schedule TriggerÖ as required.

Enter the trigger details in the following dialog in the same way as described for the Data Schedules.

 

 

 

 

If an Alarm Schedule is not defined, then the Alarms are processed continuously at the maximum rate.

Halting and Resuming Alarm Schedule

The processing of all Alarms can be globally halted and resumed, and the processing of individual Alarms can also be halted and resumed at any time.

Halting and Resuming All Alarms 

The sampling and processing of all Alarms can be halted and resumed by the global Halt and Go commands, and the Alarm Halt and Go commands

H             Halt scanning of all data acquisition channels and Alarms
G             Resume scanning of all data acquisition channels and Alarms
HZ           Halt processing of all Alarms
GZ           Resume processing of all Alarms

When the dataTaker is initially powered up, is hardware reset or executes a RESET command, the Alarm Schedule defaults to HZ. When a new Alarm is entered, the Alarm Schedule is enabled (GZ) at the time of entry. This allows the Alarms to be processed at the next Alarm Schedule interval.

Note :  Alarm processing is also controlled by the global Halt and Go commands for data acquisition scanning. If the Halt or Go command is entered to halt or resume data acquisition, this will also halt or resume all alarms processing.

Halting and Resuming Individual Alarms

The sampling and processing of individual Alarms can be halted and resumed by the commands

HZn            Halt processing of an individual alarm
GZn           Resume processing of an individual alarm
where n is the alarm number

If an undefined alarm number is suspended by the command HZn, or resumed by the command GZn, then the command has no effect.

When a CALARMS command is executed (See Section III ñ Clearing Alarms from the Channel Table) all Alarm information is erased from the alarms section of the internal channel table.

Preventing Alarm Schedules from Waking the dataTaker

When Alarms are being processed or data acquisition channels are being scanned at intervals of less than 2 seconds, then the dataTaker will not automatically enter the low power mode or sleep mode.

Conversely whenever Alarms are being processed or data acquisition channels are being scanned at an interval of greater than 2 seconds, then the logger will sleep between scans if other functions are not keeping it awake.

The dataTaker can be programmed to ignore Alarm Schedule triggers or Data Schedule triggers, and to sleep and wake according to specified schedules only.

Where used for Alarms, the effect of this is that the Alarms are only processed whenever the dataTaker is awake to read data acquisition channels, even though the Alarm Schedule interval may be more frequent than the Data Schedule intervals.

The schedules which can wake then dataTaker are defined by setting a bit mask using the Parameter20 command as follows

 

 

Figure 128 ñ Parameter20 Bit Map

 

Whenever the dataTaker is initially powered up, is hardware reset or executes a RESET command, Parameter20 defaults to 0 which allows all schedules will wake the logger when they become due.

The use of the Parameter20 command is illustrated by the example

where the Alarm Schedule is triggered every second, and the data acquisition schedule is triggered every 30 minutes.

With Parameter20=1, the dataTaker sleeps and wakes according to the data acquisition interval of Schedule A, and only processes the Alarm on a 1 second interval while awake to read the data acquisition channels.

Returning Data From Alarm Input Channels

The most recently read value of the Alarm test data can be returned to the host computer by the Alarm Query commands

?n               Returns the current data for a single alarm
?ALL            Returns the current data for all alarms

where

?                 is the Alarm Query identifier
n                 is an alarm number
ALL              specifies all alarms

The format of the data returned to the host computer by the Alarm Query command is similar to the format of the data returned by the Data Schedules.

The only difference in data format for data is returned by the Alarm Query command is that the alarm number of the alarm testing the input data is returned with each item of data rather than the channel number of the input channel or internal data source.

The format of the data returned by the Alarm Query command is illustrated in the following example

will return data in the format

3  1550.8 mV

The returned data can be formatted by the Switch commands /U, /u, /N, /n, /C and /c, and the Parameter22 and Parameter24 commands, in the same manner as data returned from the Data Schedules (See Section III ñ Format of Returned Data).

If an undefined Alarm or a halted Alarm are queried by the Alarm Query command, then the command is ignored and no data is returned.

Data returned by the Alarm Query commands cannot be logged to internal memory or memory cards.

Assuming that the following Alarms have been entered in the dataTaker, and are currently being processed

then the Alarm Query commands for these alarms will produce the following responses

will return the current value for the thermocouple as follows

A5  115.35 Deg C

will return the current values for all input channels as follows

A1  10:20:33
A2  10:20:33
A5  115.35 Deg C

The Alarm Query command returns the most recent value of the Alarm test data. The command does not invoke a new reading of the Alarm input.

The Alarm Query command is not directly supported by DeLogger, however can be sent from the lower Entry Screen of the Text View if needed.

Checking the Alarms

The Alarms can be checked at any time by the STATUS command.

The general STATUS command lists the number of Alarms currently defined as part of the general report, and the STATUS3 command lists the actual definitions (except Channel Options) of the Alarms.

For example, using DeTransfer the command

produces a general status report to the host

dataTaker 0 Version 7.00
A B C,none Scan Schedules Active, Halted
3,0 Alarms Active,Halted
3 Polynomial/Spans Defined
Logging is OFF
166530 Internal Data Points Free,Stored
0,0 Card Data Points Free,Stored
4090,0 Program Characters Free,Stored
/a/C/d/E/f/h/J/K/l/M/N/o/Q/R/S/t/U/v/w/x/y/Z

and the command

 

 

 

 

produces a detailed report of the Alarms similar to

3,0 Alarms Active,Halted
RZ2S
ALARM3(1V>1000.00)"Volt Over Range^M^J"
ALARM4(5TT<>100,105/5S)3DSO"Boiler^M^J"
ALARM22(1C><256,512)"[RA1S 1C]"

Individual Alarms which have been halted by the HZn command are reported with the Alarm keyword in lower case characters as follows

alarm4(5TT<>100,105/5S)3DSO"Boiler^M^J"

and are reported in the normal manner when resumed by the GZn command.

Using DeLogger, the number of Alarms active and halted can be checked by the dataTaker : Status option from the main menu bar, or the Status button on the main toolbar. Neither of these however will list the actual Alarms.

 

 

Clearing Alarms from the Internal Channel Table

When Alarms are entered into the dataTaker, the Alarm input channels are entered into an internal channel table. The internal channel table is shared with the Data Schedules for data acquisition (See Section III ñ Schedules).

Whenever the dataTaker is initially powered up or executes a RESET command, the internal channel table is initialised to 20 entries for Alarms.

The allocation of entries in the channel table for Alarms can be either increased or decreased by the Parameter30 command. However if there are any entries in the alarm or data acquisition sections of the channel table, the Parameter30 command cannot be used until the internal channel table is cleared.

The section of the internal channel table which is allocated to the Alarms is cleared from DeTransfer by the command

The section of the internal channel table allocated to Data Schedules is cleared by the CSCANS command, which must also be used before channel table allocation can be altered by Parameter30.

Individual Alarms can be cleared from the internal channel table by the command

where n is the number of the individual alarm to clear. The alarm number must be in the range of 1 to the setting of Parameter30.

If an Alarm is entered with the same Alarm number as that of an already entered Alarm, then the new Alarm will replace the original Alarm. This can be used to interactively redefine Alarm function as an application progresses.

Using Alarms for Controlling

The Alarms can be used for simple 'bang bang' control functions, which provide switching for an actuator at the alarm setpoint. The dataTaker does not support any PID control functions.

The following examples illustrate the use of Alarms as simple controllers

where the thermocouple is monitoring the temperature of a water bath, and digital output channel 1 is controlling a water heater. If the temperature falls below 50.0°C the heater is switched on, and when the water is heated to 50.0°C the heater is switched off.

This simple controller has no hysteresis characteristic and so will tend to 'hunt or chatter' around the setpoint, particularly if there is little inertia in the controlled system.

A bang bang system will always hunt around the setpoint. If hunting is too rapid, the Alarm can be slowed by a delay for example

which will delay switching of the heater when the temperature falls below the setpoint. However this will cause greater excursions from the setpoint.

Hysteresis can be obtained using two Alarms as follows

which provides a 1°C deadband.

Other Applications of Alarms

The Alarms can be used for a variety of purposes other than for monitoring and acting on specific alarm conditions. Some more common applications are illustrated below, but there are many other applications which will become self evident when need dictates.

1. Read input channels and log the data a window of time each day. Consider the program

In this case a Data Schedule is to log the data for ten thermocouple inputs, and the Schedule is immediately halted. Two Alarms are defined where Alarm 1 starts the data logging at 6:00:00, and Alarm 2 halts the data logging at 15:00:00.

 

2. Log data from the input channels only if the data is outside an acceptable range. Consider the program

In this case Schedule A is reading a voltage input, and data logging is initially disabled. Two Alarms are defined where Alarm 1 enables data logging if the measured voltage is less than 2 volts, and Alarm 2 disables data logging if the measured voltage is greater than 2 volts.

 

3. Read a group of channels for a period of time, then read a second group for a period of time. Consider the program

Two Data Schedules scan different groups of inputs, and both are halted at program entry. Four Alarms are defined which have the following effects

Alarm 1 commands Schedule A to run (GA) at 10:00:00

Alarm 2 commands Schedule A to halt (HA) at 12:00:00

Alarm 3 commands Schedule B to run (GB) at 16:00:00

Alarm 4 commands Schedule B to halt (HB) at 18:00:00

 

4. Read a group of channels and log the data for short periods of time during longer periods of time. Consider the program

This application uses the System Timer 2, which increments every minute (See Section III ñ System Timers). Schedule A is entered to scan a group of voltage inputs, and is immediately halted. The Alarm Schedule is temporarily halted (to prevent the loss of initial synchrony) and the two Alarms are entered. Data logging is enabled.

Alarm1 starts Schedule a scanning when the System Timer exceeds 55 counts (55 minutes), and Alarm2 stops Schedule A scanning when the System Timer exceeds 5 counts (5 minutes). The System Timer 2 is synchronized to the real time clock, and resets to a count of zero on a count of 60 (minutes).

The program is started by enabling the Alarms Schedule. The effect of the program is to scan the group of channels and log the data from 5 minutes before each hour until 5 minutes after each hour