circuitcellar.com
Magazine Support   Digital Library   Products & Services   Suppliers Directory 
 
 





 

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 there’s 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 there’s 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 don’t 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.