Download here.

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
Transcript
An Apogee CCD Instrument Module for Chimera
Cid Meyers, Earl Bellinger, Adam Biesenbach, Joshua Brown, Joshua Primrose, Dennis Quill,
Antonio Kanaan, Paulo Henrique de Silva, Dr Shashi M Kanbur
One of the great strengths of the CHIMERA control software is its adaptibility to different
hardware. Because of its modular control structure, CHIMERA is able to handle virtually any
conceivable configuration of telescope, CCD, dome, etc. that can be controlled by computer.
In addition, upgrades to existing installations are quite straightforward, requiring only that the
software driver for the upgraded hardware be rewritten, rather than the entire software
package.
One of the specific goals of the IRES 2010 project was to provide proof-ofconcept for the modular system by creating such an instrument module for
the Apogee ALTA CCD. The Apogee camera represents a substantial
upgrade to the currently-installed SBIG camera; the CCD surface is much
larger and capable of considerably higher-resolution images, and the
camera’s ancillary systems (cooling, image buffering, etc) are considerably
more advanced.
The strength of CHIMERA’s modular flexibility is derived from the interoperability of the
Python language and the C or C++ that most hardware drivers are written in. Through the
use of special header files and a program called SWIG, it is possible to create an interpreter
that can translate the CHIMERA core calls into lower-level commands. This interpreter, or
“wrapper,” can be compiled directly into the C driver module, providing an interface which
CHIMERA can use to control the hardware.
Overall, the process of creating the wrapper module was relatively
straightforward. The Apogee camera driver relies on TCL, which was not
initially present on the test system; however, once that dependency was
provided, the wrapper compiled smoothly, allowing for control of the camera
from the Python command line.
The process of creating the CHIMERA
instrument module was also a success, though a qualified one; though the
There are four links in the control chain: the hardware driver, or kernel module; the Python
module that interfaces with the driver; the CHIMERA “instrument” module, which relays
commands from CHIMERA to the Python interface; and the CHIMERA core itself. The only
part of the chain that has to be completely re-coded for each new instrument is the
instrument module. The driver is provided by the instrument manufacturer, though it has to
Apogee camera’s fans and cooling can currently be controlled from within the
CHIMERA system, the process of actually taking an image is quite
complicated, and time on the project ran out before the exact procedure could
be discerned and programmed. It seems certain, however, that working out
the exposure process would be quite possible given a little more time.
be recompiled using the special Python header files, the Python interface module is
automatically generated by SWIG, and the CHIMERA core remains the same between
Even though the Apogee camera is not fully functional within CHIMERA, it is
apparent that the concept is sound, demonstrating the flexibility and versatility
instruments.
of the CHIMERA system’s modular approach.
The instrument module, however, has to be able to correctly translate CHIMERA’s function
calls into something the Python interpreter will understand. In order to facilitate this, the
instrument module inherits functionality from CHIMERA’s generic instrument modules, such
as camera.py.
All of the functions provided by the camera.py interface have to be
implemented in the instrument module so that the functionality the core module expects is
preserved. This is accomplished, essentially, through trial and error, working from the list of
functions provided by the CHIMERA interfaces and manually translating them to the
functions that exist in the hardware driver. The process is time-consuming, but unavoidable,
as no standardisation with regard to driver calls exists amongst hardware manufacturers.
Still, as long as the manufacturer’s code is sane and their documentation adequate, it is
considerably easier and faster to work out the translations than it would be to write an
entirely new driver for the device.
With thanks to the NSF, through award NSF OISE 0755646.