Inter-Computer Coordination
Volume Number: 13
Issue Number: 11
Column Tag: Programming Techniques
High-Speed Inter-Computer Coordination
by Dr. Scott B. Steinman
Combining C++, FrontierScript, LabVIEW and multiple Macs
to solve a real world problem
A few years ago, I was asked to put together an infant vision clinic that would offer not
only state of the art tests for assessing the function and health of an infant's visual
system, but which would also be fast, easily operated and flexible enough to readily
allow future expansion. It didn't take much thinking to come to the conclusion that only
the Macintosh could do it. But the programming was far from straightforward at the
time, since some of the system software that I needed had only just become available
and was not well documented.
This article will discuss the specific programming issues that had to be solved in order
to achieve the design goals of the clinic, as well as many of the workarounds that had to
be made. These issues also apply to other medical, scientific and engineering tasks.
We'll see that sometimes a seemingly more roundabout design actually produces a
simpler, faster and more flexible solution.
Design Decisions
The infant vision tests typically involved displaying a rapidly animated visual
stimulus that moved targets on a screen or changed the target's contrast dynamically.
At the same time, physiological data such as eye movement recordings or evoked
potential recordings ("brainwaves") have to be obtained in response to the stimulus.
Both tasks need to be executed rapidly -- the animation may be run at refresh rates up
to 60 Hz, while the data acquisition may occur at up to 1000 Hz.
While speed and flexibility are always two important design goals, the system had
additional restrictions that made these goals even more critical. First, the time
required to conduct the full test sequence needed to be extremely short since our
subjects were very young infants whose attention span is limited in duration. The
examiner has to collect data extremely rapidly on any given test, then quickly proceed
to the next test. Second, the same examiner who has to control the data acquisition also
has the responsibility of directing the infant's attention to a visual stimulus. This not
only reinforced the need for speed of testing, but also ease of operation. Finally, the
software system needed to be modular and easily extended when new tests of infant
vision were introduced.
I chose National Instruments' LabVIEW(tm) as the language in which to write the data
recording and analysis code. LabVIEW is a true "visual" (that is, iconic) dataflow
programming paradigm, much like Prograph CPX(tm). Visual programming allows
rapid application development (RAD) in a fraction of the time required to write an
equivalent C/C++ program (for example, see Steinman & Carver, 1995). LabVIEW
also includes a huge library of data acquisition and data analysis code modules (called
Virtual Instruments, or VIs for short) that may be used to build a recording system. In
addition, LabVIEW's integrated user interface design tools provide a uniform intuitive
"front panel" of controls that can be easily operated even by assistants.
Unfortunately, while LabVIEW is well suited for laboratory data acquisition and
analysis, it is not capable of performing acquisition and analysis while simultaneously
generating rapid animated visual stimulus displays. One solution that was considered
was to call Macintosh Toolbox and QuickDraw routines via external C language external
code modules, but these graphics routines could not be called in parallel with the data
acquisition VIs. Even if these routines were called in separate programs, running all of
these tasks on a single machine could still be risky since processor interrupts of the
data acquisition hardware and those of the visual stimulus animation code could
potentially interfere with each other -- that is, data samples could be "skipped
during graphics operations or graphics could "shear" when data samples are acquired.
We therefore chose to implement the system on two Macintosh Quadra computers --
one solely for recording and the other solely for stimulus display. This would allow
each computer to perform its single specialized task at maximum speed without
interfering with each other.
Both the recording program on one computer and the stimulus program on the other
computer had to "know" what the other was doing at any given moment. Their
operations needed to be tightly synchronized if the two-computer system were to act as
a single unit. The overall operation of the laboratory software would be controlled by
the examiner on the recording computer, and the second computer would act as a
"slave" to the recording computer. This computer would act only in response to
commands sent to it by the "master" recording computer.
This article will discuss the specific programming issues that had to be solved in order
to achieve real-time inter-computer coordination while meeting the design goals of
the clinic. I'll discuss many of the workarounds that needed to be made. These issues