- Email: [email protected]
Toward a standardized data acquisition interface
Computer Standards & Interfaces 14 (1992) 333-337 North-Holland
333
Commentary
Toward a standardized data acquisition interface Tarik Ozkul Computer Engineering Department, King Fahd University of Petroleums and Mineral, KFUPM Box 1912, Dhahran 31261, Saudi Arabia
Abstract Ozkul, T., Toward a standardized data acquisition Interface, Computer Standards & Interfaces 14 (1992) 333-337. Personel computers increasingly have more acceptance as serious data acquisition tools in the lab environments. But the lack of standardization in this field is becoming a serious setback for the personal computer to be more popular. In this paper several important points that should be considered in a data acquisition interface are discussed and a trial standard that is being implemented in K F U P M is examined.
Keywords: Data acquisition; standards.
I. Introduction
Personal computers are becoming more popular as data acquisition tools in research labs and industrial environment. The two major underlying factors behind this are the increase of the reliability, and the increase of the processing power of the PCs. Personal computers which are initially designed for the office environment are now being manufactured in industrial grade - called industrial PCs - which are robust enough to take the vigors of the harsh factory environment. With respect to the processing power of PCs we have come a long way from the first PCs that were introduced in the beginning of the 1980s. After a decade, the ordinary PC now has the power of yesterday's workstation at a fraction of the cost. Besides the two major factors stated above there are other factors such as abundant availability of software packages and software tools for the PCs which are additional incentives for using PCs in the industrial environment.
Manufacturers of data acquisition instruments were quick enough to take notice of the development and respond to it by designing various different add-in cards designed to be used with the PC. Soon after the development of the cards, software companies prepared commercial software packages for controlling data acquisition cards. Encouraged by the response that they got, hardware companies continued on designing systems with more sensitive, higher resolution data acquisition equipment. As the PC-based data acquisition got more acceptance from industry we see the merger from the add-in cards concept to a more acceptable architecture where the data acquisition hardware is located inside a crate and the crate is controlled by the PC. This architecture offers higher sensitivity since data acquisition equipment is taken out of the electromagnetically noisy PC environment. The last evolution in this arena was the development of hybrid systems with intelligent crates and the necessary data acquisition hardware built in. Because of the in-
0920-5489/92/$05.00 © 1992 - Elsevier Science Publishers B.V. All rights reserved
334
Z Ozkul
telligence integrated into the crate, it can sample data in a stand-alone mode and sent it to a remote location via a serial link. PC-based data acquisition took a giant leap in the few years and became an acceptable intelligent instrumentation device in the research laboratories and the factory floor. Now an experienced researcher can select data acquisition cards and software in order to build his own system for scratch. A few years ago this was only possible by a special purpose turn key system. A side benefit of this was the automated data collection and transfer of data to popular data analyses packages for the purpose of analyzing data on or off-line. Although being an old standard, GPIB or IEEE-488 is still a popular method of controlling intelligent instruments in a lab environment. Nowadays almost universally the job of the controller is done by a PC with an IEEE-488 interface card inside. As all things that developed very quickly, the standardization of the data acquisition cards was either overlooked or impossible due to lack of available guidelines. All data acquisition hardware manufacturers ended up with their own designs. Although the software interface of these cards is not very complex, it still requires special purpose software to handle each one of these cards. Only a few of the hardware cards in the market are compatible with each other. Although writing a custom driver routine for each card is not difficult, it is not possible for a considerable number of researchers who would like to use the cards in their projects but are not very well versed with details of programing languages and location of the i n p u t / o u t p u t ports. If the data acquisition project at hand requires only a few cards to coexist inside the PC then the problem is not so serious. But if the number of cards that needs to be interfaced is more than two or three, then together with the already crowded I / O map of the PC, the selection, relocation of the I / O ports for the data acquisition hardware becomes a quite difficult, if not impossible, task. This is a setback for the PC-based data acquisition system users and results in limiting the applications to small size data acquisition projects. The remedy to the problem is to standardize the data acquisition interface of the PC in such a way as to allow users that are not very technically oriented to easily set-up large number of cards together. Besides being easy to understand and use, the soft-
ware interface should also be very well defined so that the data acquisition hardware can be controlled by all data acquisition software packages, not only by the software supplied by the manufacturer of the interface card. Obviously such a task should be looked at carefully by a consortium of researchers in the field of data acquisition and in universities before it becomes an acceptable standard.
2. Concept of a system
In this paper we would like to introduce an in-house developed data acquisition interface for the data acquisition lab of the KFUPM. While designing the standard, particular attention was given to fulfilling the following points: (i) software interface of the design should be as simple as possible, (ii) hardware interface of the system should occupy minimum amount of i n p u t / o u t p u t ports in the I / O map or the memory map of the system, (iii) system should be easily enlarged by the user with minimum effort by cascading additional units to the existing system without changing the previous configuration, (iv) data acquisition systems are use external timers extensively to keep track of timing for sampling data, so the system should have provisions for providing multiple timer signals easily, (v) data acquisition systems use interrupts extensively. Especially high priority non-maskable interrupts are needed to be used in the system in order to insure timely sampling and data transfer. The interface should provide provisions for providing multiple NMI interrupts to the computer. The data acquisition interface designed provides the above-mentioned points and can be used for plug-in cards designed to be used inside a PC as well as external crate systems. The interface can be expanded to include even the most demanding data acquisition applications. The interface has special provisions for dealing with ADC inputs, DAC outputs, stepper motor control outputs, interrupt inputs, timer outputs, digital inputs and digital outputs. There are also provisions for user definable functions in case of
Toward a standardized data acquisition interface
335
BASE ADDRESS 0
XX00
15 [
XX01
]
DATA WORD 1
XX10
I
DATA WORD 2
XXll
I
I
I
CONTROL WORD
INTERRUPT ID WORD
Fig. 1.
a need for expansion arises. The base address of the data acquisition interface can be either memory or I / O mapped. The interface occupies only four 16 bit memory or I / O locations in the memory map of the PC. The first 16 bits are designed for the control word, second and third 16 bits are for the data word. Fourth 16 bit is designed for the interrupt identification vector. The assignment of the bits for the control word are shown in Fig. 1.
2.1. Control word Control word specifies the type of function and identifies the specific channel for the information. The possible functions for data acquisition are specified by the most significant three bits of the control word, which are analog to digital conversion, digital to analog conversion, stepper motor control, setting system timers, digital input and digital output. There are two custom definable functions left for the user in case a special function needs to be implemented. The slot number and channel n u m b e r are alternative ways of addressing different cards in the system. They can be used individually or together or one may be omitted in the control word. When the slot number is not specified, by default it will be accepted as '0' by the system. In this case the channel number has to be specified by the user to define which A D C or which D A C etc. is being addressed. If the channel number is not specified, then the system will accept channel '0' by default and deal with the slot specified by the slot number directly (Fig. 2). The five bit slot number
allows a system with a maximum of 32 slots. Normally each crate has 8 slots, as the need arises, the system can be expanded by cascading additional crates of up to four to give a total of 32 slots (Fig. 3). Each slot in the system can have 256 channels. To give an example, a user may have an analog to digital converter card in one of the slots. From this single slot, 0 to 255 different A D C channels can be accessed. It should be noted that only one function for a slot is allowed, either A D C or D A C or Timer etc. By specifying both slot number and channel number together maximum expansion of the system can be achieved which gives 8 192 channels to be used with ADC, DAC, timers etc. Normally for a PC-based system where the data acquisition card resides inside the
CONTROL WORD FORMAT
15 14 13 12 11 10 09 08 07 06 05 04 03 02 0100
I 11 II l I ChannelI Select Function Select SlotSelect ADC 001 DAC 010 STEPPERMOTOR 011 TIMER 100 DIGITALINPUT 101 DIGITALOUTPUT 000
110 USER DEFINED 111 USER DEFINED
Fig. 2.
I
336
T. Ozkul
D
[111111
]
analog to digital function the data words will serve as input, for digital to analog conversion function they will be output, for time they will be output. The formats of the data words for different functions are shown in Table 1. 2.3. Interrupt I D vector
CRATEEXPANSIONSYTEM Fig. 3.
PC the slot n u m b e r is not applicable and only the channel n u m b e r has to be used. (All slots inside the PC are identical, they cannot be distinguished by software.) For a more serious data acquisition project where sensitivity is important a crate system that resides outside of the PC environment is needed. For a limited size project were the number of A D C s and DACs are not excessive one crate with 8 slots may be sufficient. Each slot in the system is identified separately and data can be transferred simply by specifying the slot number. For a seriously large size data acquisition project where several channels for A D C and D A C are needed, both slot n u m b e r and channel number have to be specified to enable data transfer from a specific channel of a specific slot. 2.2. D a t a words
The second and third 16 served for data. Depending tion selected by the control be either input or output.
bit locations are reon the type of funcword this word may As an example for
The system uses a sophisticated but simple to use interrupt mechanism. In data acquisition projects the use of interrupts becomes a must for sampling data at precise times with precise duration in between samples. The system is designed to give a hardware non-maskable interrupt or interrupt request to the computer. In data acquisition projects a non-maskable interrupt (NMI) is preferred because of the high priority in the computer. To make it possible that M N I is given by more than one device in the system an interrupt identification vector is defined. Devices that want to give an N M I to the computer must first send an interrupt to the system and give the identification number. The interrupt will then be ID number read by the computer during the NMI routine for further identification of the interrupting device. For interrupts that are not so timecritical, interrupt request ( I R Q ) will be generated. Again the interrupt I D vector will be provided in location X X l l for the CPU. Normally the connections from the timer outputs to interrupt inputs are done in hardware, but there are special hardware provisions for supplying interrupt IDs to the computer. Basically each crate has several available prefixed interrupt ID codes. The user, while connecting the interrupting line to the interrupt input line of the crate, also connects the interrupting line to the ID select lines to select one of the available unique ID codes.
Table 1 Most sig. word XX01 Least sig. word XXl0 Most sig. word XX01 Least sig. word XX10 Most sig. word XX01 Least sig. word XX10 (Countdown timer, time base of the individual timers are hardware provided) Stepper motor XX01 Most significant bit 0 clockwise 1 counter clockwise all the rest of the bits: number of steps Digital input Most sig. word XX01 Least sig. word XX10 Digital output Most sig. word XX01 Least sig. word XX10
Analog to digital Digital to analog Timer
Toward a standardized data acquisition interface
3. Conclusions In this paper we have tried to emphasize the benefits of a standardized data acquisition interface, and tried to give some of the important points that the data acquisition interface should provide. We have not mentioned the details of the hardware design since the design is rather trivial and dependent on the type of PC being used. It is the opinion of the author that the issue of standardization of the data acquisition interface be looked at by a consortium of the involved engineers in the field and a solid standard is drafted as soon s possible.
337
Tarik Ozkul has received his BSc degree in Electrical Engineering from Bogazici University, Istanbul, Turkey in 1981. After working as a design engineer for some time, he got his MSc in Electrical Engineering in 1984 from Florida Institute of Technology, Florida, USA. In 1988 he received his PhD in Electrical Engineering from ~ ! ~ the same institution in Florida. He has been working as an Assistant Professor in the Computer Engineering Department of King Fahd University of Petroleum and Minerals since then. His research interests are data acquisition, robotics and neural networks. He is also currently involved in the rapid prototyping area.
333
Commentary
Toward a standardized data acquisition interface Tarik Ozkul Computer Engineering Department, King Fahd University of Petroleums and Mineral, KFUPM Box 1912, Dhahran 31261, Saudi Arabia
Abstract Ozkul, T., Toward a standardized data acquisition Interface, Computer Standards & Interfaces 14 (1992) 333-337. Personel computers increasingly have more acceptance as serious data acquisition tools in the lab environments. But the lack of standardization in this field is becoming a serious setback for the personal computer to be more popular. In this paper several important points that should be considered in a data acquisition interface are discussed and a trial standard that is being implemented in K F U P M is examined.
Keywords: Data acquisition; standards.
I. Introduction
Personal computers are becoming more popular as data acquisition tools in research labs and industrial environment. The two major underlying factors behind this are the increase of the reliability, and the increase of the processing power of the PCs. Personal computers which are initially designed for the office environment are now being manufactured in industrial grade - called industrial PCs - which are robust enough to take the vigors of the harsh factory environment. With respect to the processing power of PCs we have come a long way from the first PCs that were introduced in the beginning of the 1980s. After a decade, the ordinary PC now has the power of yesterday's workstation at a fraction of the cost. Besides the two major factors stated above there are other factors such as abundant availability of software packages and software tools for the PCs which are additional incentives for using PCs in the industrial environment.
Manufacturers of data acquisition instruments were quick enough to take notice of the development and respond to it by designing various different add-in cards designed to be used with the PC. Soon after the development of the cards, software companies prepared commercial software packages for controlling data acquisition cards. Encouraged by the response that they got, hardware companies continued on designing systems with more sensitive, higher resolution data acquisition equipment. As the PC-based data acquisition got more acceptance from industry we see the merger from the add-in cards concept to a more acceptable architecture where the data acquisition hardware is located inside a crate and the crate is controlled by the PC. This architecture offers higher sensitivity since data acquisition equipment is taken out of the electromagnetically noisy PC environment. The last evolution in this arena was the development of hybrid systems with intelligent crates and the necessary data acquisition hardware built in. Because of the in-
0920-5489/92/$05.00 © 1992 - Elsevier Science Publishers B.V. All rights reserved
334
Z Ozkul
telligence integrated into the crate, it can sample data in a stand-alone mode and sent it to a remote location via a serial link. PC-based data acquisition took a giant leap in the few years and became an acceptable intelligent instrumentation device in the research laboratories and the factory floor. Now an experienced researcher can select data acquisition cards and software in order to build his own system for scratch. A few years ago this was only possible by a special purpose turn key system. A side benefit of this was the automated data collection and transfer of data to popular data analyses packages for the purpose of analyzing data on or off-line. Although being an old standard, GPIB or IEEE-488 is still a popular method of controlling intelligent instruments in a lab environment. Nowadays almost universally the job of the controller is done by a PC with an IEEE-488 interface card inside. As all things that developed very quickly, the standardization of the data acquisition cards was either overlooked or impossible due to lack of available guidelines. All data acquisition hardware manufacturers ended up with their own designs. Although the software interface of these cards is not very complex, it still requires special purpose software to handle each one of these cards. Only a few of the hardware cards in the market are compatible with each other. Although writing a custom driver routine for each card is not difficult, it is not possible for a considerable number of researchers who would like to use the cards in their projects but are not very well versed with details of programing languages and location of the i n p u t / o u t p u t ports. If the data acquisition project at hand requires only a few cards to coexist inside the PC then the problem is not so serious. But if the number of cards that needs to be interfaced is more than two or three, then together with the already crowded I / O map of the PC, the selection, relocation of the I / O ports for the data acquisition hardware becomes a quite difficult, if not impossible, task. This is a setback for the PC-based data acquisition system users and results in limiting the applications to small size data acquisition projects. The remedy to the problem is to standardize the data acquisition interface of the PC in such a way as to allow users that are not very technically oriented to easily set-up large number of cards together. Besides being easy to understand and use, the soft-
ware interface should also be very well defined so that the data acquisition hardware can be controlled by all data acquisition software packages, not only by the software supplied by the manufacturer of the interface card. Obviously such a task should be looked at carefully by a consortium of researchers in the field of data acquisition and in universities before it becomes an acceptable standard.
2. Concept of a system
In this paper we would like to introduce an in-house developed data acquisition interface for the data acquisition lab of the KFUPM. While designing the standard, particular attention was given to fulfilling the following points: (i) software interface of the design should be as simple as possible, (ii) hardware interface of the system should occupy minimum amount of i n p u t / o u t p u t ports in the I / O map or the memory map of the system, (iii) system should be easily enlarged by the user with minimum effort by cascading additional units to the existing system without changing the previous configuration, (iv) data acquisition systems are use external timers extensively to keep track of timing for sampling data, so the system should have provisions for providing multiple timer signals easily, (v) data acquisition systems use interrupts extensively. Especially high priority non-maskable interrupts are needed to be used in the system in order to insure timely sampling and data transfer. The interface should provide provisions for providing multiple NMI interrupts to the computer. The data acquisition interface designed provides the above-mentioned points and can be used for plug-in cards designed to be used inside a PC as well as external crate systems. The interface can be expanded to include even the most demanding data acquisition applications. The interface has special provisions for dealing with ADC inputs, DAC outputs, stepper motor control outputs, interrupt inputs, timer outputs, digital inputs and digital outputs. There are also provisions for user definable functions in case of
Toward a standardized data acquisition interface
335
BASE ADDRESS 0
XX00
15 [
XX01
]
DATA WORD 1
XX10
I
DATA WORD 2
XXll
I
I
I
CONTROL WORD
INTERRUPT ID WORD
Fig. 1.
a need for expansion arises. The base address of the data acquisition interface can be either memory or I / O mapped. The interface occupies only four 16 bit memory or I / O locations in the memory map of the PC. The first 16 bits are designed for the control word, second and third 16 bits are for the data word. Fourth 16 bit is designed for the interrupt identification vector. The assignment of the bits for the control word are shown in Fig. 1.
2.1. Control word Control word specifies the type of function and identifies the specific channel for the information. The possible functions for data acquisition are specified by the most significant three bits of the control word, which are analog to digital conversion, digital to analog conversion, stepper motor control, setting system timers, digital input and digital output. There are two custom definable functions left for the user in case a special function needs to be implemented. The slot number and channel n u m b e r are alternative ways of addressing different cards in the system. They can be used individually or together or one may be omitted in the control word. When the slot number is not specified, by default it will be accepted as '0' by the system. In this case the channel number has to be specified by the user to define which A D C or which D A C etc. is being addressed. If the channel number is not specified, then the system will accept channel '0' by default and deal with the slot specified by the slot number directly (Fig. 2). The five bit slot number
allows a system with a maximum of 32 slots. Normally each crate has 8 slots, as the need arises, the system can be expanded by cascading additional crates of up to four to give a total of 32 slots (Fig. 3). Each slot in the system can have 256 channels. To give an example, a user may have an analog to digital converter card in one of the slots. From this single slot, 0 to 255 different A D C channels can be accessed. It should be noted that only one function for a slot is allowed, either A D C or D A C or Timer etc. By specifying both slot number and channel number together maximum expansion of the system can be achieved which gives 8 192 channels to be used with ADC, DAC, timers etc. Normally for a PC-based system where the data acquisition card resides inside the
CONTROL WORD FORMAT
15 14 13 12 11 10 09 08 07 06 05 04 03 02 0100
I 11 II l I ChannelI Select Function Select SlotSelect ADC 001 DAC 010 STEPPERMOTOR 011 TIMER 100 DIGITALINPUT 101 DIGITALOUTPUT 000
110 USER DEFINED 111 USER DEFINED
Fig. 2.
I
336
T. Ozkul
D
[111111
]
analog to digital function the data words will serve as input, for digital to analog conversion function they will be output, for time they will be output. The formats of the data words for different functions are shown in Table 1. 2.3. Interrupt I D vector
CRATEEXPANSIONSYTEM Fig. 3.
PC the slot n u m b e r is not applicable and only the channel n u m b e r has to be used. (All slots inside the PC are identical, they cannot be distinguished by software.) For a more serious data acquisition project where sensitivity is important a crate system that resides outside of the PC environment is needed. For a limited size project were the number of A D C s and DACs are not excessive one crate with 8 slots may be sufficient. Each slot in the system is identified separately and data can be transferred simply by specifying the slot number. For a seriously large size data acquisition project where several channels for A D C and D A C are needed, both slot n u m b e r and channel number have to be specified to enable data transfer from a specific channel of a specific slot. 2.2. D a t a words
The second and third 16 served for data. Depending tion selected by the control be either input or output.
bit locations are reon the type of funcword this word may As an example for
The system uses a sophisticated but simple to use interrupt mechanism. In data acquisition projects the use of interrupts becomes a must for sampling data at precise times with precise duration in between samples. The system is designed to give a hardware non-maskable interrupt or interrupt request to the computer. In data acquisition projects a non-maskable interrupt (NMI) is preferred because of the high priority in the computer. To make it possible that M N I is given by more than one device in the system an interrupt identification vector is defined. Devices that want to give an N M I to the computer must first send an interrupt to the system and give the identification number. The interrupt will then be ID number read by the computer during the NMI routine for further identification of the interrupting device. For interrupts that are not so timecritical, interrupt request ( I R Q ) will be generated. Again the interrupt I D vector will be provided in location X X l l for the CPU. Normally the connections from the timer outputs to interrupt inputs are done in hardware, but there are special hardware provisions for supplying interrupt IDs to the computer. Basically each crate has several available prefixed interrupt ID codes. The user, while connecting the interrupting line to the interrupt input line of the crate, also connects the interrupting line to the ID select lines to select one of the available unique ID codes.
Table 1 Most sig. word XX01 Least sig. word XXl0 Most sig. word XX01 Least sig. word XX10 Most sig. word XX01 Least sig. word XX10 (Countdown timer, time base of the individual timers are hardware provided) Stepper motor XX01 Most significant bit 0 clockwise 1 counter clockwise all the rest of the bits: number of steps Digital input Most sig. word XX01 Least sig. word XX10 Digital output Most sig. word XX01 Least sig. word XX10
Analog to digital Digital to analog Timer
Toward a standardized data acquisition interface
3. Conclusions In this paper we have tried to emphasize the benefits of a standardized data acquisition interface, and tried to give some of the important points that the data acquisition interface should provide. We have not mentioned the details of the hardware design since the design is rather trivial and dependent on the type of PC being used. It is the opinion of the author that the issue of standardization of the data acquisition interface be looked at by a consortium of the involved engineers in the field and a solid standard is drafted as soon s possible.
337
Tarik Ozkul has received his BSc degree in Electrical Engineering from Bogazici University, Istanbul, Turkey in 1981. After working as a design engineer for some time, he got his MSc in Electrical Engineering in 1984 from Florida Institute of Technology, Florida, USA. In 1988 he received his PhD in Electrical Engineering from ~ ! ~ the same institution in Florida. He has been working as an Assistant Professor in the Computer Engineering Department of King Fahd University of Petroleum and Minerals since then. His research interests are data acquisition, robotics and neural networks. He is also currently involved in the rapid prototyping area.