4.9. IMPLEMENTACIÓN DE DIVISIÓN DEL SISTEMA ( ACTIVE
4.9.4. Implementación de división del sistema para T3_DQ, R-CE33,
3.3.4
Network
All Controllers have either Ethernet interfaces, or serial interfaces which are mapped to a Eth- ernet interface by a Beck IPC Microcontoller. The Ethernet interfaces are combined in a switch which has a fiber link connection to the main camera controlling computer. This Linux PC, which also is connected to the telescope controlling system, holds the main storage device and can be remote controlled via Internet. (See also Fig. 3.7.)
3.3.5
Electro-Magnetic Shielding
To protect the electronics of the camera against frequent lightning and the high radio immission of a nearby radio station it has a massive EM-radiation shielding. The shielding is made of 0.7 mm thick copper plate sheet and conductively connected to the mirror cell. Therefore this Faraday cage has only one major opening for the infalling light beam. Several minor openings are for wiring and a venting system, which is needed to avoid heating of the mirror cell by the camera electrics. An uninterruptible power supply (UPS) and the fiber link connection (Sect. 3.3.4) provide additional safety.
3.4
Controlling Software
The controlling software follows closely the lessons learnt by previous instrument upgrades to
MONICA, its offset guiding system and the 80 cm telescope software (TCS). We implement a
client /server architecture utilizing programs and libraries already developed for the TCS net-
work [Snigula, 2006, Chap. 7].
3.4.1
Controller interfaces
The CCD controller, connected to proprietary PCI boards of a PC via fiber link, is controlled through device drivers and a software called Voodoo [Streit, 2003]. Voodoo provides low-level C-routines for all controller functions as well as an exemplary Java-GUI.
Two HS-20E Multi-Axis Indexer/Controller of Cyberpak Co. [Cyb, 2001] are controlled via
serial interfaces which again are mapped through a Beck IPC device [Bec, 2006] to a TCP/IP
socket. The “native” motor controller commands are very cryptic if not incomprehensible. To make things worse some commands do not even work as documented. There are 8 motors alto- gether which have to be controlled: 2 blades per shutter, 2 filter sliders, guiding focus and field. Since only one Indexer can be active at a time and motors have either to move sequentially or at least with identical stepping we grouped the shutters with one controller and the filter sliders
and guiding with the other. This way the camera can take either “optionally interleaving” se-
quential4 or strictly parallel exposures. Exposures shorter than 5 seconds are accomplished by
the two shutter blades forming a slit which moves through the optical beam. Besides exposures 4Meaning that only one shutter blade can move at a time, but e.g. one channel can make a long exposure while the other takes several short ones.
48 3. AMiGo – A New, Two-Channel CCD Camera for Wendelstein Observatory
Camera Network Interface Scheduler
Thread Camera Daemon
Interface Thread
Admin Client Instrument Listener
spawns Command/ Reply send Status send Commands Client programs cleartext protocol
CAMD
CCD Controller Cryocontrol Motor Controller Controller Devices Thread receive Messages etc. Camera StatusFigure 3.8: AMiGo Server Daemon (camd) overview. Top: Client interfacing; centre: Main threads and status field; bottom: Camera controller interfacing.
3.4 Controlling Software 49
(and initialisation) all motors can only move one at a time. For additional information on specific motor controller commands see App. B.1.
The picomotors, vacuum and temperature control serial interfaces come all with their own proprietary protocol. They are relayed through the same Beck IPC device which also handles explicit interface multiplexing.
3.4.2
Server design and interface
Thecamera daemon (camd)follows closely theTCS daemon (tcsd)of Snigula [2006, Chap. 7].
The multi-threaded daemon has three principle threads (Fig. 3.8): Those are a main thread which spawns the client interface threads, a scheduler thread which takes care of executing the com- mand queue, and a camera controller devices thread which listens for camera status messages
from the different device controllers. The client interface threads supply an access hierarchy
provided by separate dedicated IP ports. Whileadminaccess allows control even to the level of
restarting the daemon or disconnecting clients, the user level client access gives only control to the camera functions. Both those access options allow only one client at a time. An additional
instrument port offers a distinct subset of the camera functions to give the possibility to trigger
commands from other instruments, i.e. the telesope or the guider. Finally, the listener port an-
nounces the full camera status every second and allows “unlimited5” connection instances. The
(human readable!) syntax of all commands and listener messages is summarised in App. B.2.
The internal access to the camera status representation structure is controlled by “mutexes” which
prevent simultaneous read and write access to the same status variable. For thecamdconfigura-
tion file options and syntax see App. B.3.
3.4.3
Client design – the GUI
Thecamd daemon already allows easy access to all camera functions, e.g. by an telnet session
on the client ports, and it even offers the possibility of scripting observation runs, e.g. viashell,
perlorpython. Nevertheless, a Graphical User Interface (GUI) is the easiest way to control the
functions of an instrument by a computer. Therefore, we built a Qt based [Haavard and Chambre- Eng, 2007] GUI (see Fig. 3.9 for a snapshot). The GUI implements image preview, a status log view, and overall camera control, i.e. binning(s), window(s), exposure time(s), filters etc. It
allows to toggle between different modes, i.e. a synchronous and an independent camera channel
exposure mode, scripting mode etc. There are already builtin “hooks” for autofocus and autoflat procedures supposedly working similar to those of MONICA (G¨ossl [1998] and Sect. 2.3.2), but those will be more complicated to implement because of the two channel design.
5Of course the system operating the daemon and the available network bandwidth limits the real number of possible listener clients.
50 3. AMiGo – A New, Two-Channel CCD Camera for Wendelstein Observatory
Figure 3.9: Snapshot of the AMiGo GUI: The GUI was coded utilising the Qt library [Haavard and Chambre-Eng, 2007] and therefore is cross-platform deployable. For a detailed description see text.