Engineering PapersSearch

Engineering topics

Conrad, A. R.

Publications and source records attributed to Conrad, A. R..

The Keck keyword layer

Each Keck instrument presents a consistent software view to the user interface programmer. The view consists of a small library of functions, which are identical for all instruments, and a large set of keywords, that vary from instrument to instrument. All knowledge of the underlying task structure is hidden from the application programmer by the keyword layer. Image capture software uses the same function library to collect data for the image header. Because the image capture software and the instrument control software are built on top of the same keyword layer, a given observation can be 'replayed' by extracting keyword-value pairs from the image header and passing them back to the control system. The keyword layer features non-blocking as well as blocking I/O. A non-blocking keyword write operation (such as setting a filter position) specifies a callback to be invoked when the operation is complete. A non-blocking keyword read operation specifies a callback to be invoked whenever the keyword changes state. The keyword-callback style meshes well with the widget-callback style commonly used in X window programs. The first keyword library was built for the two Keck optical instruments. More recently, keyword libraries have been developed for the infrared instruments and for telescope control. Although the underlying mechanisms used for inter-process communication by each of these systems vary widely (Lick MUSIC, Sun RPC, and direct socket I/O, respectively), a basic user interface has been written that can be used with any of these systems. Since the keyword libraries are bound to user interface programs dynamically at run time, only a single set of user interface executables is needed. For example, the same program, 'xshow', can be used to display continuously the telescope's position, the time left in an instrument's exposure, or both values simultaneously. Less generic tools that operate on specific keywords, for example an X display that controls optical instrument exposures, have also been written using the keyword layer.

Conrad, A. R.

CCD data acquisition systems at Lick and Keck Observatories

This paper will describe and compare two distinct but related CCD data acquisition systems (DAS) currently under development at Lick and Keck Observatories. Although these two systems have a number of major architectural differences, they share a considerable amount of common hardware and software. Both of these new systems build on a large body of proven software that is the foundation of the existing CCD DAS currently in use at Lick Observatory. Both will provide support for reading up to four on-chip amplifiers per CCD and/or reading out mosaics of CCD chips. In addition, they will provide the capability for interactive, real-time adjustment of CCD waveforms for engineering purposes. Each of these two systems is composed of three major subsystems: (1) an instrument computer and its software; (2) a data capture computer and its software; and (3) a CCD/dewar controller and its software. The instrument computer is a Unix workstation, and the functions it provides include user interfaces, the interactive real-time display of CCD images, and the recording of image and FITS header data to disk and/or tape. The data capture computer is responsible for the packaging and high-speed transfer of the CCD pixel data stream into a bulk RAM, and the subsequent transfer of this data to the instrument computer. The CCD/dewar controller generates the waveforms for clocking the CCD, digitizes the pixel data, and transmits it via high-speed link to the data capture computer. It is also responsible for monitoring and controlling the dewar temperature and cryogen levels. Given the number of different types of processors and high-speed data links employed in both systems, a major emphasis of this paper will be on the various forms of interprocessor communications utilized for data transfer and distributed process synchronization.

Kibrick, R. I.

The Keck Task Library (KTL)

KTL is a set of routines which eases the job of writing applications which must interact with a variety of underlying sub-systems (known as services). A typical application is an X Window user interface coordinating telescope and instruments. In order to connect to a service, application code specifies a service name--typically an instrument name--and a style, which defines the way in which the application will interact with the service. Two styles are currently supported: keyword, where the application reads and writes named keywords and the resulting inter-task message traffic is hidden; and message, where the application deals directly with messages. The keyword style is intended mainly for user interfaces, and the message style is intended mainly for lower-level applications. KTL applications are event driven: a typical application first connects to all its desired services, then expresses interest in specified events. The application then enters an event dispatch loop in which it waits for events and calls the appropriate service's event-handling routine. Each event is associated with a call-back routine which is invoked when the event occurs. Call-back routines may (and typically do) interact with other sub-systems and KTL provides the means of doing so without blocking the application (vital for X Window user interfaces). This approach is a marriage of ideas culled from the X window, ADAM, Keck instrument, and Keck telescope control systems. A novel feature of KTL is that it knows nothing about any services or styles. Instead it defines a generic set of routines which must be implemented by all services and styles (essentially open(), ioctl(), read(), write(), event(), and close()) and activates sharable libraries at run-time. Services have been implemented (in both keyword and message styles) for HIRES (the Keck high resolution echelle spectrograph built by Lick Observatory), LWS (the Keck long wavelength spectrometer built by UC San Diego), and the Keck telescope. Each of these implementations uses different underlying message systems: the Lick MUSIC system, RPC's, and direct sockets (respectively). Services for the remaining three front-line Keck instruments will be implemented over the next few months.

Lupton, W. F.