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
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.
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.
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
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.
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
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.
in this case the channels 1V and 2V will be executed on entry as an Immediate Schedule
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
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
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
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
A Program Example
The following program illustrates a dataTaker program in which the programming styles discussed above have been used.
'Calculate standard deviation of wind speed
'Calculate standard deviation of wind direction