A simple multipurpose dataacquisition program for PCIBMGrasso Antonino, Gangemi Rosario, and Wanderlingh Ulderico Citation: Review of Scientific Instruments 62, 2042 (1991); doi: 10.1063/1.1142364 View online: http://dx.doi.org/10.1063/1.1142364 View Table of Contents: http://scitation.aip.org/content/aip/journal/rsi/62/8?ver=pdfcov Published by the AIP Publishing Articles you may be interested in Two Demonstrations with a New Data-Acquisition System Phys. Teach. 52, 164 (2014); 10.1119/1.4865520 The Tramp DataAcquisition System Comput. Phys. 7, 638 (1993); 10.1063/1.4823239 NMR data acquisition, data processing, and spectrometer control with an IBM PC compatible Rev. Sci. Instrum. 63, 5359 (1992); 10.1063/1.1143402 Integrated, multivendor distributed dataacquisition system Rev. Sci. Instrum. 59, 1786 (1988); 10.1063/1.1140112 Assembly subroutine to optimize the multiplexed A/D throughput of the IBM PC Data Acquisition andControl Adapter Rev. Sci. Instrum. 58, 1766 (1987); 10.1063/1.1139353

This article is copyrighted as indicated in the article. Reuse of AIP content is subject to the terms at: http://scitationnew.aip.org/termsconditions. Downloaded to IP:

130.160.4.77 On: Fri, 19 Dec 2014 03:43:07

A simple multipurpose data-acquisition program for PC-IBM Grass0 Antonino Istituto Teen. Spettr. C&R., C.l? 55 S. Agata, 98010 Messina, Italy

Gangemi Rosarioa) and Wanderlingh Ulderico Dipartimento di Fisica, Universit& di Messina, C.P. 55 S Agata, 98010 Messina, Italy

(Received 20 November 1990; accepted for publication 22 March 1991)

A BASIC program is described that runs on any PC-IBM. This program allows data acquisition either from most interfaciable devices (by means of IEEE 488 or RS 232), or suitable cards such as the 8255. During acquisition, recorded data can be processed and displayed, and several commands can be executed so as to modify the acquisition itself in real time. The set of commands forms a sort of programming language and an ASCH file of such commands can be executed. Some applications, already in use in our laboratory, are also described.

Any research laboratory nowadays is equipped with measuring instruments that come with interface parts (of- ten IEEE 488 or RS 232). Usually, programs supplied with the instruments by the companies are either demo pro- grams or too specific and not sufficient for special needs. As a consequence, researchers have to write specific pro- grams for their own instrumentations, usually using the simplest programming languages (like BASIC). Thus, many programs are created that have nothing in common. Gen- erally these programs are hard to modify for controlling other devices and they are not easy to update. It is custom- ary to start with a very simple and essential program but, in reality, after a few corrections and improvements one comes up with a muddle of routines. For all of the above reasons, we have felt the necessity to realize a well-orga- nized program that preserves all the advantages of a High- Level Language (HLL) like BASIC. In the following sec- tions we will describe the program and some applications. The program can be requested by electronic mail from (ANTONIO @ IMEUNIV EARN-BITNET).

The way in which most of the acquisition and control- ling programs are realized in a research laboratory is broadly as follows: There is a main program, written in HLL that is in charge of processing, storing, and display- ing data, and several subroutines that control all the in- struments and data acquisition via interface cards. In ad- dition LLL (Low-Level Language) routines may be present once the execution of them in HLL is not fast enough. The main program is then the only part that one can standardize since it is independent from the specific measuring system. The BASIC program we created has many of the features that would be desirable as standard. The skeleton of the program is in fact able to display the measured data during the acquisition, record the data in mass storage systems (HD, FD), and show the parameters that characterize the measurement and the status of the experimental set. Moreover the skeleton program includes a flexible command string interpreter that gives the user full control of the experiment by means of a set of com- mands. The commands that perform the above-mentioned features are part of the skeleton, while the remaining com- mands have to be written suitably for specific applications.

“External collaborator.

The skeleton program is constituted by several self- consistent segments (referred to as modules) that are chained by a trapping path (Fig. 1). The execution of a certain module is conditioned by the values of one or more flags. When the program runs the program pointer moves along the trapping path checking the flags of each module in order to decide if it is running inside it or not. Every module, once executed, may change the values of some flags so as to alter the forthcoming path of the program pointer. The modules that are already present in the skel- eton are, as shown in Fig. 1, the Graphics, Keyboard, Commands Interpreter, Commands Files Processor, Wait, and Data Acquisition modules. In order to show the capa- bilities of this program we will briefly describe some of them.

The Data Acquisition Module is the only one that is seen as a “Maskable Interrupt” while all the others are treated using a “Polling Technique”; in such a way the priority of the data-acquisition procedure is preserved. Ow- ing to the language (BASIC) in which the program is writ- ten it is not possible to use such a module when acquisition time steps smaller than 1 s are needed. This module is composed of two parts, one of which depends on the re- mote instrument and interface cards used to get the data,

I J FIG. I. Block diagram of the skeleton program showing the basic features and the available areas to specialize the program (gray box).

2042 Rev. Sci. Instrum. 62 (S), August 1991 0034~6748/91/082042-03$02.00 @ 1991 American Institute of Physics 2042 This article is copyrighted as indicated in the article. Reuse of AIP content is subject to the terms at: http://scitationnew.aip.org/termsconditions. Downloaded to IP:

130.160.4.77 On: Fri, 19 Dec 2014 03:43:07

while the other, being standard for all applications, is a part of the skeleton program.

The graphics module provides the possibility of plot- ting the incoming data as well as already recorded data file, to change the X/Y scale, and so on. The incoming data are plotted on a part of the screen, along with a set of chosen parameters characterizing the experiment, so that a hard- copy of the screen will furnish all the necessary informa- tion about the experiment. The routine in charge of dis- playing the characters on the screen is an ASSEMBLER routine.

The Commands Interpreter Module is in charge of the execution of the defined commands. Commands are used to set some experimental parameters, communicate with external devices, or turn on/off flags so as to enable/disable the processing of some module. It is also possible to chain a set of these commands in an ASCII file that will be processed sequentially by the main program when a spe- cific command is typed (DO (filename) ). The authors in- serted in the main program some mathematical commands such as Weighted Linear Regression (WLR) and others which, in their opinion, are useful in a lot of applications. Last but not least all commands can be typed on the key- board while the experiment runs, making possible the cor- rection of some parameters if necessary; the program will check the compatibility of commands with the actual mea- surement status. In order to create a new command (C Box) in the skeleton program one only needs to increase the commands number variable and to define its name. Then the segment of the program that will be executed once this command is typed has to be written in a box suitably labeled.

The wait module, like the data-acquisition module, is composed of a part of broad utility that comes with the skeleton program and another one that depends on the specific application. In fact, the WAIT command is a mul- tifunctional command as can be seen from its syntax: WAIT (nn)/(XX). In the first case it is followed by a number that represents the standby time to continue the execution of the actual command file. In the latter case the effect of the command depends on a particular condition (e.g. WAIT TEMP will wait for a given value of the tem- perature of the sample).

Going back to Fig. 1, we will now describe how the gray boxes could be “filled” in order to specialize the pro- gram for specific applications.

An experiment usually consists of the measurement of a certain variable Y as a function of another variable X. If the variable X is the time, users can exploit the data-ac- quisition module already existing in the skeleton (A box). This is possible only if the elapsed time between two ac- quisitions is not shorter than 1 s; otherwise, a suitable as- sembler routine has to be written.

If the independent variable X is not the time the ex- periment is then merely reduced to set the value for the X variable and then read the corresponding value for the Y one.

To fit our program to a new measurement set involves writing some new commands and adding some new mod- ules. Definition of a new module (C box) involves writing

2043 Rev. Sci. Instrum., Vol. 62, No. 8, August 1991

the proper segment of program, and chaining it along with the other modules. Access to a module is conditioned by the new flags set for that module and sometimes also by flags already present in the program. For the modules, as well as for the commands, the execution time should be short, in order to avoid blocking all the other functions. The breaking of a module in several parts to be executed in a successive cycle of the pointer is a good solution. Cre- ation of a new module will, of course, involve the creation of new commands (at least those in charge of the enabling/ disabling of the module itself).

To extent the WAIT command (D box) it is necessary to define the variable for which this module should be waiting. Usually a command, with the aim of setting the value of this variable, is defined at the same time. By typing the WAIT command together with the new option, the processing of the actual command file will be halted until the variable reaches the set value. In our laboratory the described program has been applied to two experimental sets.

The instrument, described in Ref. 1, allows relative heat capacity measurements with great accuracy. A typical experiment consists of three stages: First the sample has to reach thermal equilibrium with a bath; this was realized using a WAIT SLope command (SLope is the preset value for the time derivative of the sample temperature, calculate using the WLR facility). In the second stage, both the sample and the reference have to be heated for a given time. This has been performed by a simple command HEATER ON/OFF that switches the proper power sup- ply on and off. Finally, the experimental data (temperature difference between sample and reference) have to be col- lected for a suitable time and then recorded. This has been achieved with high precision by means of a lock-in ampli- fier equipped with an EM RS232 interface card, driven by the program.

Static light scattering is a diffraction measurement that uses monochromatic light as a probe. A laser beam is fo- cused into the sample and the scattered light is collected at various angles by a photomultiplier (PM). In this case we just set a value for the angle 6 and read the corresponding intensity of the scattered light. The output of the PM is a TTL signal whose frequency is proportional to the rate of incoming photons. To measure such a frequency, we ex- ploited the solution adopted in Ref. 2 in which the 8255 card is used. The experiment, controlled by our program, consists in initializing the cards and reading the counter value at regular time intervals. Several measurements are repeated at a given angle so as to provide better averaged data and rejection of spurious counts, due to unwanted experimental effects (such as large aggregates, dust, elec- trical spikes, and so on). Moreover, along with the scat- tered intensity we can also read the incident light intensity so as to normalize the scattered light.

‘A. Barbini, D. Bertolini, M. Cassettari, F. Papucci, A. Salvetti, G. Sal- vetti, and S. Veronesi, Rev. Sci. Instrum. 60, 1308 (1989).

*S. Interdonato, D. Majolino, F. Mallamace, F. Aliotta, N. Micali, and C. Vasi, Rev. Sci. Instrum. 61, 2243 (1990).

Notes 2043 This article is copyrighted as indicated in the article. Reuse of AIP content is subject to the terms at: http://scitationnew.aip.org/termsconditions. Downloaded to IP:

130.160.4.77 On: Fri, 19 Dec 2014 03:43:07