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
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.
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.
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.
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.
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
input channel or system data less than a setpoint
input channel or system data outside the range of two setpoints
input channel or system data between two setpoints
Each of these elements of the Alarms are discussed in detail in the following sections.
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.
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
ALARMR2 - returns the alarm message to the host continuously while the single ended
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
IFR15 - returns the alarm message to the host continuously while the value of
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.
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 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
>< - the test data increases from a low value to equal to or greater than the first setpoint, or
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 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
ALARM1(2V>100.0)"Alarm 1 High"
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.
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
ALARM17(1CV<>2CV,3CV)"Out of Range"
DeLogger does not support setpoints being programmed as Channel Variables.
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.
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 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 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.
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
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.
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
? substitute with the current value for the alarm test data in the alarm message returned to the
# ñ 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.
ALARM4(10PT392>150.0)"Alarm ! High Temp @ ^M^J"
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.
ALARM6(5V(Y1)<>90,110/30S)"Low Press ? psi^M^J"
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.
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)
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.
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
ALARM 3 OFF
and will be displayed as follows when the temperature is above 100°C and therefore in alarm
ALARM 3 ON
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
ALARM 3 OFF
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
ALARM3(1TK("Low Temp")>100)"High Temp"
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
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.
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
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
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.
ALARM3(T>09:00:00)"[RA5S 1..10V LOGON]"
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
ALARM4(2L(Y1)>15)"Alarm [R1M 2L(Y1) LOGON]"
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.
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
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
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.
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
ALARM1(5F>85)4DSO"Hi Freq[R1S 5F LOGON]"
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
ALARM4(5F>85)"Hi Freq[4DSO=1 R1S 5F LOGON]"
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.
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
ALARM is the Alarm identifier
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
ALARM1(4TT>55)AND ALARM2(5TT>55)"High Temp"
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.
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 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)
The general format for the Alarm Schedule trigger as digital events is
RZnE ñ trigger on both transitions
The general format for the Alarm Schedule trigger as counter events is
RZnC(count) ñ trigger on count from a low speed counter
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.
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.
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
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.
The sampling and processing of individual Alarms can be halted and resumed by the commands
HZn Halt processing of an individual alarm
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.
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.
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
? is the Alarm Query identifier
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
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.
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
and the command
produces a detailed report of the Alarms similar to
3,0 Alarms Active,Halted
Individual Alarms which have been halted by the HZn command are reported with the Alarm keyword in lower case characters as follows
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.
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.
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.
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