Introduction

System Requirements

  • LabVIEW™ base package minimum, version 8.2.1 or later.
  • dataTaker DT80 range data logger.
  • If communicating to a dataTaker data logger via a PC serial port (except PPP), NI-VISA™ is required.

Installation

To install the driver, extract the file, DT8xDRIVER.ZIP to the relevant user.lib folder in the LabVIEW program directory.

The file, DT8xDRIVER.ZIP can be downloaded from our website http://www.datataker.com/downloadsDT80.php
or from the LabVIEW section of our website http://www.datataker.com/LabVIEW.php

After you start LabVIEW, the contents of this directory are located on the Functions>>User Libraries>>dataTaker DT8x Driver palette.

    top level palette

After you have successfully installed the dataTaker DT8x Driver, the following folders will have been added to your hard drive:

…\LabVIEW (8.2)\user.lib\DT8xDRIVER
The main directory of the dataTaker DT8x Driver.

…\LabVIEW (8.2)\user.lib\DT8xDRIVER\documentation
The directory containing the help file for the driver.

…\LabVIEW (8.2)\user.lib\DT8xDRIVER\examples
The directory containing the examples included with the driver.

There are many directories and files within the driver, which can easily be navigated through the functions palette.

NOTE : The driver has been written for LabVIEW later than verion 8.2.1, so the LabVIEW directory will reflect the version number.

Overview

The dataTaker DT8x Driver is a comprehensive library of VIs that allows dataTaker DT80 range data loggers to be configured and queried from LabVIEW.

For users familiar with LabVIEW, the dataTaker DT8x Driver for LabVIEW offers a classic data logger hardware alternative for data acquisition. Data loggers can be used as an alternative to plug-in PC cards for real-time data acquisition, but are best suited to applications that require stand-alone operation in remote or distributed locations where power supply may be limited.

For users familiar with dataTaker hardware, the dataTaker DT8x Driver provides a means to incorporate dataTaker data loggers in applications that require an open, programmable software environment, and/or a mix of dataTaker and other I/O hardware. LabVIEW is National Instruments’ industry-leading graphical software development environment for measurement and automation applications.

Driver Version

The version of the driver can be determined from the release notes.txt file located in the user.lib\DT8xDRIVER folder after the driver has been installed.

The release notes.txt file will contain "dataTaker DT8x Driver RELEASE NOTES for version 1.00".

User Background

The dataTaker DT8x Driver is targeted at users that have at least a basic familiarity with the concepts and terminology of both the LabVIEW and dataTaker environments.

Experienced dataTaker users who are new to LabVIEW would need knowledge of LabVIEW to the level of the National Instruments’ course “LabVIEW Basics I”, or equivalent.

Experienced LabVIEW users with no previous exposure to dataTaker hardware can use the library to connect to a dataTaker data logger and acquire real-time data, or return historical data, from a previously configured acquisition schedule. To properly use all high, intermediate and low level library functions requires a working knowledge of the dataTaker data logger. Please refer to the appropriate dataTaker user’s manual for additional details and specific information about each model.

Configuring your data logger

A data logger is a stand-alone hardware device that is designed to acquire and store multiple channels of data in on-board or removable memory. Data is often acquired over long periods of time (months, or even years), in remote or otherwise hostile locations where power supply may be limited. Data can be read from the data logger via a host PC in real-time as it is acquired, but is most often stored in memory and transferred to the host PC via a direct communications link or a flash memory card. Data may be transferred at regular periods, or irregularly, as and when circumstances allow.

The list of channels sampled, their logging rate, scaling, alarm conditions and other functions, are determined by a simple program or script(a "Job" in dataTaker terminology). This is typically composed on a host PC and downloaded and stored in the logger’s on-board memory. The composition and downloading of the program is typically performed via a dedicated configuration program, or an ASCII terminal window.

The dataTaker DT8x Driver allows arbitrarily complex tasks to be programmatically assembled and downloaded to the dataTaker from a LabVIEW VI. All major functions of the dataTaker can be configured from LabVIEW if required. For users who are not expert with the dataTaker command language, the Library provides for automatic generation of program strings in the correct format using simple point and click operations.

Users who are familiar with the dataTaker command language can bypass the string format Wizards and enter all program strings manually when configuring a dataTaker from LabVIEW. However we expect that many experienced dataTaker users will continue to configure dataTaker data loggers using the configuration tools they are already familiar with, using the driver primarily to provide a programmable GUI for retrieving data from a previously configured device.

Either approach is OK. Use the best mix of LabVIEW and your existing dataTaker tools to achieve your objectives.

Driver Structure

The dataTaker DT8x Driver follows standard LabVIEW conventions in designing I/O libraries. In particular, it is similar in its functional approach to the way that the National Instruments’ NI-DAQ driver for plug-in data acquisition boards is organised. The driver palette is organised in three levels – High (or Easy), Intermediate, and Low (or Advanced). Each palette in the driver includes the relevant function VIs, including one or more examples showing how they should be used. Some palettes also contain sub-palettes of standard controls. These standard controls are resources used by the driver VIs, and should not normally be used directly, or modified, by an end-user.

The Intermediate level VIs are built from the Low level VIs. The High level VIs are built from combinations of Intermediate and Low level VIs. As a general rule, you should aim to work at the highest level in the hierarchy that achieves the objectives of your application. The lower level functions give you more power and direct control at the expense of programming complexity.

The high level palettes provide “single VI” solutions to the task of retrieving real-time or historical data from a dataTaker data logger. The high level VI’s handle any required temporary configuration of the data logger automatically, these changes being transparent to the user.

The intermediate level palettes are also used for retrieving real-time or historical data from a dataTaker data logger. Like the High level palettes, any temporary configuration of the data logger required is handled automatically by the Intermediate level VI, and is transparent to the user. Unlike the high level palettes, Intermediate VIs are NOT “single VI” solutions. A series of Intermediate level VIs is used in a specific sequence to achieve the required outcome. The major benefits of working at the Intermediate level are more direct programmatic control of the timing and execution of each function, along with higher throughput of real-time data.

Both the High level and Intermediate level palettes contain three separate, but functionally identical, sub-palettes for communicating with dataTaker data loggers. This can be via TCP/IP or direct serial. You should use the palette that corresponds with the type of communications link that you are making to your data logger.

The Low level palettes contain the basic function blocks that allow a user to any of the following:

  1. Open and manage a communications link to a dataTaker data logger.

  2. Read data from any configured dataTaker data logger.

  3. Compose and download complete Jobs including Schedules, Channel Descriptors, Alarms, Channel Options.

  4. Perform specific configuration and management functions as required (eg retrieve the dataTaker version, wake up a dataTaker from sleep mode, synchronise time between the host PC and dataTaker, etc).

The Low level sub-palettes are grouped by logical function, and NOT according to the type of communication link.

High Level (HL) VIs

Work with the High (or Easy) I/O level VIs if you simply need to do any of the following:

  1. Retrieve historical data from a data logger that has been previously configured with an active Job.

  2. Acquire real-time data from a data logger that may NOT have been previously configured with an active Job.

There are two nearly identical sub-palettes at the High level, differing only in the mode of connection to the dataTaker (direct serial, or TCP/IP). Use the sub-palette that matches the type of connection that you are making to your dataTaker.

Each sub-palette includes six (6) functional VIs, and a separate palette of example programs. Two (2) of the functional VIs are used to retrieve historical data that has been logged to on-board memory by a previously configured Job. Four (4) of the functional VIs are used are used for retrieving data in real-time as it is acquired. They allow the user to configure and download an “Immediate” Schedule.

Each functional VI may be called once to return a single data point or block of data points from each nominated channel, or called repeatedly in a loop to provide a continual update of historical or real-time data. Each call to a VI involves:

  1. Opening a connection to the data logger.

  2. Configuring the dataTaker with an “Immediate” Schedule (if required, real-time functions only).

  3. Retrieving the requested data.

  4. Closing the connection to the data logger.

The two (2) historical functions return all unread data in on-board memory that is derived from the currently active Job. One returns all unread data from all active channels. The other returns all unread data from a single specified channel. Repeated calling of these VIs (at a regular or irregular interval) will result in all historical data being transferred from on-board memory to the host PC in sequential blocks.

The four (4) real-time functions configure and download an “Immediate” Schedule to the data logger retrieving data as it is acquired. In this mode the data logger is acting like any other real-time acquisition device, and you may or may not be making use of its ability to log the data on-board. Most experienced LabVIEW users would normally use the host PC to process and log data in this mode.

The two (2) real-time channel VIs return single points of data from the nominated channel(s). The two (2) real-time waveform VIs return blocks of data containing a user-specified number of points, acquired at a user-specified rate, from the nominated channel(s). The “Immediate” Schedule that is created by these VIs returns raw channel data only. To programmatically create “Immediate” (or historical) Schedules that include units, scaling and other channel options you must use VIs from the Low level palette.

Intermediate Level (IL) VIs

Like the High level VIs, the Intermediate level VIs are used to do any of the following:

  1. Retrieve historical data from a data logger that has been previously configured with an active Job (using the historical functions).

  2. Acquire real-time data from a data logger that may NOT have been previously configured with an active Job (using the real-time functions).

Unlike the High level VIs, several Intermediate level VIs must be used in a specific sequence to retrieve the data. By separating the functions for communications, configuring the “Immediate” Schedule (if required) and reading the data, you have more control over when, and under what conditions each function is called. For example, by opening communications once, and making repeated calls in a loop to retrieve the data, you reduce the communications overhead and increase data throughput.

Low Level (LL) VIs

The Low (or Advanced) level VIs are grouped into three logically connected sub-palettes (not by connection type).

  • The Low level Comms palette provides direct access to the functions that handle serial and TCP/IP packets. These functions would only rarely (if ever) need to be accessed by end-users.

  • The Low level Utilities palette contains a collection of VIs for setting or querying various aspects of the dataTaker’s configuration. It includes VIs for the following:

    1. Waking a data logger from low power (sleep) mode.

    2. Synchronising the data logger time to the host PC time.

    3. Returning the data logger version.

    4. Reading the data logger “Data Map”. This allows a user to determine the nature and format of any data stored by the currently active job without detailed knowledge of the job itself.

    5. Extracting data from the Data Map. This function uses the Data Map returned from item 4. to parse the data from on-board memory.

  • The Low level general palette includes all the generic tools for:

    1. Configuring the communications type and port.

    2. Opening a communications link.

    3. Reading Schedule or Job data from a data logger.

    4. Writing (ASCII) data/commands to a data logger*. Experienced dataTaker users can use this function to programmatically download any valid command to a dataTaker data logger, including those commands not currently supported by the driver at a high level.

    5. Closing a communications link.

    6. Creating correctly formatted data logger commands/strings for configuring Channels, Schedules, Alarms, and Channel Options, via a “point and click” interface. This allows users who are not experienced with the dataTaker command language to generate correctly formatted commands for most major operations;

    7. Attaching Channel Schedules and Channel Options to a multi-schedule string*.

    8. Creating, downloading, and starting complete Jobs that include multiple Channel and Alarm Schedules*.

    *Less experienced dataTaker users would use the output command strings from item 6. as inputs to these functions. Experienced dataTaker users could directly enter any valid command string as an input.