| The driver provides digital and analog values of input/output modules of DataLab IO4 and DataLab IO1 devices to the Control Web application or to any application capable to communicate with Active X components. |
Moravian instruments, Inc., source: https://www.mii.cz/art?id=138&lang=409, printed: 30.04.2025 22:02:18
Main page▹Products▹DataLab industrial input/output system▹DataLab - Industrial input/output devices | 28.2.2019 |
|---|
| The driver provides digital and analog values of input/output modules of DataLab IO4 and DataLab IO1 devices to the Control Web application or to any application capable to communicate with Active X components. |
|
Contents of section:
Channel data types (either numbers representing analog values or two-state logical values) and directions (either inputs or outputs) are defined by the module types plugged to individual slots of the particular unit. It is necessary to define used module types in the driver parameter file to enable application development. The driver creates a set of channels of appropriate type and direction for each module according to module type. Channel numbers associated to used modules are freely selectable, but always must create a continuous range. So it is possible to choose only the number of the first channel, other channels are numbered automatically up to the total number of channels available in the module. Channel numbers assigned to individual modules cannot overlap. If the particular module provides both input and output channels, channel numbers can be assigned independently for both channel groups —number of the first input channel is defined independently on the number of the first output channel. If the module type plugged to device slot does not correspond to the module type define in the parameter file, the driver detects it and any attempt to read or write to channel of the particular module causes error (see chapter Driver specific error codes). No other configuration (e.g. unit addressing, communication speed, parity, handshake, stop-bits settings etc.) is required due to the USB interface used in the DataLab IO units. The system works in the pure Plug-and-Play manner. Remark: The driver requires Windows 2000 (the Windows NT v5.0) and higher versions—e.g. Windows XP (the Windows NT v5.1). Windows versions lower than 5.0 do not contain APIs necessary to run the driver. But the robustness and reliability, required in the industrial applications, is provided only by the Windows NT based operating systems either way. So the necessity to use Windows NT to run the driver should cause no problems. The DataLab IO driver for Control Web relies on the DataLab IO system driver (see chapter DataLab IO system driver). It is not possible to communicate with the device over USB without properly installed system driver. Connecting multiple DataLab IO devices to single computerIt is possible to connect multiple DataLab IO devices to single computer, be it directly to USB ports available on the computer I/O panel or through the USB hub. The operating system assigns unique name to every connected USB device. The name is rather complex string derived from the device driver GUID, USB hub identifiers, USB port number on the particular hub etc. Simply put, these identifiers are intended for distinguishing USB devices within operating system, not to be used by computer users. But if the application communicates with multiple DataLab IO devices, it is necessary to distinguish them—the concrete signal wired to concrete terminal port of the concrete module must be properly identified in the application. The device serial number is used identify devices. The serial number is always printed on the label on device case and is necessary to write it as parameter id of section [device] in driver parameter file. It is necessary to use one driver instance for every DataLab IO unit. One driver instance (with corresponding one parameter file) cannot handle multiple units at once. Warning: It is necessary to define the id parameter not only when single application uses multiple devices, but always when multiple DataLab IO devices are connected to one computer. If the id parameter is not defined, the driver uses the first device it finds. Sometimes it can be necessary to obtain device identifier in running application. The driver offers special input channel, from which the device identifier can be read (its number is defined by the parameter id_channel of section [device] in the parameter file). Driver exceptionsThe driver generates exceptions always when its state changes. The application (the virtual instrument within application) can handle these exceptions (virtual instrument is activated when the driver exception occurs if its parameter driver_exception contains particular driver name). The exception handling procedure can read the driver status channel to determine device state. An example of the indicator instrument, which handles DataLab IO driver exception and switches on or off according to the device state is in the chapter Driver status channel. Driver status channelThe status channel (its number is defined by the parameter status_channel of section [device] in the parameter file) provides the DataLab IO device status information. Currently only one bit number 0 is defined—it represents the “connected” status (that means if the device is connected to the USB port and properly powered). If the DataLab IO device is unplugged (or without power in the case of self-powered devices), the status channel is the only channel which can be read without error. An attempt to read any other channel will generate error 1. Status channel value should be interpreted as bit mask. It is always necessary to check only the particular bit of interest. Undocumented bits represents other states and their meaning can change in different driver versions. It is possible to use function bitget or operator and to extracting just one bit from the number. The following example demonstrates how to read DataLab IO “connected” state and how this state is represented by indicator instrument. This example assumes that there is a parameter status_channel = 99 in the [device] section in parameter file. driver
datalab : 'dldrv.dll', 'DataLab USB test Analog In.dmf', 'DataLab USB test Analog In.par';
end_driver;
data
channel {driver = datalab; direction = input};
...
dlStatus : longcard {driver_index = 99};
end_channel;
...
end_data;
instrument
indicator ConnectionStatus;
driver_exception = datalab;
...
procedure OnActivate( ByTimer, ByInstrument, ByDriver, ByData : boolean );
begin
if ByDriver then
(* mask bit 0 by logical and with mask 1 *)
SetValue( dlStatus & 1 <> 0 );
(* it is possible get the bit using bitget function, the second parameter is bit index, not mask
SetValue( bitget( dlStatus, 0 ) <> 0 );
*)
end;
end_procedure;
...
end_indicator;
...
end_instrument;
Driver parameter fileDriver parameter file is an ordinary text file and can be edited by any text editor (e.g. Control Web Editor or Notepad). It has very simple structure following '.INI' file conventions. Section [device]If there are multiple DataLab IO units connected to one computer, it is necessary to specify for which unit is the particular parameter file intended. The parameter id of section [device] defines the particular unit. Parameter value is a number or list of numbers separated by commas. If the parameter is present, the driver instance (with this parameter file) will work only with the DataLab IO of the serial number defined as id. The syntax of parameter is id = number,number,..,number. If there is only one device connected to the computer, this parameter is optional and can be omitted with the whole [device] section (if no other parameter of [device] section is used, of course). Hint: The number list can be used when the DataLab IO device should be replaced by another device without stopping of the application and editing the parameter file. The list then should contain the serial numbers of both primary and the backup devices. The number of devices in the list is not limited. If the status channel is required by the application, its number must be defined by the parameter status_channel in the [device] section. If the parameter file defines this channel, it is necessary to define this number in '.DMF' file as input channel of type longcard. The status channel is described in the Driver status channel chapter. Also the channel returning DataLab IO identifier number can be defined in the [device] section. The identifier channel number must be defined by the parameter id_channel. If the parameter file defines this channel, it is necessary to define this number in '.DMF' file as input channel of type longcard. It is also possible to define logical parameter reset_outputs in the [device] section. If the parameter is true (reset_outputs = true), all output channels are reset to their initial state (the sate in which channels are when the device is powered on) when the application is terminated or when the host PC (or connection to host PC) fails. Module sections [module_x]Every I/O module, plugged into the device, must have a section in the parameter file named according to the device slot (see chapter Module positions and device slots). Sections names are in square brackets : [module_a] to [module_d]. There are two mandatory parameters in each section: module_type and first_channel. Other parameters (control_channel and mode) are optional.
DataLab IO1 has only one module slot, which corresponds to position A. The parameter file for DataLab IO1 should contain only one module section [module_a]. Remark: Numbers in parameter file can be written not only in decimal format, but also in binary and hexadecimal notation. Numbers in binary notation should be followed by letter “B”, numbers in hexadecimal notation should be followed by letter “H”. Example of hexadecimal and binary notations: mode = 0A012C0FH mode = 00001001B Parameter file example: [device] id = 1234567 status_channel = 1 id_channel = 2 reset_outputs = true [module_a] module_type = DI1 first_channel = 100 mode1 = AC mode2 = AC [module_b] module_type = DO2 first_channel = 108 control_channel = 120 [module_c] module_type = AO1 first_channel = 200 unit = V unit1 = A unit2 = A unit3 = A unit4 = A [module_d] module_type = CNT1 first_input_channel = 300 first_output_channel = 310 control_channel = 320 mode1 = enable mode2 = enable mode3 = enable mode4 = enable Channels and modes of individual module typesEvery module (depending on its module type) provides channels for reading or writing of values. Some module types offer control channel and/or mode. Channel types, directions, control channel functions and modes for various module types are as follows: Digital input modules DI1 and DI2
Digital counter module CNT1The module contains 4 counters with 24 bit range (numeric range of every counter is 0 to 16,777,215). First two counters have more configuration options compared to the second pair of counters (last two counters are limited to simple counting with the possibility to preset their value). Counter modes (e.g. counting enabled/disabled, logical levels etc.) are defined by setting module mode or by writing to module configuration channel.
Functionality of the first two counters (counters number 0 and 1) can be more complex:
Counter configuration can be written to the output channel No. 6 Config, to the control channel (control_channel) or can be defined as the module mode parameter. Configuration value is 4B long unsigned integer. Every byte contains configuration of one counter, the less significant byte contains configuration of counter 0, the most significant byte contains configuration of counter 3. Every byte meaning is defined by the bitmask according to the following table:
Individual counter configuration Remark: The shift of the configuration byte of counter N can be performed by its multiplying by number 256 powered to N. For instance configuration, which enables all four counters, has a value 1 + 1 × 256 + 1 × 2562 + 1 × 2563 = 16,843,009. However, the better way is to use the possibility to write binary or hexadecimal numbers in parameter file. The above example can be written simply as a hexadecimal number 01010101H. Mode can be defined also for every channel individually: mode1 = 1001B mode2 = 1011B mode3 = 101B mode4 = 101B Alternative way to define mode is using a list of keywords:
Modes from the previous example can be defined as follows: mode1 = enable, test_gate mode2 = enable, falling_edge, test_gate mode3 = enable, reset_on_read mode4 = enable, reset_on_read Incremental counter module CNT2The module contains 1 incremental counter 1 with 32-bit range (numerical range is from -2,147,483,648 to 2,147,483,647). The counter is able to decode quadrature modulation from position/angle sensors as well as to work in up/down and step/direction modes. The counter is also capable to preset counter value and capture value according to logical inputs and to signal alarm outputs if the counter value underflows low limit or overflows high limit.
Counter configuration can be written to the output channel No. 4 Config, to the control channel (control_channel) or can be defined as the module mode parameter. Configuration value is 32-bit integer number. Individual bit meaning is defined in the following table:
Bits meaning in incremental counter configuration The counter is capable to handle three input signal types, depending on its function. Counter function is defined by configuration bits 8 and 9 as follows:
Remark: The possibility to write values in parameter file in binary (number terminated by character “B”) or hexadecimal (number terminated by character “H”) notation can be advantageous when specifying modes. For instance the line: mode = 11001000001100B configures the incremental counter to step/direction mode, inverts both A and B inputs, enables preset and capture inputs and disables alarm underflow and overflow outputs. Alternative way to define mode is using a list of keywords:
Mode from the previous example can be defined as follows: mode = step_direction, enable_preset, enable_capture, invert_a, invert_b Digital output modules DO1, DO2 and DO3
Remark: The driver does not distinguish if the connected module is e.g. open-collector output module or relay output module. However, it can be necessary to distinguish them on the application level—e.g. the switching speed of the relays is much lower than the speed of transistors and application must take it into account. Analog input module AI1Remark: The AI1 module is discontinued and the driver supports it only to maintain backward compatibility.
There are a small array of jumpers on the module printed circuit board (PCB), associated with every input channel. Jumper configurations are described in the module technical documentation. Basically, jumpers define two settings:
So the actual input range depends on the mode of analog inputs (defined by the parameter mode in parameter file and/or by control channel write) and also on the BIAS jumpers position. Hint: While the mode can be set for the whole module only (for all 8 channels), jumpers can be set independently for each channel. Every channel can be configured to measure voltage or current and every channel can have input range multiplied 4 times by BIAS jumpers. It is also clear that while the jumpers can be set only while the unit is unplugged fro USB and not powered, the mode can be changed programmatically. But thanks to Plug and Play features of DataLab IO it is not necessary to stop the application—the device can be unplugged, jumpers can be altered and the plugged again. Input voltage ranges of individual modes for both BIAS jumper positions are:
Input ranges of analog inputs The BIAS column represents BIAS jumper positions on the module PCB. Values “Max. voltage between inputs” a “Full range” needs a brief explanation:
Hint: Ranges 10 V and 5 V can be measured when BIAS is on (modes 2 and 3) or off (modes 0 and 1). Due to ADC internal workings and signal filtration it is always better to use highest input ranges. It is recommended to configure BIAS off and use modes 0 and 1 for these ranges. Analog input module AI2
There is a jumper on the module PCB associated with every input channel. Closing the jumper causes a precision 120 Ω resistor is inserted into the input, which changes voltage input into the current one. Hint: Input ranges can be defined for every input channel independently by the application program. But the voltage or current mode is selected by jumper on the PCB and this cannot be performed on application runtime. The AI2 module allows not only input range setting for individual inputs, but also allows switching each input off. Skipping of particular input speeds up the sampling frequency of remaining inputs. The module is able to sample data at frequency 50 Hz (50 samples per second) on one channel. If all 8 channels are measured, the sampling speed is 6.25 Hz. If it is for instance necessary to sample data 10× per second, only 5 channels can be turned on, remaining 3 channels must be turned off. It is not necessary to wait for the digital filter to settle down when only one channel is measured and the input multiplexer is not switched. The data sampling frequency is then 200 Hz. But keep on mind that the A/D converter is not able to pass the step over the full input range to its output at this speed. If the input voltage changes e.g. from -10 V to +10 V, the converter needs 4 cycles to propagate the step to the output. So the sampling frequency is again 50 Hz. Remark: The USB interface of DataLab IO devices can transfer data much faster than the AI2 module can measure them. But faster communication with the device does not bring any advantages. More frequent read requests only causes more frequent communication of the same data. Analog input module AI3
There is a jumper on the module PCB associated with every input channel. Closing the jumper causes a precision 100 Ω resistor is inserted into the input, which changes voltage input into the current one. Hint: Input ranges can be defined for every input channel independently by the application program. But the voltage or current mode is selected by jumper on the PCB and this cannot be performed on application runtime. The AI3 module allows not only input range setting for individual inputs, but also allows switching each input off. Skipping of particular input speeds up the sampling frequency of remaining inputs. The module is able to sample data at frequency 50 Hz (50 samples per second) on one channel. If all 8 channels are measured, the sampling speed is 6.25 Hz. If it is for instance necessary to sample data 10× per second, only 5 channels can be turned on, remaining 3 channels must be turned off. It is not necessary to wait for the digital filter to settle down when only one channel is measured and the input multiplexer is not switched. The data sampling frequency is then 200 Hz. But keep on mind that the A/D converter is not able to pass the step over the full input range to its output at this speed. If the input voltage changes e.g. from -10 V to +10 V, the converter needs 4 cycles to propagate the step to the output. So the sampling frequency is again 50 Hz. Remark: The USB interface of DataLab IO devices can transfer data much faster than the AI3 module can measure them. But faster communication with the device does not bring any advantages. More frequent read requests only causes more frequent communication of the same data. Analog output module AO1
Analog output module provides 8 voltage analog outputs with the range 0 to +10 V. D/A converter has 12 bit resolution. Each D/A converter count equals to 2.5 mV output voltage change. Remark: Because 12 bit resolution provides 4096 counts, 2.5 mV per count equals 10.24 V. If the output must not exceed 10 V, the software must not write value greater than 4000 to the output channel. When the driver is configured to use physical units (volts), such problem does not occur. For instance writing 10 to the output channel means the 10 V (with the uncertainty about 0.1 % caused by used components) appears on the output pins. First four of eight outputs can be configured as current outputs with range from 0 to 20 mA using jumpers on the module PCB. Due to the high resolution of the DAC the 4 to 20 mA range is implemented by software limitation of 0 to 20 mA range. Remark: The current source generates 20 mA when the DAC value is 3846 counts (with the uncertainty about 1 % caused by used components). Configuring the driver to use physical units (amperes) eliminates the necessity to recalculate written values. For instance writing 0.02 to the output channel means the current source will generate 20 mA current. Combined analog input and digital input/output module AD1
AD1 module analog inputs equal to the AI3 module inputs. Choosing voltage or current inputs, switching input ranges, sampling rate and other characteristics are described in the AI3 module description. But because the AD1 module has only 4 analog input channels, the input sampling rate is 12.5 Hz, not 6.25 Hz as in the case of AI3 module. Combined analog input/output and digital input/output module AD2
AD2 module analog inputs equal to the AI3 module inputs. Choosing voltage or current inputs, switching input ranges, sampling rate and other characteristics are described in the AI3 module description. But because the AD2 module has only 4 analog input channels, the input sampling rate is 12.5 Hz, not 6.25 Hz as in the case of AI3 module. Analog outputs can be configured as voltage or current outputs using jumpers on the module PCB. Voltage output range is 0 to 10 V, current output range is 0 to 20 mA. The used D/A converter has 8-bit resolution and one count corresponds to 41.5 mV or 0.083 mA. Remark: Because 8 bit resolution provides 256 counts, 41.5 mV per count equals 10.625 V. If the output must not exceed 10 V, the software must not write value greater than 240 to the output channel. When the driver is configured to use physical units (volts), such problem does not occur. For instance writing 10 to the output channel means the 10 V (with the module uncertainty) appears on the output pins. The same is valid for current mode. Combined analog input/output module AIO1
AIO1 module analog inputs equal to the AI3 module inputs. Choosing voltage or current inputs, switching input ranges, sampling rate and other characteristics are described in the AI3 module description. But because the AIO1 module has only 4 analog input channels, the input sampling rate is 12.5 Hz, not 6.25 Hz as in the case of AI3 module. Analog outputs can be configured as voltage or current outputs using jumpers on the module PCB. Voltage output range is 0 to 10 V, current output range is 0 to 20 mA. The used D/A converter has 12-bit resolution and one count corresponds to 2.5 mV or 0.005 mA. Remark: Because 12 bit resolution provides 4096 counts, 2.5 mV per count equals 10.24 V. If the output must not exceed 10 V, the software must not write value greater than 4000 to the output channel. When the driver is configured to use physical units (volts), such problem does not occur. For instance writing 10 to the output channel means the 10 V (with the module uncertainty) appears on the output pins. The same is valid for current mode. Module for Resistive Temperature Detectors RTD1
Hint: Input ranges can be defined for every input channel independently by the application program. Inputs are sampled at the same speed as in the case of the AI3 module. However, sampling speed is not critical in the case of temperature measurement using RTD. Remark: The USB interface of DataLab IO devices can transfer data much faster than the RTD1 module can measure them. But faster communication with the device does not bring any advantages. More frequent read requests only causes more frequent communication of the same data. Mode and control channel usageThe same module configuration can be often defined in two ways—by writing to control channel or by setting the mode parameter in the parameter file. The numerical value is the same in both cases. Writing the control channel on application startup (e.g. in OnStartup() procedure of some instrument) has the same effect as defining the mode parameter in the parameter file. The driver stores value written to control channel and uses it as module mode. If the module is disconnected and then connected again, the module is initialized with the last value written to the control channel and not with mode value defined in the parameter file. Driver-specific error codesThe driver generates the following error codes:
Remark: The driver-specific error codes are distinguished from Control Web system error codes by adding the 65536 (10000H) offset. The Control Web then can determine if the error code is system global code or driver specific code. The error codes displayed in the Log Window are already displayed without the offset (that means codes 1 to 4 are displayed in the case of DataLab IO). But if the application reads the error code attribute channel:error, the attribute value will be 65537 to 65540. Module positions and device slotsDataLab IO4 has four slots marked by letters A, B, C and D. These slots are placed in the device as displayed on the picture: Module positions on the DataLab IO unit Take care to orient the unit properly—slots A and B are on top when the device blue LED and also the USB and power connectors are on the right side. The slot letters are necessary only for users—they do not affect the device functionality. Any module can be placed to any slot. The device automatically detects plugged module types and adopts to the current configuration. But if the device is used with the Control Web application, the parameter file contains parameters for concrete modules and it is necessary to uniquely identify these modules. DataLab IO1 has only one module slot marked A. This is why the parameter file for DataLab IO1 unit should have only the [module_a] section. Driver configuration in the Control Web development environmentThe Control Web development environment offers tools for comfortable driver configuration. This tool automatically creates driver parameter file (.par) and driver map file (.dmf) according to the application author's needs. The driver configuration tool scans the USB bus to search all DataLab IO units plugged to the computer. All units including their identifiers and plugged modules are displayed in a tree. Scanning of all connected DataLab IO devices It is possible to choose the device with which the particular driver will communicate. Device parameters can be edited using the structured sheet editor, showing parameters of individual sections. Driver parameter editing The driver configuration tool can create both parameter and mapping files from defined parameters. It is of course possible to edit these files using arbitrary text editor. The parameter file in the text form DataLab IO system driverThe operating system needs proper drivers to correctly detect and handle all USB devices. There is a system driver on the CD-ROM supplied with every DataLab IO device. Driver files are placed in '\English\DataLab IO_USB\Drivers\Windows' directory. This directory contains only two files: 'dlusb.sys' (the driver itself) and 'dlusb.inf' (installation information). The driver can be installed explicitly by clicking the 'dlusb.inf' file by right mouse button and choosing the Install menu item. But this way is not usual. The best way to install the system driver is just plug the DataLab IO device to USB port. The operating system will detect new USB device and prompts the user to enter path to driver files. It is possible to enter the path to '\dlusb' on CD-ROM or just to let the system to search the CD-ROM for drivers. Hint: It is not necessary to install the driver from the CD-ROM. Driver files can be copied to any disk storage. If for instance the target machine is not equipped with the CD-ROM drive, it is possible to copy driver files to USB Flash Disk and to install them from that copy. Warning: The 'dlusb.sys' driver is not signed by digital signature. Windows notifies the user about that and asks if the installation should continue. If you want to install the driver, just continue with installation. Digital signature is only a formal and should ensure using only drivers signed by Microsoft. It does not affect driver functionality. Operating system supportThe DataLab IO devices can theoretically work with any operating system supporting USB interface. However, as stated earlier, every operating system requires proper driver to work with USB device. Currently only Windows driver is supplied with DataLab IO devices. But there are also differences among various Windows versions. The 'dlusb.sys' corresponds to WDM (Windows Driver Model) specification. WDM drivers should work in Windows 98SE, Windows Me and also in Windows 2000 and Windows XP. But there are APIs missing in Windows 9x (Windows 98 and Windows Me), necessary to correctly detect device arrival/removal from user mode. This is why the driver requires Windows 2000 and better versions of Windows (e.g. Windows XP). History of function enhancementsWhenever the functionality of DataLab IO is enhanced, the new version of software support must be released. Both DataLab IO system driver (the 'dlusb.sys' file) and Control Web and Active X driver (the 'dldrv.dll' file) must be upgraded together. This is why the major and minor version numbers of both files are the same.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||