Extendable high-speed stimulus generation and recording on the Macintosh computer

Page created by Andrea Watts
 
CONTINUE READING
Behavior Research Methods, Instruments, & Computers
1998,30 (3),392-398

                   Extendable high-speed stimulus generation
                   and recording on the Macintosh computer
                                                          SCO'IT B. STEINMAN
                                       Southern College oj Optometry, Memphis, Tennessee

             A new visual electrophysiology and eye-movement laboratory was developed with three goals in
          mind: (1) rapid execution speed for quick acquisition of data from infant subjects, (2) ease of opera-
          tion by experimenters, and (3) modularity and flexibility. A powerful system composed of two linked
          Macintosh computers was constructed in which one computer was used solely to generate visual stim-
          uli and the second solely to record subjects' responses, allowing recording to execute at maximum
          speed without being slowed by stimulus graphics generation. A single program on the recording com-
          puter allowed the experimenter to choose the stimulus and recording parameters. The two computers
          intercommunicated via a local EtherNet network to coordinate recording and signal averaging. This
          paper presents design principles and specific programming techniques relevant to any Macintosh sys-
          tem that must rapidly acquire physiological recordings while simultaneously displayingsensory stimuli.

   During the past decade, turnkey electrophysiology                    (flash electroretinograms [ERG], pattern ERG, flash vi-
recording units have gradually been replaced by personal-               sual evoked potentials [YEP], pattern YEP, motion YEP
computer-based recording systems (e.g., see Baro &                      [see Norcia, 1993], binocular "beat" YEP [see Baitch &
Lehmkuhle, 1988; de Waal, Reits, Spekreijse, & Grim-                    Levi, 1988]), oculomotor recordings (optokinetic ny-
bergen, 1983; Torok, 1990; van Norren & van de Kraats,                  stagmus [OKN], pursuit, saccade, fixation stability), and
 1983). Personal-computer-based systems offer flexibil-                 psychophysical measurements (forced-choice preferen-
ity not possible in turnkey-dedicated averaging units-                  tiallooking).
the stimulus configurations and analysis techniques                        The goal of this paper is not to provide all of the steps
are limited only by the imagination of the programmer.                  required to build an infant vision testing system. Rather,
The advent of fast personal computers has enabled the                   this paper will discuss specific programming issues that
use of graphical laboratory data acquisition program-                   had to be solved in order to achieve the design goals of a
ming languages for rapid program development. Al-                       wide variety of laboratory sensory electrophysiological
though these languages provide a useful physiology lab-                 recording systems. In particular, programming techniques
oratory tool, their clinical and experimental usefulness                for intercomputer coordination to allow simultaneous real-
has been limited in vision science because they cannot                  time visual stimulus display and electrophysiological re-
present rapidly changing visual stimuli and acquire and                 sponse recording will be examined in detail. However, it
display physiological responses at high sampling rates si-              is beyond the scope ofthis paper to be a tutorial on the par-
multaneously.                                                           ticular programming languages used; a background in
   This paper describes an extremely flexible infant vision             these programming languages is assumed.
laboratory developed by the author for the Washington
University School ofMedicine using two MC68040-based                    Design Goals and Decisions
Apple Macintosh computers. All of the major hardware                       While rapid data acquisition and flexibility are natu-
components and software tools are available from com-                   rally two important goals of any physiological recording
mercial sources or as freeware on the World-Wide Web.                   system, the present system had additional constrictions
Its modular software system was designed to allow stan-                 that made these goals even more critical. First, the time
dardized stimuli to be presented for tests of visual func-              required to conduct the full test sequence needed to be
tion, yet permit easy future expansion to include newly                 extremely short since our subjects were very young in-
developed tests. The system is presently used to record                 fants whose attention span is limited in duration. The ex-
several classes of electrophysiological measurements                    perimenter therefore had to collect data extremely rapidly
                                                                        for any given test, then quickly proceed to the next test so
                                                                        that as much data as possible could be acquired from the
  The author wishes to thank Ray Hunter of the St. Louis Children's     infant. Second, the data acquisition and analysis system
Hospital for his support of the Infant Vision Laboratory, and Barbara   had to be run by a single experimenter who also had the
Steinman for her many helpful comments on earlier drafts of this man-   responsibility of observing the infants' state of alertness,
uscript. Correspondence should be addressed to S. B. Steinman, De-
partment of Biomedical Sciences, Southern College of Optometry,         as well as direct the infants' attention to the stimulus dis-
1245 Madison Ave., Memphis, TN 38104-2222 (e-mail: steinman@            play. This not only reinforced the need for speed oftest-
sco.edu).                                                               ing but also ease of operation. Finally, the software sys-

Copyright 1998 Psychonomic Society, Inc.                            392
MAC RECORDING SYSTEM                    393

 tem needed to be modular and easily extended when new           In the interest of rapid completion of test sequences for
 tests of infant vision were introduced.                         our infant population and the need to constantly monitor
    The first major design decision was to choose the Lab-       the infants, it was imperative that the experimenter in-
 VIEW programming language as the language in which              teract with only one of the two computers. An experi-
 to implement the data recording and analysis software.          menter could not realistically set recordings on one com-
 LabVIEW is a visual or iconic programming paradigm,             puter, launch a stimulus program and set its stimulus
 which includes a huge library of data acquisition and           parameters on the second computer, then coordinate the
 data analysis code modules (called virtual instruments,         data acquisition and stimulus display on both computers
 or VIs) that may be incorporated to build electrophysi-         all while observing the infant subjects.
 ology or oculomotor recording systems. In addition, Lab-            More importantly, the two computers could not simply
 VIEW's integrated user interface design tools allow the         run in isolation. Both the recording program on one com-
 construction of software with a uniform intuitive "front        puter and the stimulus program on the other computer
 panel" of controls that can be easily operated by a exper-      had to "know" what the other was doing at any given mo-
 imenter. The visual programming paradigm allows for             ment. Their operations needed to be tightly synchronized
 rapid application development (RAD) or prototyping in a         if the two computers were to act as a single unit. This was
 fraction of the time required to write an equivalent CIC++     important not only for coordinating the stimulus presen-
 program (e.g., see Steinman & Carver, 1995).                   tation at the onset of the data recording but it was even
    Unfortunately, while LabVIEW is well suited for de-         more critical for the time-locked stimuli used for evoked
 veloping software for data acquisition and analysis, it is     potential recording. How would the two computers
 not capable of generating rapid animated stimulus dis-          intercommunicate?
 play graphics. In fact, LabVIEW can operate at a very               A design decision was made to control the overall op-
 high speed only ifit displays recorded data after the data      eration of the laboratory software using one Macintosh
 acquisition sequence is completed. Simultaneously con-          computer containing an analog data acquisition board.
 trolling visual stimulus display while recording and            In addition to data acquisition, this computer would also
 graphing data is not feasible within the LabVIEW envi-         be responsible for data analysis and report generation.
 ronment. One possible solution that was considered was         The second computer would act as a "slave" to the re-
 to call Macintosh ToolBox and QuickDraw routines via           cording computer-that is, it would act only in response
 external C language external code modules. Unfortu-            to commands sent to it by the "master" recording com-
 nately, these graphics routines cannot be called in parallel   puter. This slave computer would be responsible solely for
 with the data acquisition VIs if rapid execution of the        stimulus generation. These two computers will be referred
 data acquisition code is to be achieved. An additional         to henceforth as the recording computer and the stimulus
problem is that stimulus programs for vision research           computer, respectively. Clearly, two forms of communi-
typically involve interrupt-driven code to ensure accu-         cation were required that would be executed indepen-
rate visual stimulus motion velocity or accurate exposure       dently. The first was to transmit commands from the
duration timing.                                                recording computer to the stimulus computer. If the
    The simultaneous generation ofstimulus graphics and         recording computer was to be used as a central command
data acquisition is risky on a single machine since the         station to oversee the operation ofthe entire computer sys-
processor interrupts of the data acquisition software and       tem, it would need to "tell" the stimulus computer what
those of the stimulus generation code might interfere           stimulus to display and when. The second form of inter-
with each other, and data samples might be "skipped" dur-       communication was to maintain tight control over the tim-
ing graphics operations or the graphics may "shear" when        ing of the sequence of events during data acquisition-
data samples are acquired. These same interrupt issues          that is, (1) trigger or sync signals to initiate analog signal
may arise even if the data acquisition and stimulus gener-      acquisition sampling, to initiate signal averaging sweeps,
ation are handled by separate programs on a single com-         or to indicate the completion of the data acquisition pe-
puter. Furthermore, even ifthe possibility of conflicting or    riod, and (2) a "ready" signal to indicate that the stimu-
"missed" interrupts were not an issue, Quickdraw graph-         lus program had completed all of the preprocessing re-
ics operations on the Macintosh computer are not yet rapid      quired to display a visual stimulus. Digital I/O lines were
enough to allow simultaneous high-speed electrophysi-           used to transmit these signals.
ological data acquisition, data display, and animated stim-         Finally, two more decisions related to programming
ulus displays on a single computer system.                      language had to be made. The first was which program-
   Therefore, the system design selected was to imple-          ming language to use for the stimulus generation soft-
ment the system on two Macintosh computers: one solely          ware. As stated above, the LabVIEW language is not op-
for recording, and the other solely for stimulus display.       timal for the programming of rapid or interrupt-driven
This would allow each computer to perform its single            animated graphics. A second constraint was that this lan-
specialized task at maximum speed-that is, the stimu-           guage had to support programming of intercomputer
lus display generation would not slow down the rate of          communication through AppleEvents, the Macintosh's
data acquisition and data display. This decision to use         standard interprogram communication protocol. Lab-
two computers, in turn, created additional design issues.       VIEW has some capabilities for sending AppleEvents
394      STEINMAN

 (with provisos to be mentioned below), but it has extremely   trolled stimulus onset and offset, or acted as a "program
 limited abilities to respond to AppleEvents. Because of       ready" signal.
 its abilities to overcome these constraints, the c++ pro-         The second connection was an EtherTalk network cable
gramming language was chosen for developing the stim-          between the two computers, but which was not connected
ulus display programs. C++ not only allows for the rapid       to any local area network. This provided the means of in-
 interrupt code required for accurately timed stimulus         tercomputer communication for stimulus control by the
display palette or frame animation (see Baro & Hughes,         recording computer. Why was the more expensive Ether-
 1991, Steinman, 1993, and Steinman & Nawrot, 1992,            Talk used rather than standard built-in AppleTalk? In ini-
for such graphics techniques) but is also well suited for      tial testing of the software system, it was found that in-
handling AppleEvents. In addition, the use of C++ al-          tercomputer communication over an AppleTalk network
lowed the reuse of graphics, digital I/O, timing interrupt,    was too slow. When AppleEvent commands were sent to
and experiment control code libraries written previously       the stimulus computer, the recording computer often had
by the author, which could in turn be reused for future        to wait for a "reply" that indicated that the command was
programs.                                                      received correctly. An AppleEvent could "time out" while
    Although AppleEvents would be involved in the inter-       waiting for this reply if the transmission time for the
program communication between the data acquisition             AppleEvent and its reply was too long. This would lock
and stimulus display computers, they could not be used         up the data acquisition sequence as the recording com-
uniformly throughout the software due to limitations in        puter kept waiting for the reply. The much quicker Ether-
LabVIEW's interprogram communication code, to be               Talk was the solution to this problem, allowing replies to
discussed below. One possible solution to this problem         be received fairly instantaneously.
would be to use AppleScript to transmit scripts contain-           It could be argued that the EtherNet connection that
ing sequences of AppleEvent commands. A decision was           carried AppleEvents from one computer to the other
made to forego AppleScript, even though the Macintosh          could be replaced by a simple high baud rate serial line.
operating system (System 7.0 or higher) provides built-        However, there is one disadvantage to doing so. In the
in AppleScript support. For reasons to be discussed below,     current system, both the LabVIEW recording program
the interprogram communication was implemented with            and the C++ stimulus display program are not aware of
the Frontier scripting language (Userland Software In-         whether they reside on two computers or on a single
corporated, Redwood City, CA; now available as free-           computer. The use of Frontier as an intermediary for
ware on the World-Wide Web at http://www.scripting.            passing commands hides these details. This means that
com/frontier/).                                                if the present stimulus generation and recording system
                                                               could be implemented on a single computer in the future,
 Hardware Components                                           all that would need to be done is to edit one subset ofFron-
    The computer hardware system was composed of two           tier scripts. Neither the recording software nor the stim-
 Macintosh Quadra computers (Apple Computer, Cuper-            ulus display software would need rewriting. If a serial
 tino, CA). The recording computer was configured with         line had been used instead, all of the interprogram com-
 20 MB of RAM, a 128-MB magneto-optical drive for              munication code would need to be completely rewritten
data storage, and a laser printer for hard copies ofelectro-   if these programs resided on one computer.
 diagnostic and oculomotor data. Data acquisition was
performed with a high-speed analog-to-digital (A/D)             Software System Operation
converter board (NB-MIO-16XH-42, National Instru-                 For a better understanding of the workings of the vi-
ments, Austin, TX).                                            sion assessment software, the general test sequence for
    The stimulus computer was equipped with 8 MB of            recording from subjects is as follows: The main program
RAM and a video scan converter (CVLink, DisplayTech            is entered, which establishes the connection between the
Incorporated, Concord, CA) for display of visual stimuli       recording and stimulus computers across the EtherTalk
on a 60-in. diagonal television monitor (VS-60VF2, Mit-        network. The two DIO lines are then initialized. At this
subishi Electronics America Incorporated, Cypress, CA).        point, the experimenter selects a test to be run.
A digital input-output (DIO) interface provided control           A command is transmitted to the stimulus computer
signals to a digital to analog (D/A) converter that pre-       to launch a given stimulus display program, a graphics
sented sinusoidal flicker for binocular beat VEPs via sets     program that will display such targets as a drifting sine-
of light-emitting diodes embedded in a pair of goggles.        wave grating. The stimulus parameters chosen by the ex-
    The two computers were connected in two ways. The          perimenter are transmitted to the display program by a
first connection was composed ofDIO interfaces in each         second command. The experimenter then clicks on a but-
computer (NB-DIO-96, National Instruments) joined by           ton on the recording computer screen to start recording,
a ribbon cable, which provided the path for rapid control      and a digital signal is sent to the stimulus computer to
signals to synchronize the actions of the two computers        enable the stimulus animation. The display computer re-
during the real time. These included a digital trigger line    turns a digital signal to trigger data acquisition, time-
for ERG and YEP recordings and a sync signal that con-         locked to the stimulus display. After data collection is
MAC RECORDING SYSTEM                     395

completed-that is, a specific number of electrophysio-           system, there are several performance issues that com-
logical recording data samples are collected by the record-      pelled us to use Frontier instead, as will be discussed below.
ing computer-commands are sent to the stimulus com-
puter to stop the stimulus presentation, then quit the             Interprogram Communication
stimulus display program. Data analysis is performed off           Problems and Solutions
line at a later time so that additional tests with different          Although data acquisition and analysis with LabVIEW
stimulus parameters may be run in rapid succession while           are topics worthy ofdiscussion, information on these areas
the subject's (usually an infant) attention may be main-           can easily be obtained elsewhere (Johnson, 1994). What
tained. The analysis programs are included as modules in           we will discuss in the remainder of this paper will be a
the software system and operated in much the same way              topic on which little information has been available: the
as the recording modules.                                          techniques required for rapid simultaneous stimulus
                                                                   graphics and data acquisition. With a novel combination
 Software Components                                               of different programming tools, several problems that
    The software system has been designed to be both flex-         are specific to real-time simultaneous visual stimulation
 ible and modular. It was composed of three major com-             and data acquisition have been solved. Specifically, we
 ponents. The first was implemented in the LabVIEW 3.0             will present an easy way to synchronize two Macintosh
programming language (National Instruments, Austin,                computers to work as a single electrophysiology labora-
 TX) on the recording computer. This code was responsi-            tory device, via software commands and hardware signals
ble for establishing the AppleEvent communication link             passed between.
between the two computers across the EtherTalk network                The first problem that we had to confront and solve
and initializing the analog and DIO boards. The experi-            dealt with shortcomings in LabVIEW's capacities for in-
menter selects with a mouse pointing device which test             terprogram communication. While AppleEvent support
 is to be run, and the program enters one of several test-         is included in LabVIEW, it is mostly specialized as VIs
 specific subprograms for acquiring physiological data.            that are used to execute other VIs, such as AESend Run VI,
 Each subprogram allows the specification of stimulus             AESend Open, Run, Close VI, AESend Close VI, AESend
and recording parameters, as well as starting, pausing,           Abort VI, and AESend VI Active", or responses to these
or aborting data acquisition. A uniform user interface             commands. For programs composed of code other than
across all tests simplifies operation ofthe tests and permits      its own VIs, LabVIEW is more capable of responding to
the examiner to devote more attention to observing the            commands than sending them.
subject's alertness and behavior.                                     A few other AppleEvent-related VIs exist, which are
    Visual stimuli are presented via the second component         geared toward starting or quitting other programs, but
of the software, a collection of very small programs that         these are not sufficient for laboratory program control.
were written in the c++ programming language (Code-               Fortunately, a LabVIEW VI that is often overlooked by
Warrior C++, Metrowerks Incorporated, Mooers, NY;                 programmers just happens to be the one VI that is criti-
Resorcerer, Mathemaesthetics Incorporated, Chestnut               cal for controlling the operation of the stimulus graphics
Hill, MA). These programs take advantage of a reusable            programs by the recording computer. This VI is called
code library of drawing and animation routines devel-             AESend Do Script. As its name implies, it is specialized
oped by the author (SMS Technologies, Ann Arbor, MI)              toward sending scripts-sequences of commands en-
that allows both palette animation for drifting and counter-      coded as textual strings. Scripts may be written in any of
phase gratings (Baro & Hughes, 1991) and frame anima-             several languages created for interprogram control on the
tion for moving complex shapes as pursuit stimuli (Stein-         Macintosh, such as AppleScript (where the commands
man, 1993; Steinman & Nawrot, 1992). These programs             . are sequences of AppleEvents to be executed) or Hyper-
perform only three chores: (1) receive AppleEvent com-            Card. When such scripts are received by a target program,
mands (to be discussed below), (2) display animated               their text is decoded into the series of instructions to be
graphics, and (3) read and write to the DIO lines for syn-        carried out by that program.
chronization with the recording software.                             The next decision was therefore to choose a specific
    Coordination between stimulus generation and data ac-         scripting language. The most commonly used system-
quisition was established by the third component of our           wide scripting language on the Macintosh is AppleScript.
software system, which sends and receives AppleEvent              However, the use of AppleScript presents several obsta-
commands between Macintosh programs (see Apple                    cles. The first is that while AppleScript is very benefi-
Computer, 1991), in this case between the data acquisition        cial for sending sequences of instructions to programs, it
program on the master (recording) computer and various            is relatively slow, even on rapid PowerPC-based Macin-
stimulus programs on the slave (stimulus) computer. The           toshes, on which it is executed in emulated 68000 code.
transmission of commands from one computer to the                 AppleScript is therefore not very well suited for programs
other is mediated by Apple Open Scripting Architecture-           that need to execute subject test sequences quickly.
compatible scripts in the the Frontier scripting language.            A second problem is that AppleScript (as well as
While AppleScript, another means ofsending such com-              AppleEvents themselves) was not primarily designed for
mands, is a built-in component ofthe Macintosh operating          sending commands quickly over a network to a second
396      STEINMAN

 computer. To send an AppleScript or AppleEvent across copy of Frontier on the second computer. This second
 a network, the PPC Browser must be invoked. The PPC copy of Frontier translates the command into AppleEvent
 Browser is intended to allow users to choose which com- format and relays the command to the stimulus program,
 puter and application should be sent a command, but it where the command is carried out.
 also has one shortcoming for our purposes. It provides a         Why use such a circuitous route? Why not just send
 level of security on the network. After the computer and scripts directly from the LabVIEW recording program to
 program with which to "connect" have been chosen, the the stimulus display program on the second computer?
 operator must enter their user name and password for Two reasons have already been mentioned: (1) Frontier
 access to the second computer's program via the User speeds up the transmission of commands across the net-
 Identity dialog box. While this is useful for preventing un- work, and (2) to avoid the need to add AppleScript-parsing
 wanted connections across the Internet, it is a severe im- code to each stimulus program. Let us add two more im-
 pediment to our design goals. Every time we need to send portant reasons to use Frontier as an intermediary in pass-
 an AppleScript or an individual AppleEvent to a differ- ing along commands: (3) Frontier simplifies our program-
 ent stimulus display program, we will be faced with the ming task by translating the original command from
 PPC Browser and User Identity dialog boxes! This is not LabVIEW's Do Script VI, which is in textual script for-
 only disruptive, but it will slow down our data collection. mat, into a form that can be handled with simple code in
    A third problem is that if only AppleScripts are trans- the stimulus programs-AppleEvent handlers. (4) Be-
 mitted to the stimulus computer in order to initiate a stim- cause Frontier itselfsends the commands across the Ether-
 ulus display, these stimulus programs must be capable of Net network, the intrusive PPC Browser and User Identity
receiving and parsing AppleScripts. This presents a very dialog boxes are avoided during the time-critical portions
 difficult task for several reasons: (I) AppleScript pro- of data collection.
 gramming is not entirely intuitive and few example pro-          When the Lab VIEW program on the recording com-
grams exist for learning to do so. It is a difficult enough puter must find a program on the stimulus computer to
task that only a relatively small proportion of commer- which to "connect" and send commands, it connects to
cial Macintosh programs are scriptable. (2) AppleScript the master copy of Frontier on its own machine. Simi-
programming also requires programming knowledge larly, the slave copy of Frontier on the stimulus computer
 about "aete" resources, special Macintosh resources that connects to stimulus programs that reside on its own
 identify the AppleEvents that may be "understood" by the computer. These two communication paths do not re-
receiving program. The steps required for the creation of quire the PPC Browser or User Identity dialog boxes,
these resources are not very well documented. (3) In the since each connection between programs is made within
present software system, this would require adding Ap- a single machine. The connection between the two ma-
pleScript support to each of a dozen small stimulus dis- chines is made by Frontier itself before the LabVIEW
play programs. While adding AppleScript is a fruitful op- program is executed, by means of its NetFrontier suite-
tion for single large commercial programs, the time and a collection of scripts that deals solely with intercon-
effort required to add AppleScript support to several necting two or more copies of Frontier on different com-
small specialized laboratory programs are simply not cost puters connected across a network.
effective. We have selected an alternative that is simpler,      Before launching the LabVIEW recording program in
yet overcomes many of the limitations of AppleScript.          an experimental session, a small Frontier script is run on
    That alternative is Frontier, the first system-wide the recording Macintosh that results in the master copy
scripting environment released for the Macintosh com- of Frontier on that Macintosh establishing a connection
puter (even before AppleScript), now available as free- across the network to the slave copy of Frontier on the
ware on the World-Wide Web. Although Frontier is not stimulus Macintosh. This is the only time at which the
an integrated part of the Macintosh operating system (as PPC Browser and User Identity dialog boxes appear. Dur-
is AppleScript), it is widely used by commercial soft- ing all subsequent experimental testing, these dialog boxes
ware developers as the scripting language of choice. It never reappear, even when the experimenter switches be-
can transmit sequences of AppleEvents across a network tween test types and stimulus types, because the connec-
at least 10 times more rapidly than AppleScript scripts, tion across the network has already been established from
and it does not require the creation of aete resources. one copy of Frontier to the other.
   In our laboratory electrophysiology system, Frontier          It should be noted that we have had to modify the ar-
is installed on both the recording computer and the stim- guments passed to some ofthe NetFrontier commands to
ulus computer. When a command must be sent from the include a second parameter that allows the option ofwait-
LabVIEW program on the recording computer to a vi- ing or not waiting for a reply during transmission of a
sual display program on the stimulus computer, it is first script to the stimulus computer. This is because, by default
sent as a script from Lab VIEW to a "master" copy of Frontier waits for a reply from the receiving application.
Frontier on the recording computer. This Frontier appli- When we send commands to show visual stimuli just as
cation is "told" to run a script stored within itself that es- we are about to begin data acquisition, we cannot afford
sentially transmits the command contained in the original the luxury of waiting for a reply, because this would
LabVIEW script across the EtherNet network to a "slave" delay the onset of the data acquisition. It is therefore im-
MAC RECORDING SYSTEM                 397

perative to have the option of avoiding a reply. We do this               gram to a stimulus program will be explained in detail-
in our Frontier scripts by replacing Frontier's appleEvent                in particular, the version of this script that is used to set
command, which performs the actual transmission of in-                    up and execute a counterphase-reversing grating presen-
formation across the network, with the similar finder-                    tation program for pattern YEP recordings. This code is
Event command;finderEvent, by default, does not wait                      used once the recording and stimulus parameters have
for a response. This command was original1yintended for                   been chosen in the LabVIEW program and we are ready
sending scripts from Frontier to the Macintosh System                     to initiate data acquisition in response to the grating
7's Scriptable Finder, but it also suits our purposes well.               stimulus. The LabVIEW program initializes data acqui-
   Once the intercomputer connection is made, we launch                   sition, then sends a runStimulus script containing coun-
the LabVIEW recording program and set stimulus and                        terphase grating stimulus settings to the Frontier appli-
recording parameters prior to data collection. Setting                    cation on the stimulus computer. Frontier then repackages
stimulus parameters requires sending commands and                         the text contained within this AppleEvent into a format
data across the EtherTalk network, as dictated by scripts                 that can be sent to and understood by the copy of Frontier
sent from LabVIEW to Frontier within the recording                        on the stimulus computer-a Frontier script. On receipt
computer. But LabVIEW's script transmission VIs expect                    of the restructured script, the stimulus Macintosh's Fron-
to be sending commands by connecting to another pro-                      tier application executes the script, extracts its param-
gram across a network, and we do not want that to occur.                  eters, and sends the parameters within an AppleEvent to
We want LabVIEW to communicate only with the copy                         the stimulus display program. An AppleEvent handler in
of Frontier hosted on the same computer, and let this copy                that program retrieves the stimulus settings from the
of Frontier handle the communication across the net-                      AppleEvent parameters and displays the stimulus after
work to the stimulus computer. In other words, we have                    sending a sync signal via the DIO lines to let the record-
to force LabVIEW to establish a connection directly to                    ing Macintosh know that it is time to start acquiring data.
the Frontier application within the recording computer.                   The net result is that the stimulus program only needs to
   We take advantage of a LabVIEW PPC Toolkit VI                          receive an AppleEvent and its parameters in an easy-to-
named Get TargetID, which receives the name of the ap-                    extract format, rather than a textual AppleScript that re-
plication to find and return its target ID. The target ID is              quires complex code to decipher. In other words, the dis-
a LabVIEW structure (or "cluster" in LabVIEW termi-                       play program need not "understand" the scripting code
nology) that stores the location of a program that exists                 output by LabVIEW or the scripts transmitted by Fron-
on the network. We restrict the search to the copy of Fron-               tier. Such code is difficult to decipher by C++ programs.
tier on the same machine hosting the LabVIEW record-                      Rather, it need only understands very basic, low-level
ing program. The target ID returned by this search is used                AppleEvents, which require a minimum ofprogramming
in all subsequent command transmissions to Frontier.                      to decode. Our Frontier programming has allowed us to
   Now that we have examined the framework by which                       simplify our programming task for each stimulus display
LabVIEW and Frontier communicate between them-                            program to the point that each program need only be a
selves to establish control across a network, we will dis-                small skeleton program written in C++, consisting solely
cuss the special programming steps required to send both                  of AppleEvent-handling and stimulus generation graphics
commands and data from the LabVIEW recording pro-                         code. The message passing pathway between the record-
gram to their real target, the C++ stimulus display pro-                  ing and stimulus computers is summarized in Figure I.
grams. In the example code to follow, the runStimulus                        One aspect ofthis interprogram control that has not yet
command transmitted from the LabVIEW recording pro-                       been discussed is the launching and quitting of the stirn-

                                                                   (~-aurMrm) ....
                             ~~netRunStlm8Cl1p                                             < l,,=p1f
                             ............             Frontier"'
                         ;
                                               .. ,                   (8CIfpt,.,.)            .. (8tImJl8IW11 )
                       I( Scrfpt
                                                                                              '
                                                                   NelFIOI1IIer IIJfIScrt1t
                                                                                         ;+
                                            teAt )
                         AppIeEvert                                                               (8tImpeIWI'I   )
                                                                                                   AppIeEvert
                                                                                                           ...:.ou
                                             Do SCript VI I
                                       LabVlEW- conIroI ard                              AERunStlm
                   I                     recorcIng prognm                               C++ sttmulus progrsn

                         Recording Computer                                          Stimulus Computer
                             ("master")                                                   ('Islavell)
                      Figure I. Summary of command transmission from LabVIEW to the C++ stimulus dis-
                   play programs. Frontier translates the script sent by LabVIEW into simpler AppleEvents
                   and transmits them across the EtherTalk network.
398      STEINMAN

ulus display program prior to and following data acqui-       AppleEvents to be received by the stimulus program. Such
sition. Frontier simplifies these tasks as well. NetFron-     a system would also be lower in cost and easier to main-
tier can instruct the copy of Frontier on the stimulus        tain. It is likely that extremely rapid PowerPC processors
computer to execute two other Frontier commands. The          may eliminate the need for dual dedicated computers. A
first is Frontier's launch command, which sends an Apple-     single extremely rapid PowerPC processor would not only
Event via the Finder to launch a program. This command        speed up graphics and data acquisition code but would
finds an application whose signature we supply. The sec-      also decrease the time required to process interrupts, re-
ond command, to be used after data collection, is Fron-       ducing the likelihood that graphics and data acquisition
tier's quit command, which instructs an executing pro-        interrupts would have mutually deleterious effects. An-
gram to quit itself.                                          other important benefit ofFrontier will become evident in
   Frontier can therefore be used to handle all aspects of    the future when single PowerPC-based computer systems
the interprogram communication that is at the core ofthe      can be used for simultaneous stimulation and recording.
laboratory electrophysiology software. Frontier launches      Frontier can use the fast Component Manager of Power
the stimulus generation programs, signals each to display     Macintoshes for AppleEvent transmission within a single
stimuli with specific stimulus parameters, then forces        machine, which increases the speed of interprogram com-
them to quit when we no longer need them. The sole pur-       munication even more. However, even with the present
pose of the DIO lines is to ensure the tight time-locking     single-processor technology, we have demonstrated that
of stimulus display and data recording.                       the creation ofpowerful, flexible, real-time electrophysio-
                                                              logical laboratory software is facilitated when it makes use
 Conclusions                                                  of innovations found on the Macintosh computer. The
    In the construction of software systems, complex de-      same programming principles outlined in this paper may
 cisions regarding individual aspects of the system design    be applied to a wide range of psychology laboratories.
must be made that have serious implications for the de-
 sign of the remainder of the system. In the present case,    Availability of Code
 the overwhelming need for program execution speed dic-          The sample code described in this manuscript may be
tated the choice of a dual-computer system and the            obtained from the author bye-mail at steinman@sco.edu
 method of communication between the computers. Such          or by anonymous ftp from the MacPsych site.
 a system could not have been constructed easily without
 combining the strengths of the LabVIEW iconic labora-                                  REFERENCES
 tory programming language, the Frontier scripting lan-       ApPLE COMPUTER (1991). Inside Macintosh: Interprogram communi-
guage, and the c++ programming language. The use of             cation. Menlo Park, CA: Addison-Wesley.
Lab VIEW shortened the program development cycle              BAITCH, L. W., & LEVI, D. M. (1988). Evidence for nonlinear binocular
considerably. In addition, intercomputer communication          interactions in human visual cortex. Vision Research, 28,1139-1143.
ofthe speed and complexity used here would not have been      BARO, J. A., & HUGHES, H. C. (1991). The display and animation of full-
                                                                color images in real time on the Macintosh computer. Behavior Re-
achieved easily using C++ without the addition ofFrontier.      search Methods. Instruments. & Computers, 23, 537-545.
    Despite the complexity of this system, the software is    BARO, J. A., & LEHMKUHLE, S. (1988). A software system for recording
easy to operate by the experimenter due to the intuitive        and analyzing transient evoked potential data with an Apple lie com-
user interface imposed by LabVIEW's instrument panel            puter. Behavior Research Methods, Instruments. & Computers, 20,
                                                                515-516.
paradigm and the operation of all tests from a single pro-
                                                              DE WAAL, D. J., REITS, D., SPEKREIJSE, H.. & GRIMBERGEN, C. A.
gram on the recording computer. More importantly, the           (1983). Implementation of a portable pattern stimulator and VEPI
system design does not sacrifice modularity and expand-         ERG recording system based on an Apple microcomputer. Documenta
ability. Adding a new test requires adding only a small         Ophthalmologica Proceedings Series, 37, 209-216.
skeleton c++ stimulus display program, a few Frontier         JOHNSON, G. W. (1994). Lab VIEW graphical programming: Practical
                                                                applications in instrumentation and control. New York: McGraw-Hill.
scripts, and a few LabVIEW VIs to select stimulus param-      NORCIA, A. M. (1993). Improving infant evoked response measurement.
eters, send scripts, and record data. These code modules        In K. Simons (Ed.), Early visual development: Normal and abnormal
are very similar in each of the recording, stimulus, and        (pp. 536-552). Oxford: Oxford University Press.
intercommunication programs, largely due to a high de-        STEINMAN, S. B. (1993). Simple real-time color frame animation. Mac-
                                                                Tech, 9(9), 21-35.
gree of code reuse in LabVIEW, Frontier, and C++ li-
                                                              STEINMAN, S. B., & CARVER, K. (1995). Visual programming with Pro-
braries for handling AppleEvents and generating ani-            graph CPX. Greenwich, CT: Prentice-Hall, Manning Publications.
mated graphics. Much of the task of creating a new set of     STEINMAN, S. B., & NAWROT, M. (1992). Real-time color-frame ani-
tests simply involves duplicating then modifying exist-         mation for visual psychophysics on the Macintosh computer. Behav-
ing code.                                                       ior Research Methods. Instruments. & Computers, 24, 439-452.
                                                              TOROK, B. (1990). Microcomputer-based recording system for clinical
    In the future, it may be possible to remove some of the     electrophysiology. Documenta Ophthalmologica, 75, 189-197.
complexity of the system once it is possible to perform all   VAN NORREN, D., & VAN DE KRAATS, 1. (1983). Interactive computer
of the stimulus display and recording tasks on a single         program for clinical electrophysiology. Documenta Ophthalmologica
dual-monitor computer system. The interprogram com-             Proceedings Series, 37, 193-197.
munication could be restricted to one machine, eliminat-
ing the need for the NetFrontier suite: Scripts could be                      (Manuscript received October 7, J 996;
sent from LabVIEW to Frontier and directly translated into             revision accepted for publication January 31, J997.)
You can also read