Issue
102 January 1999
In
the Face of Medusa
Part
1:Developing Reliable Control
ROLL
THE CAMERA
A
second peripheral processor rotates a stepper motor
attached to an arm that holds a CCD camera. In this
application, the module must be able to home the camera
arm using an infrared interruption sensor, turn on IR
flood LEDs, and activate the CCD camera.
Moving
the stepper motor involves the same procedure that I
used earlier to extend the linear stepper motor driving
the syringes. The algorithm is:
- home
the camera arm at the beginning of experiment time
- wait
for a picture command from the x86
embedded system
- activate
the IR flood LEDs
- activate
the CCD camera
- wait
for end-of-picture command
- deactivate
the CCD camera
- deactivate
the IR flood LEDs
- move
the camera arm to next target
- execute
from step two until the end of the experiment
The
x86 system is equipped with a frame grabber.
So, the camera module executes the mechanical motion
and lighting procedures, freeing the x86
to spend its cycles obtaining the resulting image.
Although
not included in the algorithm, the module is also capable
of recalibrating the camera arm at any predetermined
time deemed necessary by the experiment scientists,
without interrupting the x86 processing
thread.
The
x86 can also authorize a recall operation
via command to the 4Q in charge of the camera stepper
motor. x86 failsafes for this 4Q are identical
to the Medusa 4Q, and the inclusion of an IR sensor
to monitor the IR LEDs is included in the camera-driver
module firmware.
As
far as the 4Qs are concerned, their destinies are clad
in firmware. You could control the remaining valves
and pumps with the x86 hardware, but theres
plenty of 4Q cycles left.
Another
strength associated with using peripheral processor
complexes is that, because each peripheral complex responds
to commands, functionality can be spread across all
of the peripheral processors regardless of their primary
job.
In
other words, if theres enough program code resource
and processor cycle time in the camera module to toggle
a valve and I can send a toggle valve command to that
4Q, then I can put the valve control functionality into
that 4Q.
Thus,
I can load balance my peripheral processors and still
conserve cycles on the main x86 board.
Basically, I end up with a simple half-duplex serial
network. The 4Qs dont speak until spoken to, unless
a failure of the x86 is suspected.
So
I can hang as many modules as necessary, and whenever
I need to, on this experiment. I both conserved x86
cycles and implemented a cost-effective distributed-computing
environment. The offloading of x86 CPU
cycles to the 4Qs enables use of a lower cost x86
embedded board, which next to the experiment hardware,
is the most expensive piece of computing equipment in
the experiment.