Extendable high-speed stimulus generation and recording on the Macintosh computer
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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. 392MAC 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 AppleEvents394 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 isMAC 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 second396 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
