dataTaker - Data Loggers, Powerful and Flexible Data Acquisition & Data Logging Systems

Schedules

General operation of the dataTaker data loggers centres around scheduling. Schedules determine when various processes are to occur, and can be triggered by the real time clock, by digital or counter events, by alarm states, and by the host computer. The dataTaker supports 7 different types of schedules.

The Schedules manage schedule lists, which contain the various actions that are to be performed when the Schedule is triggered or runs. These actions include reading input and internal channels, setting output channels, evaluating expressions, testing alarms, returning data, logging data, etc.

Many dataTaker commands relate to the Schedules and their schedule lists. Therefore it is important to understand this core concept of Schedules and scheduling.

There are three basic types of Schedules

Immediate Schedule ñ the schedule list is processed or scanned once immediately, and any data produced is returned to the host computer. The schedule list can be rescanned at any time by poll triggers from the host computer. Data from the Immediate Schedule cannot be logged or displayed.

Triggered Schedules ñ the schedule list is processed or scanned at regular or irregular intervals of time. Any data that is produced can be returned to the host and logged to the internal data memory or a memory card.

Statistical Sub Schedule ñ the schedule list is processed or scanned repeatedly and the data is used to calculate a periodic average, standard deviation, minimum and/or maximum or integral data for the input channels.

This Sub Schedule is used in conjunction with the Triggered Schedules, which determine the interval at which the statistical data is calculated and returned to the host, logged into the data memory or memory card, and displayed.

The Triggered Schedules and the Statistical Sub Schedule can be triggered by

real time, using the dataTaker real time clock ñ clock events

a change of state of one or more digital input channels ñ digital events

one or more counters incrementing to a terminal value ñ counter events

while one or more digital input channels is high ñ while conditional

There are six Schedules which can operate simultaneously to read input channels, evaluate expressions, etc. Each Schedule can trigger at different intervals in response to different triggers, and each with a different schedule list.

The six different types of Schedules are

one Immediate Schedule

five Triggered Schedules

one Statistical Sub Schedule, which can be associated with any or all of the Triggered Schedules.

These could be considered as the Data Schedules. There is also a single Alarm Schedule, which contains all of the alarms to be processed (See Section III ñ Alarms).

Number of Channels for Schedules

Whenever Schedules with schedule listsare entered into the dataTaker, the channels that are to be scanned and calculations that are to be performed are all entered into an internal channel table.

The channel table contains all of the details of the individual channels to be scanned, including the type of input signal, the scan interval, how resultant data is to be processed, where resultant data is to be sent, etc. The channel table also contains a RPN (Reverse Polish Notation) form of each expression.

The Data Schedules and the Alarm Schedule all share the internal channel table. A maximum of 110 channels, calculations and alarms can be entered into the channel table.

After power up, a hardware reset or a RESET command, the internal channel table is allocated between the Data Schedules and the Alarm Schedule as follows

90 entries in the channel table are allocated for the Data Schedules 

20 entries in the channel table are allocated for the Alarm Schedule

Reallocating the Internal Channel Table 

The allocation of the internal channel table for the Data Schedules and the Alarm Schedule can be changed using the Parameter30 command (See Section III ñ Parameter Commands).

Parameter30 defines the number of entries in the internal channel table which are to be allocated to the Alarm Schedules. The balance is allocated to the Data Schedules.

For example, using DeTransfer the number of entries is changed by the commands

P30=0

which allocates no space in the channel table for the Alarm Schedule, and sets the maximum space for the Data Schedules to 110 entries, and

P30=50

which allocates 50 entries in the channel table to the Alarm Schedule, and allocates 60 entries in the channel table for the Data Schedules.

The internal channel table must be reallocated if necessary before any Data or Alarm Schedules are entered. Attempts to change the channel table allocation after any Schedules have been entered will result in the error message 'E8- Parameter read/set error'.

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.

Protecting the Internal Channel Table

When Data Schedules are entered into the internal channel table, entry of successive Data Schedules will overwrite and destroy any existing Data Schedules.

The exception to this general rule is when the original Schedules have logged data into data memory, when attempts to enter new Schedules are rejected.

The risk of accidentally overwriting the internal channel table, or of accidentally altering Schedules, can be overcome by setting the Fix Channel Table Switch as follows

/F  Fix or secure the channel table, not allowing entry of new Data Schedules
or re-defining triggering for existing Data Schedules

/f   Free the channel table, allowing entry of new             Data Schedules or re-defining
triggering of existing Data Schedules

The Fix Channel Table Switch defaults to disabled (/f) after a power up, a hardware reset or a RESET command. Attempts to enter new Schedules, or to re-define the triggering for existing Schedules, while the Fix Channel Table Switch is enabled will result in the error message 'E48-schedule list fixed'.

 


Immediate Schedule

A single channel or expression, or a group of channels and/or expressions, can be processed at any time by the dataTaker using the Immediate Schedule.

The Immediate Schedule can be used for a number of purposes, including checking, testing or calibrating channels, initialising variables, changing the state of outputs, etc. The Immediate Schedule does not disrupt any other Schedules which may be in progress, and so can be used when programs are running.

The Immediate Schedule runs only once, immediately after the schedule list is received from the host computer. Any data that is produced is returned immediately to the host computer, and cannot be displayed on the logger display panel or logged into the data memory.

The Immediate Schedule does not repeat automatically, however the Immediate Schedule can be run again at any time by entering the schedule list again, or by entering the Immediate Trigger.

Immediate Schedule Command

An Immediate Schedule is specified by entering a schedule list containing one or more input channels and/or expressions, in the general format

schedule list

There is no separate trigger for this Schedule ñ the entering of the schedule list is the trigger.

Using DeTransfer, Immediate Schedules are entered by the following commands for example

T
1V  1DS
1..5TT

These 3 Immediate Schedules will respectively

return the current time

return the voltage measured on analog input channel 1, and the logic state on digital input channel 1

return the temperature from five T type thermocouples connected to analog channels 1 through 5

When a new Immediate Schedule is entered, it replaces any previous Immediate Schedule list.

 

DeLogger does not directly support the Immediate Schedule, however when channel specifications or expressions are placed in the Pre Schedule or Post Schedule fields of the Initial Conditions dialog, these are assembled into the final program as Immediate Schedules.

Immediate Schedules can also be sent from the Text View, either directly from the lower Entry Screen, or from the User buttons.

Immediate Trigger Command

After an Immediate Schedule has been entered into the dataTaker, the Schedule can be run again by
re-entering the same schedule list, or by entering the Immediate Trigger command as follows

*  (the Immediate Trigger is the asterisk character)

The schedule list associated with the last entered Immediate Schedule can be processed as many times as required, simply by entering the Immediate Trigger for each execution required. If there is no Immediate Schedule schedule list entered when the Immediate Trigger is received, then the command is ignored.

The Immediate Schedule operates similarly to the Schedule Triggered by Poll (see below), except that

the Immediate Schedule first runs immediately after it is entered into the logger

Schedule Triggered by Poll first runs after the first Poll Trigger command (X) is received (see below).

DeLogger does not support the Immediate Triggerñ it is generally not appropriate in the DeLogger environment. However if necessary, a User button in the Text View could be set up to send the Immediate Trigger command (*) whenever clicked with the mouse.

Using Immediate Schedules in Programs

The positioning of the Immediate Schedule within dataTaker programs using the BEGIN . . . END block construct is important.

The Immediate Schedule list must be positioned either

outside of the BEGIN . . . END block construct, before BEGIN or after END

following BEGIN, but before any Triggered Schedules are entered

The Schedule will execute immediately after entry in both cases.

Using DeTransfer, the Immediate Schedule can be included in programs as follows

1V(=10CV,W)
BEGIN
      'Triggered Schedules, etc
END

where the Immediate Schedule list is entered before the BEGIN, and is immediately executed.

Also

BEGIN
      1V(=10CV,W)
      'Triggered Schedules, etc
END

where the Immediate Schedule list is entered after the BEGIN but before any Triggered Schedules, and is immediately executed on entry.

However, if the Immediate Schedule list is entered after the BEGIN and after a Triggered Schedule as follows

BEGIN
      'Triggered Schedules, etc
      1V(=10CV,W)
END

then it will be attached to the Triggered Schedule and will not behave as an Immediate Schedule.

 


Triggered Schedules

The Triggered Schedules provide the most useful form of data acquisition and data processing by the dataTaker. These Schedules allow input channels to be repeatedly scanned, expressions to be repeatedly evaluated, etc. often without the need for intervention or control by the host.

The Triggered Schedules can also be regarded as the repeating schedules or reporting schedules, in that these schedules repeatedly report data at intervals.

A maximum of five Triggered Schedules can be entered into the dataTaker, and each having a different schedule list, each running at different intervals in response to different triggers.

The data from Triggered Schedules can be returned to the host computer in real time, can be logged into the internal data memory or a memory card, and can be displayed.

The Triggered Schedules repeatedly scan a group of input channels, and/or repeatedly evaluate a group of expressions, all of which are defined in the schedule lists. The repetition is based on various triggers and conditions as follows

Schedule Triggered by Poll ñ runs whenever a poll command is received by the logger

Schedule Triggered by Time ñ runs at regular intervals of time from seconds to months, and is triggered by the loggerís real time clock

Schedule Triggered by Digital Events – runs at regular or irregular intervals, and is triggered by state changes or ‘eventsí on the digital inputs

Schedule Triggered by Counter Events – runs at regular or irregular intervals, and is triggered by total count ‘eventsí from the counters

General Format for the TriggeredSchedules 

The Triggered Schedules are specified by the prefix R, that is extended by parameters which define the trigger and optional conditions for triggering.

The general format of the Triggered Schedules is

R(trigger) [schedule list]

where

R                       is the Trigger Schedule identifier
(trigger)               is the trigger for when the Schedule runs
[schedule list]       list of the channels to be read, expressions to be evaluated, etc

The trigger for the Schedules can be defined in terms of any of the following

a poll trigger, received by the logger as the Poll Trigger command (X)

a time trigger, specified as a time interval between triggers from the real time clock

a digital event trigger, specified by one or more digital input channels that receive events

a counter event trigger, specified by one or more counters which will generate counter total events

The specifications of the different types of triggers for initiating the Triggered Schedules are described in the following chapters.

Normally, when Triggered Schedules are entered, these will replace or overwrite any existing Triggered Schedules. However a number of Triggered Schedules can be entered using a special BEGINÖEND block construct, which causes the logger to append successive Triggered Schedules into one channel table list (See Section III - General Schedule Commands).

Identifying Triggered Schedules

When only one Triggered Schedule is entered into the dataTaker, then the general command format described above is sufficient. However the dataTaker supports up to five Triggered Schedules, which have individual identification.

If two or more Triggered Schedules are entered in the dataTaker, then individual Schedules are identified as Triggered Schedules RX,  RA,  RB,  RC  and  RD.

The general formats for defining the five Triggered Schedules are listed below

RX[schedule list]

RA(trigger)[schedule list]

RB(trigger)[schedule list]

RC(trigger)[schedule lis]

RD(trigger)[schedule lis]

Triggered Schedules A, B, C and D all have a (trigger) which is defined in terms of time, digital events or counter events. The Repeat Schedules run in response to their defined trigger. The Schedule Triggered by Poll (RX) does not have a variable trigger. The trigger is the Poll Trigger command (X) that is sent from a host computer or from elsewhere in the program, such as from alarms.

If the Triggered Schedules are not given an identity at the time of entry, then the dataTaker assigns an identity in the order A, B, C then D.

If one Triggered Schedule without identity is entered, this assumed to be Triggered Schedule A. If two or more Triggered Schedules without identity are entered in one command line, then the first is assigned as Triggered Schedule A, the second as Triggered Schedule B, etc.

The Triggered Schedules only run in response to their defined trigger. When the Schedules are first entered, the Schedule does not run until the first trigger occurs. This is in contrast to the Immediate Schedule, in which case the Schedule runs as soon as it is entered.

Halting and Resuming Triggered Schedules

The Triggered Schedules can be globally and individually halted, and globally and individually resumed, by the Halt and Go commands as follows

H          Halt all Triggered Schedules
G          Resume all Triggered Schedules

HA        Halt Triggered Schedule A
GA        Resume Triggered Schedule A

HB        Halt Triggered Schedule B
GB        Resume Triggered Schedule B

HC        Halt Triggered Schedule C
GC        Resume Triggered Schedule C

HD        Halt Triggered Schedule D
GD        Resume Triggered Schedule D

When the dataTaker is initially powered up or executes the RESET command, all Triggered Schedules are in the halted state. This allows the dataTaker to sleep.

When Triggered Schedules are entered, they are automatically enabled at the time of entry which allows the Schedules to run at the next trigger.

Note that the Schedule Triggered by Poll cannot be halted, since by its very nature it is halted until the next Poll Trigger command is received.

Order of Data Returned by Triggered Schedules

Whenever two or more Triggered Schedules are entered into the dataTaker, and all are running, then the data that is produced is returned to the host computer in the order

ñ Immediate Schedule data

ñ Schedule Triggered by Poll data

ñ Triggered Schedule A data

ñ Triggered Schedule B data

ñ Triggered Schedule C data

ñ Triggered Schedule D data

This ordered return of data occurs irrespective of the order in which the Triggered Schedules were originally entered into the dataTaker.

If the Units Text Switch is enabled (/U), then a CR and LF character sequence is returned at the end of the block of data from each Triggered Schedule.

If the Units Text Switch is disabled (/u), then the block delimiter character defined by the Parameter24 command is returned at the end of the block of data from each Triggered Schedule.

Extending Triggered Schedules

The use of more than one Triggered Schedule in a program is discussed in detail in Section III ñ Multiple Triggered Schedules.

Operation of the Triggered Schedules can also be conditional on external conditions, that are monitored as the logic state on one or more digital input channels. This conditional triggering is described in Section III - Schedules Triggered While Condition.

 


Schedule Triggered by Poll 

The simplest of the Triggered Schedules for repeatedly executing a schedule list is the Schedule Triggered by Poll. This Schedule executes its schedule list each time that a Poll Trigger command is received by the loggerís command processor.

The Poll Trigger command can come from

a host computer, where software running on the computer determines when the Schedule must run, and sends a Poll Trigger command to the logger to run the Schedule

other parts of the running program such as alarms, which can generate the Poll Trigger command when an alarm state occurs. This is useful for performing tasks such as returning, logging or displaying data, changing output channels, etc. in response to alarm conditions.

The dataTaker has only one Schedule Triggered by Poll.

When a Schedule Triggered by Poll is been entered into the logger, the schedule list is not executed until a Poll Trigger is received. When a Poll Trigger is received the schedule list is executed. The logger does not execute this list again until the next Poll Trigger command is received.

Resulting data can be returned to the host computer, logged to the internal data memory or a memory card, and displayed.

Whenever successive Schedule Triggered by Polls are entered, these will replace or overwrite existing Schedules.

Schedule Triggered by Poll Command

The Schedule Triggered by Poll is specified by the general command format

RX [schedule list]

where

RX                     is the Schedule Triggered by Poll command
[schedule list]       list of the channels to be read, expressions to be evaluated, etc

The Schedule Triggered by Poll has a command trigger. The trigger is an X character sent from the host computer or from an alarm.

Using DeTransfer, a Schedule Triggered by Poll is entered as follows

BEGIN
 RX
  1V(=1CV)  2I(=2CV)  3CV(ìPowerî)=1CV*2CV
END

The schedule list is executed each time a Poll Trigger is received from the host or an alarm.

Using DeLogger, a Schedule Triggered by Poll can be entered into a program in the Program Builder as follows. Click on the ëXí tab to open the Schedule Triggered by Poll work area, and then enter the input channels and calculations to be executed into the work area as for other schedules.

Note that the Schedule button cannot be opened ñ the Schedule trigger is permanently set to the X command.

 

 

Triggering the Schedule from the Host Computer

When a Schedule Triggered by Poll has been entered into the dataTaker, the schedule list is not executed until the appropriate trigger is received. Whenever a Poll Trigger command is received by the loggerís command processor, this triggers execution of the schedule list.

The Poll Trigger command is the X character.

Using DeTransfer, a Schedule Triggered by Poll is triggered to execute by sending the X character to the logger, terminated by CR or CR/LF, for example

X

The schedule list executed each time this trigger is received.

This form of input channel scanning is appropriate to polling the dataTaker from a dedicated host computer to obtain data at intervals determined by the host. A number of the third party data acquisition software packages manage the dataTaker by this method.

Using DeLogger, a Schedule Triggered by Poll can be executed by either of two methods

in the Text View, type the ëXí command into the lower or Entry Screen, and send it to the logger by hitting the Return key

in the Text View, define a User button on the lower toolbar as an ëXí command, and then click this button each time the Schedule is required to execute.

 

 

Make sure that the Text View is logically connected to the logger ñ select the connection from the drop down list at the bottom of the window.

 

Triggering the Schedule from an Alarm

The Alarms can also issue the Poll Trigger command (X), thereby triggering execution of the schedule list.

The following example with DeTransfer illustrates triggering a Schedule Triggered by Poll from an alarm

BEGIN
 RX
  1TK
  9CV(W)=9CV+1

 RS1S
  ALARM5(1TK>150)"[X]"
end

The schedule list is executed each time the temperature of the thermocouple exceeds 150°C. ALARM5 detects the over range condition, and triggers the Schedule to record the temperature under alarm conditions

 


Schedules Triggered by Time

The most widely used of the Triggered Schedule for executing schedule lists is the Schedule Triggered by Time. This Schedule is used to execute schedule lists at regular intervals of time ranging form 1 second to months.

The schedule list is executed automatically at each interval of time, and data can be returned to the host computer, logged into the internal data memory or a memory card, and displayed.

The Schedule Triggered by Time is suited to the situation where the dataTaker is used independently of the host, recording data at regular intervals of time into the internal data memory or a memory card.

Schedule Triggered by Time Command

Schedules Triggered by Time are triggered by the real time clock, and the trigger is specified in terms of the time interval between successive triggers. This therefore allows specification of the interval between successive readings of input channels, etc.

The real time scan interval can be from one second to months, and is specified in terms of seconds, minutes, hours or days.

Up to four Schedules Triggered by Time can be entered into the dataTaker, with each executing a different schedule list at different intervals of time.

The general formats for Schedules Triggered by Time are as follows

R(interval)S[schedule list]
R(interval)M[schedule list]
R(interval)H[schedule list]
R(interval)D[schedule list]

where

R                       is the Triggered Schedule identifier
(interval)              is the trigger interval in the range 1 ñ 65535
S                       the time interval is in seconds
M                      the time interval is in minutes
H                       the time interval is in hours
D                       the time interval is in days
[schedule list]       list of the channels to be read, expressions to be evaluated, etc

The trigger interval must be an integer in the range of 1 to 65535. This value is interpreted in terms of the S, M, H or D unit of time specified to determine the real time trigger interval.

If the trigger interval is zero, then the Schedules Triggered by Time run at the maximum rate irrespective of whether S, M, H or D is specified. If no time interval is specified, then the Schedule will also run at the maximum rate possible.

When a schedule list is to be executed at an interval which is a fraction or part of a minute, hour or day, then the interval must be specified in the next lowest unit of time. If for example the Schedule is to be triggered every 1.5 hours (1.5H), then the trigger interval must be specified as 90 minutes (90M).

Using DeTransfer, Schedules Triggered by Time to run at regular intervals of time are for examples

BEGIN
 R15M
  1..5V  8TK  1..2DS
END

where the Schedule will run every 15 minutes. This Schedule is not given an identity, and so is assigned as Schedule A by the logger

BEGIN
 RA20S
  1..5V  8TK  1..2DS
END

where the Schedule A will run every 20 seconds.

BEGIN
 RB12H
  1..5V  8TK  1..2DS
END

where the Schedule B will run every 12 hours.

The same trigger interval can be defined in several ways, which allows complete flexibility in the definition of the time interval. For example the Schedules

RA3600S 1..5V 8TK 1..2DS

RA60M 1..5V 8TK 1..2DS

RA1H 1..5V 8TK 1..2DS

will all run every hour.

Using DeLogger, the time interval for Schedules Triggered by Time is defined in the Program Builder for the chosen Schedule. Click on the A, B, C or D tab to select the schedule, and right click on the Schedule button at the top of the work area and select Set Schedule RateÖ

 

 

 

The Schedule Rate dialog opens, click on the required time units radio button, and enter the number of time units in the Value field. The example above sets the trigger interval for Schedule A to 15 minutes.

Running Schedules at the Maximum Speed

The dataTaker cannot be programmed to run Schedules at intervals of less than 1 second. However, where intervals of less than 1 second are required, then the ëfree runí or maximum rate can be used.

If no time interval trigger is defined, or an interval trigger of 0 (zero) time units is defined, then the Schedule will execute continuously at the maximum rate possible for the program.

The analog to digital converter of the dataTaker has a sampling rate of 16.67 conversions/second (60Hz) or 20 conversions/second (50Hz). In the case of digital state and counter channels, the sampling rate is faster. Calculations only take 2 ñ 5 millisecs.

The maximum Schedule execution rate is also influenced by other factors such as

the configuration of the analog to digital converter

the number and complexity of other Schedules which are also in progress

whether input channels sampled are simple analog inputs such as voltage, current, frequency, etc.
or are complex inputs such as thermocouples, RTD's, etc. requiring additional processing

the linearization of channel data by polynomials and span limits

whether data is being returned to the host as it is acquired

whether data is being logged as it is acquired

whether alarms are being monitored

whether the internal data memory or memory card is being simultaneously unloaded to the host

Despite these factors, the maximum Schedule execution rate for the dataTaker is generally 8 ñ 10 channels/second if the data is being returned to the host computer in real time (9600 baud), and 25 channels/second if the acquired data is being logged to the internal data memory or memory card.

The maximum analog sampling rate of the dataTaker is discussed in detail in Appendix E.

Command for Scanning at the Maximum Rate

Continuous execution of Schedules Triggered by Time at the maximum conversion rate is programmed by entering a Schedule with no time interval trigger, in the general format

R [schedule list]

where

R                       is the Triggered Schedules identifier
[schedule list]       list of the channels to be read, expressions to be evaluated, etc

Continuous execution at the maximum conversion rate can also be programmed by entering a Schedule with a 0 (zero) time interval trigger.

Using DeTransfer, a Schedule Triggered by Time is programmed to execute continuously at the maximum rate as follows

BEGIN
 RA
  1V 2R 3F 4DS
END

Note:  The regularity of the repetitive executions may vary slightly due to automatic recalibration of the analog to digital converter, if this is enabled. However such delays are rarely a problem.

 

 

Halting and Resuming Schedules Triggered by Time

Schedules Triggered by Time can be individually and globally halted and resumed by the Halt and Go commands

H          Halt all Triggered Schedules
G          Resume all Triggered Schedules

HA        Halt Triggered Schedule A
GA        Resume Triggered Schedule A

HB        Halt Triggered Schedule B
GB        Resume Triggered Schedule B

HC        Halt Triggered Schedule C
GC        Resume Triggered Schedule C

HD        Halt Triggered Schedule D
GD        Resume Triggered Schedule D

When the dataTaker is initially powered up or executes the RESET command, all Triggered Schedules are in the halted state. This allows the dataTaker to sleep.

When Triggered Schedules are entered, they are automatically enabled at the time of entry which allows the Schedules to run at the next trigger.

 


Schedules Triggered by Digital Events

Schedules Triggered by Digital Events are used to run Schedules and execute schedule lists whenever a change of state occurs on one or more of the digital input channels. The resulting data can be returned to the host computer, logged to the internal data memory or a memory card, and displayed.

The digital event used to trigger the Schedule can be one of three different types of event as follows

any change of state that occurs on the nominated digital input channel(s)

a low to high (negative to positive) change of state occurs on the nominated digital input channel(s)

a high to low (positive to negative) change of state occurs on the nominated digital input channel(s)

One or more digital input channels of the dataTaker can be used to trigger Schedules. When more than one digital event input is used, then triggering operates in a logical OR manner such that the Schedule runs when any of the digital inputs changes state.

Schedules Triggered by Digital Events can be used where the dataTaker is operating independently of a host computer, to record data at intervals determined by external asynchronous events that often come from the machine or system under test. These events are usually a logic state change or contact closures.

Schedules Triggered by Digital Events could for example be used as the basis of an event recorder, or for a process 'flight recorder', or for gathering data in response to intermittent faults within a machine, process or system, etc.

Note 1 :  The digital channels of the dataTaker are powered off while the logger is in the low power or sleep mode, and so cannot detect changes of state. Therefore the digital input channels cannot be used to detect external events for triggering Schedules during low power operation. Digital event triggering can only be performed if the automatic low power selection of the dataTaker is disabled by setting Parameter15=2, or if the logger is externally powered.

Note 2 :  The digital channels used to detect external events for triggering scans are bi-directional. These channels cannot be used to detect external events if they have previously been used for digital outputs, and left switched ON. The digital channels can only be used to detect events if their output state is OFF.

Note 3 : The digital channels of the Channel Expansion Modules do not support triggering of Schedules.

Schedule Triggered by Digital Events Command

The general formats for Schedules Triggered by Digital Events command are as follows

RnE[schedule list]
Rn..mE[schedule list]
Rn+E[schedule list]
Rn..m+E[schedule list]
RnñE[schedule list]
Rn..m-E[schedule list]

where

R                       is the Triggered Schedule identifier
n                       is any digital input channel
n..m                   is a sequence of digital input channels
E                       is the digital event identifier for triggering on any transition
+E                      is the digital event identifier for triggering on positive transitions
–E                      is the digital event identifier for triggering on negative transitions
[schedule list]       list of the channels to be read, expressions to be evaluated, etc

Using DeTransfer, Schedules Triggered by Digital Events are programmed for example

BEGIN
 RA1+E
  1..5V 8TK 1..2DS
END

where the Schedule will run each time a positive transition occurs on digital input channel 1

BEGIN
 RA3..4E
  1..5V 8TK 1..2DS
END

where the Schedule will run whenever a positive or negative transition occurs on either of digital input channels 3 OR 4.

Using DeLogger, the digital event(s) for Schedules Triggered by Digital Event is defined in the Program Builder for the chosen Schedule. Click on the A, B, C or D tab to select the schedule, and right click on the Schedule button at the top of the work area and select Set Schedule TriggerÖ

 

 

 

The Schedule Trigger dialog opens, check the Trigger channel(s), and click the appropriate Trigger Event radio button.

The example above sets the trigger event for Schedule A as a positive going (low to high) state change on digital input channel 1.

If more than 1 digital input channel is used as a trigger, then these must be consecutive channels.

 

 

Halting and Resuming Schedules Triggered by Digital Events

Schedules Triggered by Digital Events can be individually and globally halted and resumed by the Halt and Go commands

H          Halt all Triggered Schedules
G          Resume all Triggered Schedules

HA        Halt Triggered Schedule A
GA        Resume Triggered Schedule A

HB        Halt Triggered Schedule B
GB        Resume Triggered Schedule B

HC        Halt Triggered Schedule C
GC        Resume Triggered Schedule C

HD        Halt Triggered Schedule D
GD        Resume Triggered Schedule D

Halting of the Schedules merely disables the sensitivity of the trigger to changes of state on the digital input channel(s).

When the dataTaker is initially powered up or executes the RESET command, all Triggered Schedules are in the halted state. This allows the dataTaker to sleep.

When Triggered Schedules are entered, they are automatically enabled at the time of entry which allows the Schedules to run at the next trigger.

Some Applications Ideas

When a number of digital events are used to trigger a Schedule, the digital event which initiated each execution can also be recorded by including the appropriate digital input channels in the schedule list as logic state inputs, as the following example illustrates

BEGIN
 RA2..4E
  2..4DS 1..10V
END

Alternatively the logic state byte input (1DB) could be included in the schedule list.

The extension of this technique is a digital event recorder, simply implemented by either of programs

BEGIN
 RA1..4E
  1..4DS
END

BEGIN
 RA1..4E
  1DB
END

which reads the digital input channels whenever an event occurs on any digital channel.

 


Schedules Triggered by Counter Events

Schedules Triggered by Counter Events are used to run Schedules and execute schedule lists whenever one or more of the low speed or high speed counters generates a counter event. The resulting data can be returned to the host, logged to the internal data memory or a memory card, and displayed.

Low Speed Counter Events

Low speed counter events are generated when one or more nominated low speed counters reaches a specified terminal count. When more than one low speed counter is nominated, then triggering operates in a logical OR manner such that the schedule list is scanned when any counter generates an event.

Note 1 :  The digital input channels of the dataTaker are powered off while the logger is in the low power mode, and so cannot count input pulses or generate triggers. Therefore the low speed counters cannot be used to generate counter events during low power operation. Counter event triggering can only be performed if the automatic low power of the dataTaker is disabled by setting Parameter15=2, or if the logger is externally powered.

Note 2 :  The digital channels used to generate the low speed counter events are bi-directional. These channels will not generate counter events if they have been used for digital outputs, and left ON. Digital channels will only generate counter events if the output state is OFF.

High Speed Counter Events

High speed counter events are produced when one or more nominated high speed counters receives a pulse. The dataTaker checks the high speed counters every 50mS, and if a counter nominated for counter event scheduling has received one or more pulses in the previous 50mS, then a trigger is generated.

When more than one high speed counter is nominated, the triggering operates in a logical OR manner such that the schedule list is scanned when any counter generates an event.

Note : The High Speed Counters are always powered, and can sense pulses while the logger is in the low power mode. However the logger must be awake to find the count(s) and generate triggers.

The sleeping logger can be waked by the input pulse, by diode connecting the high speed counter(s) to the Wake terminal. The input pulse wakes the dataTaker and is sensed by the high speed counter, which then generates a trigger. The diode is necessary to prevent a 10Hz frequency which is output by the Wake terminal when the dataTaker is awake, from reaching the high speed counter input.

Schedules Triggered by Counter Events Command

The general formats for Schedules Triggered by Counter Events command are as follows

RnC(count) [schedule list]
Rn..mC(count) [schedule list]
RnHSC [schedule list]
Rn..mHSC [schedule list]

where

R                       is the Triggered Schedule identifier
n                       is any counter channel
n..m                   is a sequence of counter channels
C                       is the Low speed counter event identifier
HSC                   is the High speed counter event identifier
(count)                is the terminal count, in the range of 0 to 65535 (low speed counters only)
[schedule list]       list of the channels to be read, expressions to be evaluated, etc

The count parameter for the low speed counters sets the terminal count at which the counter generates an event to trigger the associated Schedule on Counter Events. The count parameter must be an integer, in the range of 0 to 65535.

The counters used for Schedules Triggered by Counter Events are set to zero when the original Schedule is entered into the dataTaker. Incoming pulses are counted until the terminal count is reached, and an event is generated and the counter is reset to zero.

Using DeTransfer, Schedules Triggered by Counter Events are programmed for example

BEGIN
 RA1C(150)
  1..5V 8TK 1..2DS
END

where the Schedule will run following each 150th count of low speed counter 1.

BEGIN
 RA1HSC
  1..5V 8TK 1..2DS
END

where the Schedule will run following each pulse sensed by high speed counter 1.

Using DeLogger, the digital event(s) for Schedules Triggered by Counter Event is defined in the Program Builder for the chosen Schedule. Click on the A, B, C or D tab to select the schedule, and right click on the Schedule button at the top of the work area and select Set Schedule TriggerÖ

 

 

 

The Schedule Trigger dialog opens, check the Trigger channel(s), click the Pulse Count radio button, and enter the terminal count value in the input field. The example above sets the trigger for Schedule A as a count of 150 on low speed counter 1 (digital input channel 1).

If more than 1 counter channel is used as a trigger, then these must be consecutive channels.

DeLogger does not support the High Speed Counters being used as events for triggering Schedules.

Halting and Resuming Schedules Triggered by Counter Events

Schedules Triggered by Counter Events can be individually and globally halted and resumed by the Halt and Go commands

H          Halt all Triggered Schedules
G          Resume all Triggered Schedules

HA        Halt Triggered Schedule A
GA        Resume Triggered Schedule A

HB        Halt Triggered Schedule B
GB        Resume Triggered Schedule B

HC        Halt Triggered Schedule C
GC        Resume Triggered Schedule C

HD        Halt Triggered Schedule D
GD        Resume Triggered Schedule D

When the dataTaker is initially powered up or executes the RESET command, all Triggered Schedules are in the halted state. This allows the dataTaker to sleep.

When Triggered Schedules are entered, they are automatically enabled at the time of entry which allows the Schedules to run at the next trigger.

Some Application Ideas

When a number of counter events are used to trigger a Schedule, the counter which initiated each scan can be recorded by including the counter channels in the schedule list as is illustrated in the following program

BEGIN
 RA1..4C(30)
  1..4C(R)
  1..5TK 6V 10R
END

The trigger counters that can be used to trigger Schedules share the same digital inputs as the normal data counters, however the two counter types are not related internally. Therefore clearing of a trigger counter when the terminal count is reached does not clear the normal data counter that could be being used for the same digital input channel.

 


Statistical Sub Schedule

The dataTaker supports statistical sampling, which allows for the periodic average, standard deviation, minimum, maximum, and integral data to be generated for the channels and channel variables in a schedule list.

The date and time at which the minimum and maximum data occurs can also be generated.

The statistical data can be returned to the host computer, logged into internal data memory or a memory card, and displayed at the next trigger of an associated Triggered Schedule.

The Statistical Sub Schedule does not report data to any destination. Further, the Immediate Schedule cannot be used to return data from the Statistical Sub Schedule.

The Statistical Sub Schedule runs and executes the schedule list at specified intervals, and the data is retained internally for calculation of average, standard deviation, minimum, maximum and integral.

Each time the Statistical Schedule runs, the channels and channel variables are read, and the data is managed internally as follows

the data is summed for later calculation of the average and standard deviation

the square of the data is summed for later calculation of the standard deviation

a scan count is maintained for later calculation of the average and standard deviation

the progressive minimum data, and the date and time of minimum is updated

the progressive maximum data, and the date and the time of maximum is updated

the progressive integral is maintained, using trapezoidal approximation

Note :  Only those procedures are carried out for which statistical functions are required (see below).

At the next associated Triggered Schedule interval, the average and standard deviation of the data for each channel are computed. The average, standard deviation, minimum, maximum, and integral data are then returned, logged and displayed.

The statistical data for linearized channel data (RTDs, monolithic, thermocouples, spans, polynomials and functions) is calculated after the linearization.

Applications for average, standard deviation, minimum, maximum and integral include

averaging of analog input channels reduces data, smooths signal noise, smooths inherently fluctuating signals, etc.

averaging of digital input channels returns the proportion of the total number of scans for which the digital input channel was high or true. This is in essence a measure of duty cycle.

averaging of resetting counters produces the arithmetic mean count

averaging of date and time produces the midpoint time for the Statistical Schedule interval.

standard deviation data for all channel types provides indication of the variability of the inputs

minimum and maximum data for all channel types provides an indication of the range of the inputs

minimum and maximum of date and time produces the start and end date and time for the Statistical Scheduling period

Statistical Sub Schedule Command

The Statistical Sub Schedule specifies the trigger at which channels requiring statistical functions are sampled. Only one Statistical Sub Schedule can be specified, and it applies to all Triggered Schedules which contain channels and channel variables which require statistical functions.

A schedule list is not associated with the Statistical Sub-Schedule as in the case for Triggered Schedules. Instead the channels sampled by the Statistical Sub Schedule are defined in other Triggered Schedules, and have statistical channel options declared.

The Statistical Sub-Schedule can be triggered in the same way as the Triggered Schedules as follows

RS               continuous statistical sampling (default)
RSnE            triggered by n digital event
RSnC           triggered by n low speed counter event
RSnHSC       triggered by n  high speed counter event
RSnS            triggered by n seconds
RSnM           triggered by n minutes
RSnH           triggered by n hours
RSnD            triggered by n days

Refer to the preceding sections where the various trigger mechanisms for Triggered Schedules are described, for details of use of these triggers here.

The Statistical Sub Schedule trigger defaults to continuous sampling, and so a trigger does not need to be declared unless a different trigger is required. This allows statistical scanning to commence when statistical channel options are included for channels in the Triggered Schedule lists.

The Statistical Sub Schedule trigger can be changed at any time.

The Statistical Sub Schedule trigger interval must be shorter than the associated Triggered Scheduleís trigger interval. If this is not the case then statistical data of 99999.9 will result, and the error message 'E53 - no statistical samples' will be returned to the host.

This can occur inadvertently when the Statistical Sub Schedule trigger is an event, or the Statistical Sub Schedule has been halted.

Note : The Statistical Sub Schedule trigger defaults to continuous scanning, and so the dataTaker will not power down to the low power mode. If low power operation is required, then a longer Statistical Sub Schedule interval must be specified.

Specifying Channels for Statistical Functions

Statistical processing of the channel data is specified by including appropriate channel options for the channels in schedule lists associated with Triggered Schedules. The channel options for each of the statistical functions are listed in the table overleaf (See also Section III ñ Channel Options).

Average

AV ñ Returns the average reading for the period, which is the sum of all the channel readings divided by the number of readings. Averaging is useful for reducing noise in channel data, and reducing the volume of data collected.

The average is returned in the units of the original data, suffixed with (Ave).

Standard Deviation

SD ñ Returns the standard deviation of the readings for the period, which is a measure of the variability of the data about the average.

The standard deviation is returned in the units of the original data, suffixed with (SD).

 

Statistical Function

Channel Option

Units Text

Average

AV

(Ave)

Standard Deviation

SD

(SD)

Minimum

MN

(Min)

Maximum

MX

(Max)

Date of Minimum

DMN

(Dmn)

Date of Maximum

DMX

(Dmx)

Time of Minimum

TMN

(Tmn)

Time of Maximum

TMX

(Tmx)

Integral

INT

(Int)

 

Minimum & Maximum

MN & MX ñ Returns the minimum and the maximum readings for the period, which are a measure of the range of data about the average.

The minimum and the maximum are returned in the units of the original data, suffixed with (Min) or (Max).

Date & Time of Minimum & Maximum

DMN, DMX, TMN, TMX ñ Returns the date and the time at which the minimum and maximum values occurred. Any combination of these channel options can be used to return data as required.

The date of minimum and maximum data can be returned as the day number or date. This is determined by the setting of Parameter31 (See Section III ñ The Real Time Clock).

The time of minimum and maximum data can be returned as time in HH:MM:SS, decimal hours or seconds format. This is determined by the setting of Parameter39  (See Section III ñ The Real Time Clock)

The date and time returned is suffixed with (Dmn), (Dmx), (Tmn) or (Tmx) respectively.

Integral

INT ñ Returns the integral of the readings for the period. The integral calculation uses a trapezoidal approximation. Integration provides a means of converting rate measurements to quantity measurements (eg. flow rate to volume, velocity to distance, etc.). The integral is calculated with respect to the time period in seconds. Other time bases can be used by applying appropriately defined polynomials.

The integral is returned in the units of the original data, suffixed with (Int). Integral units text are not derived by the logger.

For example a flow meter measuring flow in litres/sec is integrated, the units text for the integral will be litres/sec (Int), and no simply litres.

Examples of Programming the Statistical Functions

Only one statistical sampling rate can be defined in an application, Therefore the Statistical Sub Schedule trigger must be chosen to provide adequate sampling for channels in those Schedules that are running most frequently.

Some programming examples follow which illustrate the use of the Statistical Sub Schedule and statistical functions of the dataTaker. These example programs can all entered into the logger using DeTransfer 

BEGIN
 RA10S
  3TK(AV,"Temperature Ave")
END

instructs the dataTaker to calculate the average temperature every 10 seconds for a Type K thermocouple connected to analog channel 3. Because there is no Statistical Sub-Schedule trigger specified in the program, the Statistical Sub-Schedule trigger defaults to the maximum sampling rate.

BEGIN
 RA5M
  3PT385(AV)(MN)(MX)(TMN)(TMX)
END

instructs the dataTaker to calculate every 5 minutes the average, minimum, maximum, time of minimum and time of maximum of temperature for a platinum RTD connected to channel 3. Since a Statistical Sub Schedule trigger is not specified, the channel is sampled at the default maximum rate.

Note where more than one Statistical function is required, then these are entered with each in a separate pair of braces. Any other channel options appropriate to the channel management are only entered in the first pair of braces.

BEGIN
 RA5M
 RS1S
  5V(AV)(MN)  6..8TK(AV)(MX)(MN)
END

instructs the dataTaker to read the input channels every 1 second (RS1S), and return the statistical data every 5 minutes (RA5M).

BEGIN
 RA5M
  5V(AV)  6..10TK(MX)  1HSC(AV)
 RS1+E
END

instructs the dataTaker to read the input channels every time a positive external event occurs on digital input channel 1, and return the statistical data every 5 minutes. Note that the RS schedule command can be anywhere between BEGIN and END.

DeLogger fully supports the Statistical Sub Schedule and statistical functions of the dataTaker. To set the trigger for the Statistical Sub Schedule click on the Statistical tab in the Program Builder, right click on the Statistical button, then select the trigger type. This opens the appropriate dialog where the trigger is set in terms of a time interval, a digital event or a counter event.

 

 

In the Schedule Rate dialog, set the time trigger by selecting a time unit (seconds, minutes, hours or days), and entering the number of time units.

 

 

In the Schedule Trigger dialog, select the digital or counter channel for the trigger, and select the type of trigger event.

 

 

The channels for which the statistics are required are tagged with the appropriate channel options in the Data Schedules A through D.

 

Define the channel in the normal way, then right click on the Data Use icon, and select PropertiesÖ to open the Channel Properties dialog. Click on the Statistical tab, and click in the check box(s) for the statistical functions required.

Number of Statistical Samples

The number of samples taken to generate Statistical data can be returned as system variable 5SV (See Section III - System Variables), which is included in the schedule list as follows

BEGIN
 RA10M
  5SV
  1..10V(AV)(MN)(MX)
 RS1M
END

In this example 5SV will return 10, because the Schedule A is triggered every 10 minutes (RA10M) and a Statistical Sub Schedule is triggered every 1 minute (RS1M).

In DeLogger, the number of statistical samples can be selected in the Program Builder. Right click in the work area to Add Channel, select System Variables, and select No.of statistical scans in last schedule.

 

 

Returning the number of samples is more appropriate to situations where the Triggered Schedule and/or the Statistical Sub Schedule are triggered by external events.

Limit to the Number of Statistical Scans

The Statistical Sub Schedule must not run more than 65535 times during the interval of the embracing Schedule which returns the statistical results. This limitation only applies when average and standard deviation data is required.

For example in the program

BEGIN
 RA1D
  1..10V(AV)(SD)(MN)(MX)
 RS1S
END

the Statistical Sub Schedule will run 86,400 times between triggers for Schedule A. This will produce erroneous average and standard deviation data, but will not affect the minimum or maximum data.

Statistical Sub Schedules within Multiple Triggered Schedules

Only one Statistical Sub-Schedule can be specified in a program. When two or more Schedules that contain channels for statistical functions are entered, all channels in all Schedules will be read at the same Statistical Sub Schedule interval.

Format of Returned Statistical Data

The format of statistical data returned to the host is the same as for normal data, and is fully user configurable (See Section III - Format of Returned Data). Statistical data has the text for the statistical type suffixed to the units text.

If the Units Text Switch (/U) is enabled , then returned statistical data is labelled with the statistical type.

The following program with statistical functions

BEGIN
 RA10M
  1TK(AV)(SD)(MN)(TMN)(MX)(TMX)
RS15S

will return data similar to

1TK  25.6 Deg C (Ave)
1TK  0.160 Deg C (SD)
1TK  22.1 Deg C (Min)
Time  11:12:15 (Tmn)
1TK  27.8 Deg C (Max)
Time  11:14:30 (Tmx)

Format of Displayed Statistical Data

Statistical data is displayed in the same format as for returned data. However channel identification text can be added to each statistical function to improve readability of the returned data in the display.

For example

BEGIN
 RA10M
  1TK(AV,"Ave Temp")(MX,"Max Temp")(MN,"Min Temp")
 RS15S
END

will display statistical data as follows

Ave Temp
25.6 Deg C (Ave)

Max Temp
27.8 Deg C (Max)

Min Temp
22.1 Deg C (Min)

The display of statistical data is usually updated when the main Schedule executes. However the display of minimum and maximum data can be updated each time that the Statistical Sub Schedule executes.

The displaying of minimum and maximum data is controlled by the Min Max Display Switch as follows

/x      Update minimum and maximum data when Schedule executes (Default)
/X      Update minimum and maximum data when Statistical Sub Schedule executes

Following initial power up, a hardware reset, or a RESET command, minimum and maximum updates when the Schedule executes.

Halting and Resuming the Statistical Sub Schedule

The Statistical Sub Schedule can be globally and individually halted and resumed by the Halt and Go commands as follows

H       Halt Data and Statistical Sub Schedules
G       Resume Data and Statistical Sub-Schedules

HS     Halt Statistical Sub-Schedule
GS     Resume Statistical Sub-Schedule

When dataTaker is initially powered up or executes the RESET command, the Statistical Sub Schedule defaults to halted. This allows the dataTaker to sleep.

When Schedule containing channels for statistical functions are entered, then Statistical Sub Schedule is automatically enabled at the time of entry. This allows the scanning to proceed at the next scan trigger.

The Schedule associated with a Statistical Sub-Schedule can be halted, without halting the Statistical Sub-Schedule.

Halting the Statistical Sub-Schedule does not halt the associated Repeating Schedules. However channels specified for statistical functions will only be read at the Schedule interval, and raw data will be returned.

 


Schedules Triggered While Condition

The execution of Data Schedules, the Statistical Sub Schedule and the Alarm Schedule can be made conditional on the status of one or more digital input channels.

The conditional execution of Schedules is implemented by the Schedules Triggered While command which is used in conjunction with the Triggered Schedules, Statistical Sub Schedule and Alarm Schedule.

The Schedules Triggered While Condition enables the Schedule while nominated digital input channels are high or true, and disables the Schedule while the digital input channels are low or false.

The digital input channels of the Channel Expansion Module cannot be used for this purpose.

Schedules Triggered While Condition

The general format for the Schedules Triggered While Condition are extensions to the triggers for the Schedules, Statistical Sub Schedule, and Alarm Schedule as follows

R(trigger):nW [schedule list]
R(trigger):n..mW [schedule list]
RS(trigger):nW
RS(trigger):n..mW
RZ(trigger):nW
RZ(trigger):n..mW

where

R                       is the Triggered Schedule
RS                     is the Statistical Sub Schedule
RZ                     is the Alarm Schedule
:W                     is the Trigger While
n                       is any digital input channel
n..m                   is a sequence of digital input channels
(trigger)               is the Schedule trigger or interval
[schedule list]       list of the channels to be read, expressions to be evaluated, etc

When a sequence of conditional channels is specified, then the While is true and scanning will occur if any of the digital input channels is high or true. The While channel sequence therefore has a logical OR characteristic.

Using DeTransfer, Schedules Triggered While Condition are programmed as follows for example

BEGIN
 RA5M:1W
  1..5V 7P 2C(R)
END

where the schedule list runs every 5 minutes while digital input channel 1 is high or true.

BEGIN
 RAS1M:2W
 R10M:1W
  1..5V(AV)
END

where the schedule list is executed for averaging every minute while digital input channel 2 is high, and the averaged data returned every 10 minutes while digital input channel 1 is high.

BEGIN
 RA1H:1..3W
  1..5V 7P 2C(R)
END

where the schedule list is executed every hour while any of the digital input channels 1, 2 OR 3 are true or high.

Note :  The digital channels used for conditional scanning are bi-directional. These channels cannot be used for conditional scanning if they have been used as digital outputs, and left ON. The digital channels can only be used for conditional scanning if their output state is OFF.

Using DeLogger, Schedules Triggered While Condition are programmed in the Program Builder. Firstly define the schedule trigger, then in the While Condition field click the digital input channel(s) which are the trigger conditions.

 

 

 

 


General Schedule Commands

There are a number of general characteristics of the Schedules such as

ï Entering multiple Schedules

ï Changing triggers for an existing Schedule

ï Halting and resuming Schedules

ï Combining Schedules and Alarms for specific effects

ï Altering the way in which the Schedules operate

Multiple Scan Schedules

The dataTaker can support up to five simultaneous Data Schedules, each scanning different schedule lists in response to different triggers of time, digital event or counter event.

The multiple Schedules can be entered in a single line format, or in a block format.

Single Line Format (DeTransfer)

The simple method of entering more than one Schedule is to enter all schedules in one command line. This is illustrated in the following command

RX 1V R10M 1..3V R1H 4..5TN R12H 7R R1E 1C

This example has five Schedules

a voltage on each poll from the host (RX 1V)

five voltages every 10 minutes (R10M 1..3V)

two thermocouples every hour (R1H 4..5TN)

a resistance every 12 hours (R12H 7R)

a resetting counter every time an event occurs (R1E 1C).

The five Schedules will function simultaneously, executing the respective schedule lists at respective intervals.

Entering multiple Schedules in a single command line however is limited by the maximum allowable command length of 250 characters. In the above example, the Schedules with triggers are not separately identified. However the dataTaker identifies the schedules as Schedules RA,  RB,  RC and RD from left to right.

The Schedule Triggered by Poll (RX) is permanently identified, where the X indicates a host request scan trigger.

The example above could have been entered from DeTransfer as

RX 1V RA10M 1..3V RB1H 4..5TN RC12H 7R RD1E 1C

The Schedule identifiers RA, RB, RC and RD can be used for subsequent re-scheduling, Halting and Going of the individual schedules.

Block Format BEGIN ... END (DeTransfer)

In practice most multiple schedule programs will extend over several command lines. However if these multiple Schedules are entered in single line format in successive command lines, each overwrites or replaces the last.

A multiple line command block or program format is used to enter multiple Schedules, which also improves readability of the application program.

DeTransfer provides for sending both single line commands (Send Line) and multiple line commands (Send All). Refer to the relevant documentation with these programs for details.

All the commands required to be entered which are distributed over more than one line must be placed between the keywords BEGIN and END.

Features and rules of the BEGIN ... END construct are listed below

each line between can be up to 250 characters long, and must be terminated by a carriage return

' text preceded by an apostrophe can be entered as comments

blank lines can be used to improve layout

commands which are executed on entry can be included

Schedules can be placed on lines without schedule lists

channels can be placed on successive lines without a schedule header, are included in the previous schedule. A carriage return must be between channel definitions or schedule headers.

when a BEGIN command is received, all schedules (including the alarm schedule RZ) are Halted, and existing RA, RB, RC, RD , RS and RX schedules are deleted.

The exception is when data logging is enabled, the schedules are fixed (/F), or there is data logged into memory. In these cases the BEGIN command is rejected, and an error message is returned.

when the END command is received , the original Halt - Go state of each Schedule is restored.

channels cannot be appended to schedules after the END command is issued. The full set of schedules must be re-entered.

Alarms, data format commands, system commands, etc. which are not a part of Schedules can also be placed between BEGIN ... END, although this is not mandatory

An example of a program using the BEGIN ... END construct in DeTransfer is shown below

BEGIN
      RA10S
            1TK("Oven Temp",FF1)
            2TK("Flue Temp",FF1)
            3..6TK("Product Temps",FF0)
      RB1S
            1C(S1,"Gas Flow")
            2C(S2,"Electricity")

END

where

on receipt of the BEGIN command all schedules are Halted and existing schedules deleted

the Repeat Schedule A comprises the six thermocouple channels

the Repeat Schedule B comprises the counter channels

on receipt of the END command the original settings for Halt -  Go are restored

note that tabs, spaces and blank lines can be used to improve layout and readability

Documenting Programs

Comments can be used in DeTransfer programs to describe the application, the intention of particular steps, etc.

The rules for comments in dataTaker programs are as follows

a comment is prefixed by an apostrophe (') character, and all text up to the next carriage return is treated as the comment

comments can be placed on separate lines

comments can be placed after commands on the same line

comments cannot be placed before commands on the same line

Examples of the use of comments in a program is illustrated below

'Boiler monitoring program for the dataTaker
'Author: Henry Higgins
'Created                  23/4/2003
'Last Modified     25/4/2003

CSCANS
CALARMS
CDATA

'Switch units text and channel numbers off
'Switch return of Time and Date on
      /u/n/T/D

'Define spans for Gas & Electricity
S1=0,50,0,100"M^3"
S2=0,20,0,1000"KW"

BEGIN              'Begin program
'Repeat Schedule A records temperatures
      RA10S
            4TT("Oven Temp",FF1)
            5TK("Flue Temp",FF1)
            3..6TK("Product Temps",FF0)

'Repeat Schedule B records Gas & Electricity
      RB1S
            1C(S1,"Gas Flow")
            2C(S2,"Electricity")

LOGON       'Log all channel to memory

END

Commands other than Schedule commands can be included between the BEGIN ... END commands, or can be placed outside of the BEGIN ... END commands. These include

Switches commands

Parameter commands

Span and Polynomial declarations

Alarm commands

System commands

Data Logging commands

Date and Time setting commands

Order of Data Returned from Multiple Scan Schedules

Whenever two or more Schedules are entered into the dataTaker, and these are simultaneously executing their respective, schedule lists, the data is returned to the host computer in the order

Immediate Scan Schedule
Repeating on Host Request     RX
Repeating Schedule A            RA
Repeating Schedule B            RB
Repeating Schedule C           RC
Repeating Schedule D            RD

This ordered return of data occurs irrespective of the order in which the Schedules were originally entered into the dataTaker.

If the Units Text Switch is enabled (/U) then a CR/LF character sequence is returned at the end of the block of data from each Scan Schedule.

If the Units Text Switch is disabled (/u) the block delimiter character defined by the Parameter24 Schedule is returned at the end of the block of data from each Scan Schedule.

Halting and Resuming Schedules

The Schedules can either be globally or individually halted and resumed by the Halt and Go commands

H       Halt all Data Schedules 
G       Resume all Data Schedules

HA     Halt Triggered Schedule A
GA     Resume Triggered Schedule A

HB     Halt Triggered Schedule B
GB     Resume Triggered Schedule B

HC     Halt Triggered Schedule C
GC    Resume Triggered Schedule C

HD     Halt Triggered Schedule D
GD     Resume Triggered Schedule D

HS     Halt Statistical Sub-Schedule
GS     Resume Statistical Sub-Schedule

When the dataTaker is initially powered up or executes the RESET command, all Schedules default to halted. This allows the dataTaker to sleep.

When Triggered Schedules are entered, they are automatically enabled at the time of entry which allows the Schedules to run at the next trigger.

Using DeTransfer, if a newly entered Schedule should not be enabled immediately, then a Halt command can be included as follows to hold the Schedule

BEGIN
 RAB10M  HB
  1..5V 8TK 1..2DS
END

A GA command is entered later when the Schedule is to be enabled.

Using DeLogger, Schedules can be initially held by checking the ‘Schedule halted until program downloadedí in the Schedule dialog of the Program Builder.

 

 

Combining Schedules

Schedules can be combined in various ways to provide greater flexibility to data acquisition tasks.

For example the data acquisition program

BEGIN
 RX             ëInspection
  1..6PT385
 RA1H           ëData collection
  1..6PT385
END

provides the flexibility of channel inspection where

the temperature channels will be read every hour according to the Schedule RA1H

the current temperature readings can be inspected at any time by entering a Poll Trigger command X

Re-Triggering Schedules

The triggers for the Schedules and Statistical Sub Schedule can be changed at any time by entering new Schedule commands without a schedule list.

Schedules with time triggers can be rescheduled to different time intervals, or can be rescheduled to digital or counter event triggering.

This feature is useful to test or verify a data acquisition system and sensor setup, preparatory to commencing any long interval or event initiated data collection.

For example, during a data acquisition system installation and test phase, the following Schedules could be entered from DeTransfer 

BEGIN
 RS5S
 RA1M
  1..5TK(AV)(MN)(MX)
 RB1M
  6..8V(AV)(MN)(MX)
END

where a short Schedule trigger of 1 minute is used.

When all adjustments are complete, the Schedules are rescheduled by the following commands to set the intervals appropriate to the requirements of the task.

RS5M  RA1H  RB3+E  LOGON

Rescheduling of running Schedules is not supported in DeLogger.

Synchronizing Schedule Time Triggers to Last Midnight

Time triggers for Schedules can be set to one of two real time modes

trigger intervals are relative to the time of entry of the Schedule

trigger intervals are synchronized to last midnight (Default)

The default mode is that Schedule time triggers are synchronized to midnight, and the schedule list is executed on every multiple of the interval since last midnight. For example a Schedule entered as follows

BEGIN
 RA1H
  1V 2R 3F 4TT
END

first executes the schedule list on the next hour since last midnight, and every hour thereafter.

Synchronization of Schedule time triggers is defined by the Synchronization Switch as follows

/S      Synchronize scans to midnight (Default)
/s      Disable synchronization of scan intervals

The Synchronization Switch defaults to /S after initial power up, or execution of a RESET command.

An unsynchronised Schedule is entered as follows

BEGIN
 /s
 RA10M
  1V 2R 3F 4TT
END

In this case the Schedule is first executed 10 minutes after entry, and every 10th minute thereafter.

Synchronized time triggers have various effects depending on the magnitude of the interval

when the synchronized interval is a multiple of 1 hour (eg. 30S, 10M, 20M but not 35M), then the intervals will also synchronize with each hour of the day

if a synchronized interval is not a multiple of 24 hours (eg. 50M, 7H, 13H), then the last interval before midnight will be less than the specified interval.
This enables the next interval to synchronize to 00:00:00 time at midnight.

Checking Entered Schedules

Schedules can be checked at any time by the STATUS command, which returns a summary of system status including a summary of the Schedules.

The system status is returned by the command

STATUS

which produces the response (when /U/N are enabled)

dataTaker 0 Version 7.00
A,none Scan Schedules Active, Halted
3,0 Alarms Active,Halted
3 Polynomial/Spans Defined
Logging is OFF
166530,0 Internal Data Points Free,Stored
81900,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

Specific details of the current Schedules is returned by the STATUS2 command

STATUS2

which returns a listing of the current Scan Schedules as follows

A B,D Scan Schedules Active,Halted
RA5M 1..4V(AV)(MN)(MX) 6..10TT
RB1H 1..4DS 1..4C
RD15M 5L(S2)

In this example there are three Schedules which have been entered into the dataTaker.

Two of these Schedules are currently enabled to execute (Active), and one Schedule has been paused by a Halt command (Halted).

Clearing Schedules from the Internal Channel Table

Whenever Schedules and schedule lists are entered into the dataTaker, the channels to be scanned are entered into an internal channel table. The internal channel table is limited to 110 entries, and is shared with the Alarms (See Section III ñ Alarms).

When the dataTaker is initially powered, hardware reset or executes a RESET command, the internal channel table initialises to 20 entries for Alarms and 90 for Data Schedules.

The allocation of the internal channel table between the Data Schedules and Alarms can be changed to suit particular needs (See Section III - Number of Channels for Schedules).

If any channels are already entered in the alarm or data acquisition sections of the channel table, then the channel table allocation cannot be changed. The channel table must firstly be cleared.

The section of the internal channel table that is allocated to the Data Schedules can be cleared by the command from DeTransfer 

CSCANS

This command will cause any current Schedules and execution to be aborted, and can also be used to stop all data acquisition tasks.

The CSCANS command is ignored if the Fix Channel Table Switch is enabled /F or if data is stored in the internal data memory.

The section of the internal channel table that allocated to the Alarms is cleared by the

CALARMS

command (See Section III ñ Clearing Alarms from the Internal Channel Table).

These commands are not supported by DeLogger.

Priorities for Returning and Logging Data

When data is simultaneously being logged to the internal data memory or a memory card, and is being returned to the host computer, the logging of data has priority over returning of data.

Following each scan of input channels, data is logged immediately, and then returned to the host if time permits. However if the next Schedule trigger occurs then returning of data is aborted and the new scan commences. If scanning is rapid, then there may be no time available to return real time data to the host computer.

Alternatively if the data is not being logged to the internal data memory or a memory card, then all data will be returned to the host computer. If the next Schedule trigger occurs before all data from the previous scan is returned, then the new scan trigger is ignored.

However this priority can be reversed if required, using the Data Priority Switch as follows

/Y      Return all data to host when data logging is enabled, ignoring new triggers
/y      Return data to the host when data logging is enabled only if time permits

The Data Priority Switch defaults to disabled (/y) following an initial power up, or execution of a RESET command.

Preventing Schedules from Waking the dataTaker

When the channels are being read or alarms are being processed at intervals of less than 2 seconds, then the dataTaker will not enter the low power mode or sleep mode.

Conversely whenever channels are being scanned or alarms are being processed at an interval of more than 2 seconds, then the logger will sleep between successive scans if other functions are not keeping it awake (if logger is battery powered, or Parameter15 is set to 1).

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

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

 

 

Figure 127 ñ Parameter20 Bit Map

 

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

The use of the Parameter20 command is illustrated by the following example

P20=8
BEGIN
 RA30M
  7..10TT
 RB30M
  1..5V
END

With Parameter20=8, the dataTaker sleeps and wakes according to the Schedule A, and only executes Schedule B while awake to executes Schedule A.

Any combination of Data Schedules and the Alarm Schedule can be disabled from waking the dataTaker.

Page Content


Home

Title and Waranty

Go to: Section 2 | Section 3

Section 1


Construction of the dataTaker 50

Construction of the dataTaker 500 600

Construction of the CEM

Getting Started

 

Section 2


Interfacing

Powering the dataTaker

Powering Sensors from the dataTaker

The Serial Interfaces

The RS232 COMMS Serial Interface

The NETWORK Interface

Analog Process

Connect Analog

Analog Chns

Measuring Low Level Voltages

Measuring High Level Voltages

Measuring Currents

Measuring 4-20mA Current Loops

Measuring Resistance

Measuring Frequency and Period

Measuring Analog Logic State

Measuring Temperature

Measuring Temperature with Thermocouples

Measuring Temperature with RTDs

Measuring Temperature with IC Temperature Sensors

Measuring Temperature with Thermistors

Measuring Bridges and Strain Gauges

Measuring Vibrating Wire Strain Gauges

The Digital Input Channels

Monitoring Digital State

The Low Speed Counters

The Phase Encoder Counter

The High Speed Counters

The Digital Output Channels

The Channel Expansion Module

Installing The Panel Mount Display

 

Section 3


Programming the dataTaker

Communication Protocols and Commands

Entering Commands and Programs

Format of Returned Data

Specifying Channels

The Analog Input Channels

The Digital Input Channels

The Counter Channels

The Digital Output Channels

The Real Time Clock

The Internal Channels

Channel Options

Schedules

Alarms

Scaling Data - Polynomials, Spans and Functions

CVs Calcs and Histogram

Logging Data to Memory

Programming from Memory Cards

STATUS RESET TEST

Switches and Parameters

Networking

Writing Programs

Keypad and Display

Error Mess Text

Appendix A - ASCII

Appendix B - ADC Timing