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

Writing dataTaker Programs

The dataTaker 50, dataTaker 500 and dataTaker 600 series data loggers have an extensive and powerful command set which allows you to easily develop programs for both simple and sophisticated tasks.

This command set, combined with the range of different measurement capabilities of the dataTaker, allows the logger to be used in a wide variety of applications.

Programming style only applies if you are programming your dataTaker from DeTransfer, or other terminal emulation or communications software. Some third party data collection software packages may require that you develop the dataTaker program separately as a text file, which the application simply transmits to the logger.

If you are using DeLogger, then you can skip this chapter.

Style of Programming 

The success or otherwise of your dataTaker application generally reduces to the way in which you have written your program.

There are only a few simple rules for program structure, and there is considerable flexibility to allow individuals to develop their own styles.

After writing many different programs for the dataTaker this author has adopted a general style which makes programs easier to initially develop and later to interpret. While the following is not intended to dissuade others from developing their own styles, it may help in the development of those styles.

Planning the Program

Before writing a program, you should first plan your program by working through the following steps

make sure you fully understand what the dataTaker is required to do, what sort of data you require, how you want it presented, etc. A flowchart will be helpful later.

make sure that you are fully aware of the various sensor(s) you will be using including
          - whether these fulfil your needs
          - how the sensors are connected to the dataTaker
         
- which if any channel options are required to support the sensors
          - whether linearization is required, and if so in what form are the calibrations provided, etc
          - preferably make test readings from each sensor so that later you can be confident that the
            sensors are not the cause of unexpected results.

if you intend to use calculations, also decide at this time how many channel variables you will require for each Schedule (don't be afraid to over-estimate), and allocate channel variables in blocks of say 10 consecutive variables to each Schedule (ie. 1..10CV for Schedule A, 11..20CV for Schedule B, etc.). This will allow you to easily recognise later which variables belong to which schedules.

if you intend to use alarms, also decide at this time what the setpoints will be and what actions you require in response to alarm states.

Writing the Program

The overwhelming temptation is to write a dataTaker program from the 'top down', however the best approach is to write programs from the core outwards as follows

1. Firstly enter a BEGIN and an END on successive lines. These will eventually bracket the Schedules, input channel declarations, calculations and alarms that will make up the core of the program.

2. Between BEGIN and END insert the schedule(s) required, in terms of the trigger interval and method of triggering, etc.

If there is more than one Schedule then insert these on separate lines and indented two spaces. If necessary add comments to the right of the Schedules to describe their purpose.

3. Then add the channels to be scanned to each schedule, including any channel options necessary to instruct the dataTaker how the signal is to be measured, and how the data is to be used, etc.

If there is more than one channel in each schedule then insert these on separate lines below the schedule and indented four spaces. If necessary add comments to the right of the channels.

4. Then add any calculations that you require to the Schedule(s). Generally program flow is such that you will collect the channel data first, and then process the data with calculations. Therefore calculations will usually follow the channels in each Schedule.

5. Then insert any alarms that are required to monitor input channels for out of range conditions, and define the Alarms Schedule if continuous monitoring is not required. Generally these commands can be inserted following the last Data Schedule, however this is not mandatory.

6. This completes the core of the program, and all that remains is to include initialization commands required, global data formatting required, and the data logging command if required.

7. Immediately above the BEGIN statement, insert any initialization of channel variables required.

8. Immediately above these commands, insert the sensor calibration polynomial and span declarations if any are required.

9. Above these declarations insert Switch and Parameter commands required to determine the global data format.

10. At the top of the program insert the RESET command, followed by a delay period. DeTransfer will pause for the delay period when sending the program to the logger, allowing time for the dataTaker to execute the RESET command. A delay period of 5 seconds is usually sufficient time for a reset to execute.

Using a RESET command at the top of the program is strongly recommended, because the logger will then have a predictable configuration for receiving the new program.

11. Above the RESET command insert a delay period of one second, which will ensure that the logger wakes (if asleep), and is ready to receive the following program.

12. Following the END command, insert the data logging commands if required.

13. Finally insert any global or schedule Halt and Go commands as required.

14. Add comments throughout the program to document your intentions. Remember to make your comments ëmeaningful to an audience, not just to yourselfí, because either you or others may have to interpret your program months or years later.

15. Keep a folder of all documentation, sensors, calibrations, wiring configurations, etc. for the project / program.

The program skeleton illustrated overleaf embodies the general program outline described above

Wait for dataTaker to wake

RESET the dataTaker
Wait for the dataTaker to RESET

Data format definition

Sensor calibrations

Channel variable initialisations

BEGIN
  First scan schedule
    Channels
    Calculations

  Second scan schedule
    Channels
    Calculations

  Alarm
  Alarm
  Alarm
END
Data logging commands

Go and Halt commands

BEGIN ... END

In practice most multiple schedule programs will extend over several command lines. If Schedules are entered on successive command lines, then each overwrites or replaces the last.

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

All of the commands required to be entered which are distributed over more than one line must be placed between the keywords BEGIN and END. The rules of the BEGIN ... END construct are listed below

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

blank lines can be used to improve layout

commands which are executed on entry can be included

Schedule Triggers can be defined on lines without channel lists

channels can be placed on successive lines without a Schedule header, and are included in the previous Schedule.

Channels on separate lines are placed into the last defined Schedule. If there is no Schedule defined then the channel is scanned immediately in an Immediate Schedule.

when a BEGIN command is received, all of the Schedules including the Alarm Schedule RZ are Halted, and any 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.

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

The action of the BEGIN ... END construct is illustrated 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 all existing schedules deleted

the Schedule A comprises the six thermocouple channels

the Schedule B comprises the counter channels

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

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

DeTransfer provides for sending of single line commands (Send Line) and multiple line commands (Send All). Refer to the DeTransfer help for these details.

Commands Executed on Entry

With the exception of the Triggered Schedules alarms, all other commands are executed on entry. This is irrespective of whether these commands are entered outside of BEGIN . . . END, or between BEGIN . . . END .

Commands which are executed on entry include Switch commands, Parameter commands, Polynomial and Span declarations, and all system commands.

The Immediate Schedules are also executed on entry, which is a very useful programming tool (see below).

Commands that are executed on entry are only executed once, and never execute again for the life of the program.

Use of Immediate Scan Schedules

The Immediate Schedules are executed on entry, irrespective of whether the commands are entered outside of BEGIN . . . END or between BEGIN . . . END. The channels and expressions in the Immediate Schedule are only executed once, and only at the time of entry.

Care must be used when placing Immediate Schedules between BEGIN . . . END to ensure that they don't inadvertently become associated with Triggered Schedules.

For example

BEGIN
  1V 2V
  RA5S 5TT
END

in this case the channels 1V and 2V will be executed on entry as an Immediate Schedule

BEGIN
  RA5S 5TT
  1V 2V
END

in this case the channels 1V and 2V will be attached to the Schedule A.

Initialization of Channel Variables are in fact Immediate Schedules. These may be placed above the BEGIN Command (preferred), or after the BEGIN Command but before the first Triggered Schedule,

For example in the program

1..5CV(W)=0.0
BEGIN

END

the Channel Variable assignments are interpreted as being within an Immediate Schedule, and are initiated at the time of entry.

When Immediate Schedules are used as actions within Alarms, then the schedule is executed whenever the alarm becomes true. For example

ALARM3(5TT>150)"[21CV(W)=4.75]"

the assignment to the Channel Variable on each true alarm state is executed as an Immediate Schedule. However each invocation of the assignment is a newly entered Immediate Schedule, and not a re-running of an existing Immediate Schedule.

This is important to understand since there may be other Immediate Schedules executing from elsewhere in the program between successive invocations of the action command for this alarm.

Association of Channels to Schedules

Channels can be placed on successive lines between BEGIN . . . END without a Schedule definition on the same line. Each channel declaration is processed as follows

the channels are placed into the last defined Triggered Schedule

if there is no Triggered Schedule defined before this point in the program, the channel is placed into an Immediate Schedule and is executed immediately

Documenting Programs

Comments can be used in programs to describe the application, the intention of particular steps, etc. The rules for the use of 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

in DeTransfer, comments can also be preceded by \í, which signifies not to transmit the comment

 

 

 

 

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")

END                       'End of program

LOGON       'Log all channel to memory

A Program Example

The following program illustrates a dataTaker program in which the programming styles discussed above have been used.


'WIND_SET.DXC
'Program for monitoring a wind set and calculating the
'    - mean wind speed
'    - mean wind direction
'    - standard deviation of wind speed
'    - standard deviation of wind direction

'The anemometer has output of 0-1000 mV for 0-50 m/s windspeed
’The wind vane has output of 0-1000 mV for 0-360 deg direction

'Reset the dataTaker
RESET
\w5

'Synch the dataTaker clock to host computer clock
D=\d
T=\t

'Enable date and time stamps
/D /T

 


'Define the wind sensor calibrations (Polynomials)

Y1=0,0.050"m/s"       'Wind speed, 0-1000mV = 0-50 m/s
Y2=0,0.360"Deg"       'Wind direction  0-1000mV = 0-360 deg

'Define units for calcs (Polynomials with unity scaling)
Y3=0,1"m/s"           'Units text for wind speed
Y4=0,1"Deg"           'Units text for wind direction

'Clear accumulators used to sum intermediate data
10..16CV(W)=0

'Pause while the dataTaker completes initialisations
\w1

BEGIN
 'Schedule reads wind set and sums data every 5 seconds
 RA5S
  1V(Y1,=1CV,W)       'Scan wind speed and save
  2V(Y2,=2CV,W)       'Scan wind direction and save
  2CV(W)=2CV/57.29    'Convert wind direction to radians for
                      'dataTaker trig functions

  10CV(W)=10CV+COS(2CV)          'Sum of COS(wd)
  11CV(W)=11CV+SIN(2CV)          'Sum of SIN(wd)
  12CV(W)=12CV+1CV               'Sum of ws
  13CV(W)=13CV+(1CV*1CV)         'Sum of ws * ws
  14CV(W)=14CV+(1CV*COS(2CV))    'Sum of ws * COS(wd)
  15CV(W)=15CV+(1CV*SIN(2CV))    'Sum of ws * SIN(wd)
  16CV(W)=16CV+1.0               'Number of scans

 'Schedule to calc wind data every minute
 RB1M
  20CV(W)=14CV/16CV              'Mean ws * COS(wd)
  21CV(W)=15CV/16CV              'Mean ws * SIN(wd)

  'Calculate mean wind speed
  22CV(W)=SQRT((20CV*20CV)+(21CV*21CV))
  22CV("Mean Wind Speed",Y3,FF2)

'Calculate mean wind direction
  23CV(W)=ATAN(21CV/20CV)*57.29

  'Find quadrant for mean wind direction
  23CV(W)=23CV+((20CV>0)AND(21CV<0))*360     '4th quadrant
  23CV(W)=23CV+((20CV<0)AND(21CV<0))*180     '3rd quadrant
  23CV(W)=23CV+((20CV<0)AND(21CV>0))*180     '2nd quadrant
  23CV(W)=23CV+((20CV>0)AND(21CV>0))*0       '1st quadrant

  23CV(W)=23CV-(12CV=0)*(23CV+1)    'No wind speed, return -1.0

  23CV("Mean Wind Dirn",Y4,FF2)

  'Calculate standard deviation of wind speed
  24CV(W)=13CV-((12CV*12CV)/16CV)
  24CV(W)=SQRT(24CV/16CV)

  24CV("SD Wind Speed",Y3,FF2)

  'Calculate standard deviation of wind direction
  25CV(W)=10CV/16CV
  26CV(W)=11CV/16CV
  27CV(W)=SQRT((25CV*25CV)+(26CV*26CV))
  27CV(W)=SQRT(-2.0*LN(27CV))*57.29

  27CV("SD Wind Dirn",Y4,FF2)

  'Clear accumulators
  10..16CV(W)=0

END

LOGON

G


 

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