There has been considerable progress in the area of slitmask fabrication and handling since the time of the PDR. First, the NC mill with 60,000 RPM head has been purchased by the project; this mill has been successfully used to fabricate LRIS slitmasks which were used for science observations. DEIMOS test masks have also been milled, held in place by the large-size magnetic chuck intended for this use. An identical second mill was purchased by CARA for immediate use in fabricating LRIS masks and later use for DEIMOS masks after DEIMOS commissioning.
Second, the expected method of slitlet milling has been tested: four corners are specified for each slitlet. The mill tool makes an initial pass to remove the bulk of material, and then cuts the actual slitlet edges. This appears to produce adequately clean and uniform edges.
Third, barcode scanners have succesfully read barcodes attached to mask stock. The scanners can reliably read the barcode labels at fairly steep angles, permitting the spacing of masks in the cassette to be reduced (and the number of masks in the cassette increased) accordingly.
Fourth, a detailed procedure for mask handling, particularly for avoiding misidentification between physical masks and mask designs, has been produced (see Part II, Chapter 1). A plan to mill an identifying barcode into the mask stock was tested and rejected, both because the milling was highly inefficient and because the resulting barcode could not be reliably read by the barcode scanners.
Lastly, the overall feasibility of software for mask design through fabrication has been verified. This software was written for LRIS masks, but the software should be easily adaptable for DEIMOS masks. The mathmatical mapping of sky positions onto the tilted cylinder of the slitmask (see Chapter 9) has been applied to LRIS masks and appears capable of subarcsecond accuracy; this means empirically-determined corrections to the sky-slitmask mapping should be small, of order a few tenths arcsec or less.
One unresolved item that arose is that the slitmask milling produces small chips of metal that must be cleaned out of the slitlets. The method for doing this has not been identified, but ultrasonic cleaners have been suggested as a probable solution.
Another identified concern is that the positional accuracy of the mill is of order 0.0003 inch, corresponding to about 0.010 arcsec at the telescope focus or 0.1 pixel at the DEIMOS detector. Reduction software will need to account for slit nonuniformities at this level, if such accuracy is desired.
During early planning for the DEIMOS instrument, the software team wanted some means of managing the large number of new (or slightly variant) keywords the instrument would need. We constructed a relational database schema for modelling FITS keywords, storing keyword attributes such as datatype, format, semantics, etc. The schema rapidly grew in complexity, incorporating new concepts such as interkeyword syntactic and semantic relationships, hierarchical keyword grouping, etc. See Part II, Chapter 7 (``Information Management") for more details on the database design and function.
Since any graphical user interface to KTL-based instruments can be seen as a visual representation of a collection of keywords, the keyword database became a valuable resource for developing our various instrument GUI.
A complete description of the ``Dashboard" philosophy, design, and
feature set will be found in Attachment I
. In brief, the Dashboard interface is a flexible, ``soft" interface
to any KTL service. It makes use of KTL keyword libraries and of the
Ktcl extension written by W. F. Lupton (CARA). Any supported keyword
can be represented on the dashboard surface by a variety of traditional
``meters" (i.e. X11 representations of a gas gauge, dial gauge, strip
chart, function light, push button, etc.).
The meters can be repositioned freely, and all their X11 attributes can be edited. The attributes can also be made to change in response to changing values or conditions of KTL keywords. Boolean expressions involving several keywords at once can be evaluated and used to trigger appearance changes, or to deliver alarms. The designer can also invent ``pseudo-keywords" as expressions involving KTL keywords, constants, and global variables. There is no distinction between editing the application and running it; the running application can be edited and redesigned while connected to a live KTL source. This reduces the turnaround time for testing new features to approximately zero.
A variety of graphical constructs such as lines, arrows, rectangles, circles, text, bitmaps, etc. can be placed on the dashboard surface for decoration and visual organization. These also can be reconfigured, resized, and made to respond to KTL conditions. Text is a valid graphical object and can be used to convey messages, warnings, status, etc. as well as to label areas or components of the UI.
The application is layered, that is, it is possible to pop up ``sub dashboards" by double-clicking on any graphical object. This metaphor is intended to support levels of lesser and greater detail, but can be used arbitrarily to create any type of popup screen.
Though the Dashboard in designer mode is extremely fluid (the user having the option to reposition, reconfigure, delete and create) it also runs in a ``production" mode in which the user has no such power. Our plan is to design the DEIMOS interface using the flexible ``GUI builder" mode, then ship a ``frozen," stable, fully-tested UI with the instrument for observer use. CARA and Lick engineers, as well as observers, could run the ``designer mode" Dashboard at any time to invent their own KTL control panels, but the canonical DEIMOS UI would remain unaltered except by official releases from the DEIMOS project engineers. We should note that the Dashboard also supports ``No Writes" mode, in which the user can see KTL keyword values but is not permitted to do KTL writes, and a ``No KTL" mode in which development can continue in the absence of a working instrument, telescope, etc.
A prototype interface has been developed using the HIRES instrument; this interface, while functionally not more than 50% complete, demonstrates and tests most features of the application. The ``Dashboard" application will be used to develop interfaces for the Lick Prime Focus Camera (PFCAM) and Keck ESI instruments, which ship earlier than DEIMOS; DEIMOS will benefit from the experience gained during those commissionings, just as the other two instruments have benefitted from DEIMOS investment in the keyword database and GUI development project.
Astronomer response to the ``Dashboard" product has been positive so far. We anticipate a good level of acceptance by users, but we also know that it is relatively trivial to alter the appearance and function of the finished product to resolve user complaints and new feature requests. We also anticipate that CARA and Lick engineers will find the ``roll your own" aspects of the tool very useful when setting up tests and diagnostics. Dashboard's logging and plotting features make it a handy ``logic analyzer" for KTL-based systems.
We have inserted a colour page into this chapter showing two generations in the evolution of the DEIMOS UI sketch. The earlier generation (upper half of the page) shows a colour-coded version in which each major stage in the light path was represented by a pastel box. The later generation, redesigned by Faber, Phillips, and Clarke, shows a less ``busy" colour scheme, but similar graphical design. The philosophy is to show an effective light path through the instrument as a simple progression from left to right. The UI should provide obbvious graphical indication of occultation, so that the observer can see easily whether light is reaching the detector, and from what source - but at the same time, the front end should remain very simple, so that the observer can interact (when all goes well) with a clean and uncluttered interface that does not occupy the entire workstation screen. The ``long and skinny" look of the DEIMOS prototype is deliberate; at some point we may need to display UI for both beams on one screen.
The second image of each version shows an interface state in which the user has changed a desired value (bottom half of the graphical representation of each stage) from the current value. The UI has lit up that area in yellow to indicate the discrepancy between Actual and Desired. When the GO button is pushed, and stages move to their new positions, the yellow highlighting will become orange or red, and will not return to its normal colour until the stage motion is complete. Many other graphical and text display strategies can be used to indicate intent, motion, and completion, but after many discussions the DEIMOS PI and software team are leaning strongly towards the model shown here.
The dashboard can save a current KTL setup for future inload. We are debating the desirability of loading KTL setups from FITS image headers (i.e. ``Set the instrument up the way it was when the image in this FITS file was taken.") It also has a scripting capability, offering the user an edit window for writing KTL control scripts.
Double clicking on any stage will pop up a more detailed interface for that stage, and those sub-dashboards may also contain popups for extreme levels of detail. However, once the instrument is calibrated, regular science datataking can be done entirely from the simple top level interface.
The Dashboard derives its knowledge about KTL keywords from the authoritative database; no keyword knowledge is hardwired into the application. It can cache the downloaded keyword data in a local ASCII file (in accordance with the DEIMOS project philosophy of imposing a layer of separation between database server and operational applications); but the cache can be refreshed at any time from the database server, and any changes of keyword definition and usage will then be known to the UI.
Context-sensitive help is built in automatically. By means of a Control-click the user will be presented with a complete description of the KTL keyword being monitored by any given meter. Also, with a slightly different mouse click (button 1 instead of 2) the meters will give the user hints on how to interact with them. Information about ``how to" use the mouse to get to these help facilities will of course be available from a visible menu, for the first-time or casual user.
Our experience with prototyping, to date, has been encouraging. It takes very little time to develop a dashboard panel, and each panel can be revised rapidly and easily as our design discussions progress. The Dashboard is based entirely on free and portable code, so it runs with equal facility on Digital Unix, Solaris, Linux (Dashboard on a Linux laptop is an attractive portable engineering tool), etc. Our 50% complete HIRES interface, which has been tested extensively against the running instrument, took less than 2 days to construct. We are fairly confident that UI design will not be a major consumer of DEIMOS programming resources, and that we will be able to respond quickly to initial user feedback and instrument changes.
In summary, we feel that we have substantive proof of concept for our GUI design philosophy, approach and toolkit.
Every project of this complexity needs a way to document design and process. Besides the usual reams of textual documentation, drawings and diagrams are needed for easier comprehension of highly complex systems. In our case, these systems can be seen in terms of information passing through various handlers on its way to a final storage medium.
Having already established the value of the online authoritative database of keywords and made a commitment to creating and maintaining it, we are in possession of a valuable resource for software and system design. Since the keywords (or more generally, ``memes") in the database represent information, we have already modelled half of the problem. The other half is the list of ``agent" or processing nodes through which information passes.
A keyword like TEMPDET, for example, can be seen as a piece of information (the detector temperature) which originates with a hardware sensor, is read via an ADC on a board in a VME crate, then is held in the crate's memory pending broadcast or on-demand transmission of this parameter to KTL clients. The keyword eventually ends up in a FITS header, captured at end of exposure, and the FITS header ends up on an Exabyte tape. The astronomer takes the tape home, and (from our point of view) the story ends there.
We could vastly simplify this chain of events, or we could document it in excruciating detail; but a piece of information certainly does ``move" through our hardware and software system on its way to an archival storage medium, and this motion can be modelled using the database.
We established a schema for describing information flow. One element of this schema is the table of Agents. An Agent is any hardware, software, or human element present in the observing or engineering process, which somehow handles (originates, transmits, stores, alters, or destroys) information. Since this code was written for the software group, naturally the Agents table describes software agents in more detail than any of the other types; it records module name, authorship, location of source in the CVS repository, language, brief functional description, etc. (and from this table, many pages of CDR documentation can be generated).
We then established a table Mpaths (meme paths) which describes the passage of Memes between Agents. We say that a meme travels from a Sender to a Receiver, via a Medium, in a Format, with a certain Timing, requiring a certain Elapsed Time, and on the instigation of a Controller of some kind. For example, the slit mask design file travels to the slit mask design collector via the medium of email, in the format of a text file, ``on demand", and the controller is the Observation Planner (the author of the file). We have created tables of Formats, Media, and Timing to collect and document all the varieties of these attributes which can apply. (See Chapter 7 for more description of the information flow database, and the Lick Observatory Technical Report - ``The Dictionary" for schema design details.)
Obviously an endless list of paths in textual form would be unreadable and useless documentation; we require a graphical representation of our design data. The free tool ``dot" (Koutsofios and North, Lucent Technologies) renders digraphs from a simple human-readable specification language which can easily be generated from our database. We generate dot-language, which dot then renders into PostScript. The result is a publication-quality drawing representing our software or hardware (or process) design. Several of these drawings appear in the CDR document, notably in Chapter 7.
That takes care of the output; but the input seems terribly tedious. Entering meme ID numbers and agent ID numbers for many hundreds of paths, even using GUI forms, menus, dialogue boxes and all the ergonomics we can afford, is not practical. We required a GUI design tool, something almost as easy to use as a pencil, but with the ability to dump data into the database (or extract and use data from the database).
We call the tool ``Etcha" (for obvious reasons). It provides a crude but adequate drawing interface in which the user can place and size (and re-locate and re-size) nodes (Agents), then draw paths between them to indicate the passage of Memes. The Agents and the paths are editable; editor panels pop up displaying all the known attributes of an Agent or a Path. The editor panels have limited query ability into the database, and can offer menus of legitimate values for a given attribute, or can ``look up" the attributes of an Agent by name, ID number, etc.
The Agent editor can even be used to add a new Agent to the database, so that the user does not need to leave ``Etcha" in order to correct an oversight in this regard.
The tool does not attempt to do any layout or rendering; it does exactly what it is told. The first attempt at this application used the powerful ``dged" Tcl suite (North and Ellson, Lucent Technologies), a realtime interactive version of dot. We found it disorienting and frustrating; the layout changed dynamically as new nodes were added and moved, or even across Save and Reload operations. Although ``Etcha" draws crude and simple pictures, it does nothing unexpected.
Once the user is content with the layout sketched on the Etcha screen, it can be Saved as an Etcha layout file (which can later be reloaded for reference or further development) and/or Committed to the database. The Commit operation wipes out all paths in the user's design ``context" and replaces them with the current drawing.
Etcha can also retrieve an existing context from the database. Having no layout or rendering ability, it cannot make a ``pretty" drawing from the data, but it can retrieve and display all the nodes and paths, leaving the user to reposition them in a sensible or comprehensible layout.
Etcha is still a young product, but so far it has proven easy to learn and quick to use. The Overview drawing seen in I.1 was produced in less than 3 hours, and can easily be modified by direct edit of the data or by further Etcha sessions and Commits.
One convenient peculiarity of the MFLowData schema and its interpretation is that ``contexts" (effectively, drawings) can be combined. If a flow diagram is too complex to be drawn comfortably with Etcha, it can be drawing in two, three, or more pieces given related drawing names (like DEIMOS.DB.out.doc and DEIMOS.DB.out.op). The drawing generator (traceFamily, documented in Chapter 7) is intelligent enough to recognize that a request for ``DEIMOS.DB.out" should include both DEIMOS.DB.out.doc and DEIMOS.DB.out.op, and the rendering program is intelligent enough to suppress any duplication and turn the two drawings into one unified picture. This flexibility is very useful, compensating for the limitations of physical screen size and Etcha's simplicity.
Since database Agents can be created in advance of the actual existence of code modules, Etcha can be used to plan and propose software designs, as well as to document what already exists.
We plan to use Etcha, the database, and dot to document and plan our software suite as well as the interactions of the software suite with other (hardware and human) agents. We are encouraged by our success so far; much of the documentation for this review has been generated from our various database resources, and we feel this bodes well for both online and paper DEIMOS documentation to be delivered with the instrument.
A sample Etcha session will be found in Chapter 7, Figure 7.4.
As part of the information management subsystem, we have implemented a keyword database for managing the hundreds of keywords associated with DEIMOS. These keywords are used to operate the instrument and are also recorded within the headers of the FITS images that the instrument produces. The online database serves as a central repository of authoritative information about keywords. Extracts from it are used to build configuration files for operational software (e.g., ``dashboard" user interfaces as described in section I.3.2) and to generate documentation.
The keyword database is fully operational and approximately 75% of the DEIMOS keywords (primarily those involved in spectrograph control) have been defined and entered into the database. Tools for generating a formatted and indexed keyword dictionary are also operational, and have been used to generate the major portions of Lick Observatory Technical Report ???: The DEIMOS Keyword and Database Dictionary. Copies of this dictionary will be available for review at the CDR, and as noted in section I.1.1, will be available via the WWW on or before June 13.
A sample page from this dictionary is supplied to provide an example of the information that is contained in the database (see Figure 3.1). For each keyword, the dictionary specifies:
Figure 3.1: Sample Page of Keyword Dictionary
The original platform for development of Keck instrument control code was Sun/Sparc running SunOS. The code management and development schemes for Keck software have been intimately dependent on features and tools specific to that one platform. Code management was done using the proprietary SCCS software from Sun. Makefiles for the code trees relied on features unique to Sun's version of make.
The inevitable evolution of computing hardware is now forcing a change from SunOS to Solaris. Furthermore, DEIMOS has been contemplating the use of Dec alpha systems for the observer's data acquisition and reduction workstations. The utility of Intel-based laptop computers for code development is another motivation for changing from the original scheme. During the past year CARA and UCO/Lick have collaborated on the design and implementation of significant changes to enhance portability.
It is imperative to maintain authoritative central repositories of the source code for the core system and for each instrument. However we also need to be easily able to propagate changes and bug fixes to and from each of the instrument development sites.
The Source Code Control System (SCCS) is not available on non-Sun platforms. Furthermore, the original scheme for its use had relied on the existence of NFS mounts over long distances. Evolving security issues on the ever-growing internet had forced the shutdown of this scheme some years ago. Since that time the separate code repositories at each site have been evolving without means of resynchronizing.
Both CARA and Lick have experience with a freely-available source code system known as CVS. CVS has already been ported to all interesting computing platforms. It provides an environment for code sharing and development which is both natural to use and robust against misuse by unfamiliar users.
CARA is the logical site for the repositories of telescope control code (ACS, DCS) and common instrument control code (KTL). In general, the instrument-building sites are the logical site for the repository of code for each instrument. The new versions of code described in this section have already been placed into CVS. Both CARA and Lick have already demonstrated that we can obtain source code from each other's repository.
CARA made an initial port of the Keck Tasking Library (KTL) code to Solaris during 1996. This port made minimal changes to the makefiles and source code. It relied on many of the compatibility features that Sun provided to ease the transition and was not suitable for non-Sun platforms.
At UCO/Lick De Clarke and Steve Allen adopted this Solaris port of KTL. The GNU autoconfigure program is a widely-used solution for ensuring portability across all platforms. The original KTL makefiles were replaced with GNU configure-style makefiles, many sections of BSD-specific code were replaced with POSIX-conformant code, and erroneous C code using pointers was made 64-bit clean. By the end of last year the same KTL code built and operated correctly on Sparc/SunOS, Sparc/Solaris, Dec alpha/Digital Unix, and PC Intel/Linux platforms.
Although they are completely portable there are several drawbacks of the GNU configure-style makefiles. They require each site to have the entire souce code tree, including portions only relevant to other instruments. They also require significant expertise on the part of each instrument development team in order to maintain them. CARA and Lick agreed that these aspects were not desirable.
William Lupton undertook the task of merging the centrally-managed
CARA scheme with the GNU scheme from Lick. His result requires the
use of GNU make, but it has been demonstrated to work on all 4
platforms. The makefiles run GNU configure once in the
kroot/etc directory to convert a config.mk.in file into
config.mk. The makefiles in all other branches of the code
tree include the config.mk file to inherit default rules and
platform dependencies.
A little more testing is needed before this scheme can be considered
final, but it addresses the needs of the code now and into
the future. It also implements a new installation scheme.
The original CARA installation procedure placed all of the installed
files into a single directory named kroot/rel/default regardless
of their function. Many of the installed files were symbolic links
into version-numbered directories resident within the source code tree.
Following ideas from several discussions between CARA and Lick,
Lupton has reworked the installation scheme.
The name of the new installation directory is configurable. Files which are executables, includes, libraries, and data are installed into a version-numbered directory in the install tree. Symbolic links to the current version are placed into separate bin, include, lib, etc. directories. All files installed from ``release points'' in the source code tree are placed into a particular version-numbered directory.
The discussions between Lick and CARA outlined one other desirable feature which is not currently included in the installation scheme. Certain branches of the source code must be built and installed before other branches may be built. We desire to be able to document exactly which versions of installed include files and libraries were used when each subsequent branch of code is built. Only with this knowledge is it possible to reconstruct an arbitrary previously-installed version of a branch. We expect to continue work on implementing mechanisms for recording this information.
During the past year the Keck source code has evolved from a state where it could only be built on a single outdated OS to a point where it can be run on a laptop or any other modern Unix variant. The shared portions of code can again be maintained by all interested sites. The installation procedures are much more conformant with standard existing practices. We believe that we will be able to allow all instrument development teams to continue porting this scheme to arbitrary new computing platforms with minimal effort by a single expert.
The software PDR contained descriptions of several different file structures for DEIMOS images. Not all of these structures have proved necessary, and there is now a clear distinction between archival FITS formats and interim formats suited for operational purposes. The specifications of procedures and dataflows for the design and manufacture of slitmasks are complete, and they use FITS tables to store and communicate information between observer, database, and mill control computer. The content of all these FITS files is detailed in this section.
Subsequent to the PDR we organized a Birds of a Feather (BOF) session on mosaic images at the 1996 ADASS meeting in Charlottesville, VA. This allowed us to interact with other sites planning mosaic detectors. As a result it became clear that some standards are emerging for archival storage of multi-amplifier CCD images.
Following the pattern of HIRES and LRIS the PDR suggested that image sections from several CCDs might be combined into a single FITS array. This is contrary to the consensus of the FITS mosaic community which indicates that raw data from each CCD amplifier will be stored in a separate FITS image file, even when the amplifiers are on the same CCD. This has the disadvantage of breaking spatially contiguous regions of image data into separate FITS arrays. However, it also permits existing software to handle differences in bias, gain, noise, and other electronic characteristics.
These files will be approximately 140 Mbytes in size, and in the case of dual-amplifier readout each image extension will exceed 8 Mbytes. IRAF version 2.11 contains support for multi-extension FITS files, and using beta releases NOAO has already demonstrated the processing of such images.
After pipeline processing, most of the electronic artifacts from each amplifier will be removed from the image sections. In the case of a single CCD where the pixels from several amplifiers are spatially contiguous, and the gain and noise characteristics of the amplifiers are sufficiently similar, it may be desirable to combine the image sections from the amplifiers into a single FITS array. This may ease the task of existing applications which perform astrometric and photometric operations on extended objects. However, this image format is only relevant in an archival sense if at some time there might be an archive of pipeline-processed DEIMOS images. As this is not in the current plan, we have not specified details of this format.
For the initial testing of the CCD mosaic we will be using Figdisp to display the images. During this interval the CCD data capture software will descramble the amplifier data into a single large image array so that Figdisp can display it all. Contrary to the scheme detailed in chapter 7 of the software PDR, this single large array will not correspond to a FITS image array.
When the prototype version of the NOAO RTD becomes available we intend to modify the data capture agent such that it stores the image sections from each amplifier using the archival format for raw images. NOAO is already testing their RTD with images in this format. The FITS grouper/ungrouper task remains available to assist computing systems which have difficulty manipulating single files of this size, but the DEIMOS systems will be capable of handling these large files.
See Part I section 4.1 for more details on the display issues mentioned in this subsection.
During the course of the design of the DEIMOS dataflows we determined that FITS tables and RDB tables can be employed in an isomorphic fashion. We have created procedures which directly ingest FITS tables to the RDB, and we can dump any RDB table into FITS for storage or transmission. For details of this see the database schema in Part II Section 7.7. The detailed contents of all RDB tables are contained in Chapter II.2 of the Dictionary.
The design of slitmasks produces dozens of slitlets from catalogs with hundreds of objects. It is an interactive, and often an iterative, process. This requires saving of state during the design in a mask DesignFile, and subsequent transmission of that file to Keck. Upon arrival at Keck the mask DesignFile is stored as DesignData in the database. At milling time the mask DesignData must be sent to the mill for fabrication of slitmasks. Details of these procedures are in Part II Chapter 1.
On the night of the observation the quick look display needs the mask DesignData to identify each of the spectra. For archival purposes the mask DesignData must be appended to DEIMOS images taken with a slitmask. Examples of the FITS table headers for the mask DesignFile are shown below.
The list of objects which were contained in slitlets is part of the archival information for the observation, and it is also used by the GUI during quick look display.
XTENSION= 'TABLE ' / ASCII table extension BITPIX = 8 / number of bits per data pixel NAXIS = 2 / always 2 for a FITS table NAXIS1 = xxx / number of chars needed to describe members NAXIS2 = xxx / number of objects in the catalogs PCOUNT = 0 / required FITS extension keyword GCOUNT = 1 / required FITS extension keyword TFIELDS = 19 / Number of columns in the table ---------------------------------------------------------------- EXTNAME = 'DEIMOS_Object_Catalog' / This table describes DEIMOS object catalogs EXTVER = 1 / Unique index of this Catalog table in file AUTHOR = 'Rocket J. Squirrel' / Identity of person who constructed catalog CATNAME = 'My Object Catalog' / Observer's pet name for catalog DATE = 'yyyy-mm-ddThh:mm:ss'/ Date of construction of input catalog table ---------------------------------------------------------------- NPRIKEY = 1 / Number fields contributing to primary key PKTYP1 = 'ObjPKey' / native TTYPE of primary key component 1 ---------------------------------------------------------------- The design application may find useful to remember the source catalogs whence the objects in this HDU originated. (I.e., it's a feature to save state such that the user/designer can more easily recreate a previous design session.) If so, the source catalogs can be stored in the manner described in these next two bunches of FITS cards. NFORHDU = 1 / Number of foreign HDUs referenced by this HDU HDLOC1 = 'path/to/catfile' / URI of file containing foreign HDU HDXTN1 = 'TABLE ' / FITS XTENSION type of foreign HDU HDNAM1 = 'Catalog_Files' / FITS EXTNAME of foreign HDU HDVER1 = 1 / FITS EXTVER of foreign HDU HDPOS1 = / Ordinal position of foreign HDU in URI HDSUM1 = '0000000000000000' / checksum of foreign HDU HDDCS1 = ' 0' / checksum of foreign data NFORKEY = 1 / foreign key component references from this HDU FKHDU1 = 1 / refers to index counted by NFORHDU FKCOL1 = / TBCOL of foreign key component in native HDU FKTYP1 = 'CatFilePK' / TTYPE of foreign key component in native HDU FKFOL1 = / TBCOL of primary key component in foreign HDU FKFYP1 = 'CatFilePK' / TTYPE of primary key component in foreign HDU ---------------------------------------------------------------- Here are the FITS table column descriptions TBCOL1 = xx / First character in column TFORM1 = 'I6 ' / Fortran 77 format of column TTYPE1 = 'ObjPKey ' / Primary key for table of objects TBCOL2 = 1 / First character in column TFORM2 = 'A40 ' / Fortran 77 format of column TTYPE2 = 'OBJECT ' / Name of object TBCOL3 = xx / First character in column TFORM3 = 'F11.7 ' / Fortran 77 format of column TTYPE3 = 'RA_OBJ ' / TUNIT3 = 'deg ' / Unit of measure of column TBCOL4 = xx / First character in column TFORM4 = 'F11.7 ' / Fortran 77 format of column TTYPE4 = 'DEC_OBJ ' / TUNIT4 = 'deg ' / Unit of measure of column TBCOL5 = xx / First character in column TFORM5 = 'A8 ' / Fortran 77 format of column TTYPE5 = 'RADECSYS' / TNULL5 = 'NULL ' / Indicates data not provided in input TBCOL6 = xx / First character in column TFORM6 = 'F13.6 ' / Fortran 77 format of column TTYPE6 = 'EQUINOX ' / TUNIT6 = 'annum ' / Unit of measure of column TNULL6 = '-99999. ' / Indicates data not provides in input TBCOL7 = xx / First character in column TFORM7 = 'F17.9 ' / Fortran 77 format of column TTYPE7 = 'MJD-OBS ' / TUNIT7 = 'diem ' / Unit of measure of column TNULL7 = '-999999. ' / Indicates data not provided in input TBCOL8 = xx / First character in column TFORM8 = 'F7.3 ' / Fortran 77 format of column TTYPE8 = 'mag ' / TNULL8 = '-99. ' / Indicates data not provides in input TBCOL9 = xx / First character in column TFORM9 = 'A6 ' / Fortran 77 format of column TTYPE9 = 'pBand ' / TNULL9 = 'NULL ' / Indicates data not provides in input TBCOL10 = xx / First character in column TFORM10 = 'F14.3 ' / Fortran 77 format of column TTYPE10 = 'RadVel ' / TUNIT10 = 'm/s ' / Unit of measure of column TNULL10 = '-999999999. ' / Indicates data not provided in input TBCOL11 = xx / First character in column TFORM11 = 'F10.7 ' / Fortran 77 format of column TTYPE11 = 'MajAxis ' / TUNIT11 = 'arcsec ' / Unit of measure of column TNULL11 = '-9. ' / Indicates data not provided in input TBCOL12 = xx / First character in column TFORM12 = 'F11.7 ' / Fortran 77 format of column TTYPE12 = 'MajAxPA ' / c TUNIT12 = 'deg ' / Unit of measure of column TNULL12 = '999. ' / Indicates data not provided in input TBCOL13 = xx / First character in column TFORM13 = 'F10.7 ' / Fortran 77 format of column TTYPE13 = 'MinAxis ' / TUNIT13 = 'arcsec ' / Unit of measure of column TNULL13 = '-9. ' / Indicates data not provided in input TBCOL14 = xx / First character in column TFORM14 = 'F9.4 ' / Fortran 77 format of column TTYPE14 = 'PM_RA ' / TUNIT14 = 'arcsec/(Julian annum)' / Unit of measure of column TNULL14 = '-999. ' / Indicates data not provided in input TBCOL15 = xx / First character in column TFORM15 = 'F9.4 ' / Fortran 77 format of column TTYPE15 = 'PM_Dec ' / TUNIT15 = 'arcsec/(Julian annum)' / Unit of measure of column TNULL15 = '-999. ' / Indicates data not provided in input TBCOL16 = xx / First character in column TFORM16 = 'F7.4 ' / Fortran 77 format of column TTYPE16 = 'Parallax' / TUNIT16 = 'arcsec ' / Unit of measure of column TNULL16 = '-9. ' / Indicates data not provided in input TBCOL17 = xx / First character in column TFORM17 = 'A20 ' / Fortran 77 format of column TTYPE17 = 'ObjClass' / TNULL17 = 'NULL ' / Indicates data not provides in input TBCOL18 = xx / First character in column TFORM18 = 'I6 ' / Fortran 77 format of column TTYPE18 = 'CatFilePK' / TNULL18 = ' -1 ' / Indicates data not provides in input END
This table is mentioned by the commentary in the catalog table. The SIMULATOR will provide a better user interface for iterative mask design if it saves state information about the catalog(s) whence the objects came. This FITS table is not part of the mask DesignFile transmitted to Keck; it is local to the observer.
XTENSION= 'TABLE ' / ASCII table extension BITPIX = 8 / number of bits per data pixel NAXIS = 2 / always 2 for a FITS table NAXIS1 = xxx / number of chars needed to describe members NAXIS2 = xxx / number of objects in the catalogs PCOUNT = 0 / required FITS extension keyword GCOUNT = 1 / required FITS extension keyword TFIELDS = 2 / Number of columns in the table ---------------------------------------------------------------- EXTNAME = 'Catalog_Files' / This table describes catalog source files EXTVER = 1 / Unique index of this Catalog table in file DATE = 'yyyy-mm-ddThh:mm:ss'/ Date of construction of catalog table ---------------------------------------------------------------- Here are the FITS table column descriptions TBCOL1 = 1 / First character in column TFORM1 = 'I6 ' / Fortran 77 format of column TTYPE1 = 'CatFilePKey' / Primary key for table of objects TBCOL2 = 7 / First character in column TFORM2 = 'A255 ' / Fortran 77 format of column TTYPE2 = 'FileName' / Name of catalog file ---------------------------------------------------------------- NPRIKEY = 1 / Number fields contributing to primary key PKTYP1 = 'CatFilePKey' / native TTYPE of primary key component 1 ---------------------------------------------------------------- The following information is for documentary purposes only. In normal operation this HDU is referenced by other HDUs, but it is not used to make references into any other HDU. The sole reason for the existence of this block of information is to assist a human to determine the purpose of this HDU if it should become orphaned. NFORHDU = 1 / Number of foreign HDUs referenced by this HDU HDLOC1 = 'path/to/catalog' / URI of file containing foreign HDU HDXTN1 = 'TABLE ' / FITS XTENSION type of foreign HDU HDNAM1 = 'DEIMOS_Input_Catalog'/FITS EXTNAME of foreign HDU HDVER1 = 1 / FITS EXTVER of foreign HDU HDPOS1 = / Ordinal position of foreign HDU in URI HDSUM1 = '0000000000000000' / checksum of foreign HDU HDDCS1 = ' 0' / checksum of foreign data NFORKEY = 0 / foreign key component references from this HDU ---------------------------------------------------------------- END
The output of SIMULATOR is a Mask Design.
XTENSION= 'TABLE ' / ASCII table extension BITPIX = 8 / number of bits per data pixel NAXIS = 2 / always 2 for a FITS table NAXIS1 = xxx / number of chars needed to describe members NAXIS2 = xxx / number of objects in the catalogs PCOUNT = 0 / required FITS extension keyword GCOUNT = 1 / required FITS extension keyword TFIELDS = 8 / Number of columns in the table ---------------------------------------------------------------- EXTNAME = 'DEIMOS_Mask_Design' / This table describes DEIMOS mask design EXTVER = 1 / Unique index of this Design table in FITS file AUTHOR = 'Rocket J. Squirrel' / Identity of person who designed mask DESPID = nnnn / DEIMOS-assigned identity of designer DESNAME = 'My Mask Design' / Observer's pet name for mask design DESTOOL = 'My Mask Design Tool'/ Name & version of tool used to make design DATE = 'yyyy-mm-ddThh:mm:ss'/ Date of construction of mask design COMMENT Various keywords specifying the telescope axis as designed RA_PNT = xxx.xxxxxxx / Right Ascension of Keck II axis [deg] DEC_PNT = xxx.xxxxxxx / Declination of Keck II axis [deg] RADECPNT= 'FKx ' / Reference frame for RA_PNT and DEC_PNT PA_PNT = xxxx.xxxxxxx / Position angle of DEIMOS mask on sky [deg] EQUINPNT= xxxxxx.xxxxxx / Equinox for RA_PNT and DEC_PNT [annum] MJD_PNT = 24xxxxx.xxxxxxxxx / needed if RADECPNT is FK4 [diem] LST_DES = xxx.xxxxxxx / designed Local Sideral Time for mask use [deg] DATEDES = 'yyyy-mm-ddThh:mm:ss'/ designed date for mask use ---------------------------------------------------------------- Here are the FITS table column descriptions TBCOL1 = 1 / First character in column TFORM1 = 'I6 ' / Fortran 77 format of column TTYPE1 = 'slitPKey' / TBCOL2 = xx / First character in column TFORM2 = 'F11.7 ' / Fortran 77 format of column TTYPE2 = 'slitRA ' / TUNIT2 = 'deg ' / Unit of measure of column TBCOL3 = xx / First character in column TFORM3 = 'F11.7 ' / Fortran 77 format of column TTYPE3 = 'slitDec ' / TUNIT3 = 'deg ' / Unit of measure of column TBCOL4 = xx / First character in column TFORM4 = 'A1 ' / Fortran 77 format of column TTYPE4 = 'slitTyp ' / Parallelogram, Alignment, Ellipse, Square TBCOL5 = xx / First character in column TFORM5 = 'F11.3 ' / Fortran 77 format of column TTYPE5 = 'slitLen ' / TUNIT5 = 'arcsec ' / Unit of measure of column TBCOL6 = xx / First character in column TFORM6 = 'F11.3 ' / Fortran 77 format of column TTYPE6 = 'slitWid ' / TUNIT6 = 'arcsec ' / Unit of measure of column TBCOL7 = xx / First character in column TFORM7 = 'F11.7 ' / Fortran 77 format of column TTYPE7 = 'slitLPA ' / sky pa of length direction of slit TUNIT7 = 'deg ' / Unit of measure of column TNULL7 = '999. ' / Indicates data not provided in input TBCOL8 = xx / First character in column TFORM8 = 'F11.7 ' / Fortran 77 format of column TTYPE8 = 'slitWPA ' / this may not be the best choice of name TUNIT8 = 'deg ' / Unit of measure of column TNULL8 = '999. ' / Indicates data not provided in input ---------------------------------------------------------------- NPRIKEY = 1 / Number fields contributing to primary key PKCOL1 = 1 / native TBCOL of primary key component 1 PKTYP1 = 'slitPKey' / native TTYPE of primary key component 1 ---------------------------------------------------------------- The design application may find useful to remember the source catalog which was used to create the design in this HDU. (I.e., it's a feature to save state such that the user/designer can more easily recreate a previous design session.) If so, the catalog can be stored in the manner described in this next bunch of FITS cards. NFORHDU = 1 / Number of foreign HDUs referenced by this HDU HDLOC1 = 'path/to/catalog' / URI of file containing foreign HDU HDXTN1 = 'TABLE ' / FITS XTENSION type of foreign HDU HDNAM1 = 'DEIMOS_Input_Catalog'/FITS EXTNAME of foreign HDU HDVER1 = 1 / FITS EXTVER of foreign HDU HDPOS1 = / Ordinal position of foreign HDU in URI HDSUM1 = '0000000000000000' / checksum of foreign HDU HDDCS1 = ' 0' / checksum of foreign data NFORKEY = 0 / foreign key component references from this HDU ---------------------------------------------------------------- This last chunk is not yet fully specified. The FITS header explicitly represents a single row of a RDB table containing the information common to all slitlets in a single mask design. Its primary key cannot be known in advance of RDB ingest, but upon outgest it can be stored in the FITS EXTVER keyword. This FITS table explicitly represents a selected subset of a RDB table containing the slitlet information on *all* mask designs. The RDB table will have an additional field which represents the uniqueID of the particular mask design. Inclusion of the foreign key formalism here permits us to point to the values of several keywords which do not belong in this FITS header but which do belong in the RDB table row that will be created from the header. In this case the next block of lines could equally well be communicated simply by redundantly filling in the values from the catalog FITS header. NQRYKEY = 3 / Number of keywords with queryable values QKHDU1 = 1 / refers to index counted by NFORHDU QKCOL1 = -1 / TBCOL of foreign key component in native HDU QKTYP1 = 'CatAuth ' / TTYPE of foreign key component in native HDU QKFOL1 = / TBCOL of primary key component in foreign HDU QKFYP1 = 'AUTHOR ' / TTYPE of primary key component in foreign HDU QKHDU2 = 1 / refers to index counted by NFORHDU QKCOL2 = -1 / TBCOL of foreign key component in native HDU QKTYP2 = 'CatName ' / TTYPE of foreign key component in native HDU QKFOL2 = / TBCOL of primary key component in foreign HDU QKFYP2 = 'CATNAME ' / TTYPE of primary key component in foreign HDU QKHDU3 = 1 / refers to index counted by NFORHDU QKCOL3 = -1 / TBCOL of foreign key component in native HDU QKTYP3 = 'CatDate ' / TTYPE of foreign key component in native HDU QKFOL3 = / TBCOL of primary key component in foreign HDU QKFYP3 = 'CATDATE ' / TTYPE of primary key component in foreign HDU ---------------------------------------------------------------- END
The output of MAPMASK is a Mask Blueprint.
XTENSION= 'TABLE ' / ASCII table extension BITPIX = 8 / number of bits per data pixel NAXIS = 2 / always 2 for a FITS table NAXIS1 = xxx / number of chars needed to describe members NAXIS2 = xxx / number of objects in the catalogs PCOUNT = 0 / required FITS extension keyword GCOUNT = 1 / required FITS extension keyword TFIELDS = 8 / Number of columns in the table ---------------------------------------------------------------- EXTNAME = 'DEIMOS_Mask_Blueprint' / This table describes DEIMOS mask blueprint EXTVER = 1 / Unique index of this Blueprint table in file AUTHOR = 'Rocket J. Squirrel' / Identity of person who converted design to blue BLUPID = nnnn / DEIMOS-assigned identity of author/mask owner BLUNAME = 'My Mask Blueprint' / Observer's pet name for mask blueprint BLUTOOL = 'My Blueprint Tool' / Name & version of design->blueprint tool DATE = 'yyyy-mm-ddThh:mm:ss'/ Date of construction of mask blueprint LST_USE = xxx.xxxxxxx / intended Local Sideral Time for mask use [deg] DATEUSE = 'yyyy-mm-ddThh:mm:ss'/ intended date for mask use TELESCOP= 'Keck II ' / was used to look up geod & atmo info for refrac REFRALG = 'SLALIB ' / atmospheric refraction algorithm ATMTEMPC= xxx.x / air temperature used for refraction [deg C] ATMPRES = xxxx.x / air pressure used for refraction [mbar] ATMHUMID= 0.xxx / relative humidity used for refraction ATMTTLAP= 0.0065 / troposph. adiabatic temp. lapse rate [K/m] REFWAVE = 0.xxxxxxxxxx / wavelength used for refraction [m] DISTMETH= 'name of telescope distortion methodology' ---------------------------------------------------------------- Here are the FITS table column descriptions TBCOL1 = 1 / First character in column TFORM1 = 'I6 ' / Fortran 77 format of column TTYPE1 = 'bSlitPK ' / TBCOL2 = xx / First character in column TFORM2 = 'I6 ' / Fortran 77 format of column TTYPE2 = 'dSlitPK ' / TBCOL3 = xx / First character in column TFORM3 = 'A1 ' / Fortran 77 format of column TTYPE3 = 'slitTyp ' / regurgitated from Mask Design TBCOL4 = xx / First character in column TFORM4 = 'F9.6 ' / Fortran 77 format of column TTYPE4 = 'slitx1 ' / TUNIT4 = 'm ' / Unit of measure of column TBCOL5 = xx / First character in column TFORM5 = 'F9.6 ' / Fortran 77 format of column TTYPE5 = 'slity1 ' / TUNIT5 = 'm ' / Unit of measure of column TBCOL6 = xx / First character in column TFORM6 = 'F9.6 ' / Fortran 77 format of column TTYPE6 = 'slitx2 ' / TUNIT6 = 'm ' / Unit of measure of column TBCOL7 = xx / First character in column TFORM7 = 'F9.6 ' / Fortran 77 format of column TTYPE7 = 'slity2 ' / TUNIT7 = 'm ' / Unit of measure of column TBCOL8 = xx / First character in column TFORM8 = 'F9.6 ' / Fortran 77 format of column TTYPE8 = 'slitx3 ' / TUNIT8 = 'm ' / Unit of measure of column TBCOL9 = xx / First character in column TFORM9 = 'F9.6 ' / Fortran 77 format of column TTYPE9 = 'slity3 ' / TUNIT9 = 'm ' / Unit of measure of column TBCOL10 = xx / First character in column TFORM10 = 'F9.6 ' / Fortran 77 format of column TTYPE10 = 'slitx4 ' / TUNIT10 = 'm ' / Unit of measure of column TBCOL11 = xx / First character in column TFORM11 = 'F9.6 ' / Fortran 77 format of column TTYPE11 = 'slity4 ' / TUNIT11 = 'm ' / Unit of measure of column ---------------------------------------------------------------- NPRIKEY = 1 / Number fields contributing to primary key PKCOL1 = 1 / native TBCOL of primary key component 1 PKTYP1 = 'bSlitPK ' / native TTYPE of primary key component 1 ---------------------------------------------------------------- The following information permits references to the mask design NFORHDU = 1 / Number of foreign HDUs referenced by this HDU HDLOC1 = 'path/to/mask_design'/ URI of file containing foreign HDU HDXTN1 = 'TABLE ' / FITS XTENSION type of foreign HDU HDNAM1 = 'DEIMOS_Mask_Design' / FITS EXTNAME of foreign HDU HDVER1 = 1 / FITS EXTVER of foreign HDU HDPOS1 = / Ordinal position of foreign HDU in URI HDSUM1 = '0000000000000000' / checksum of foreign HDU HDDCS1 = ' 0' / checksum of foreign data NFORKEY = 1 / foreign key component references from this HDU FKHDU1 = 1 / refers to index counted by NFORHDU FKCOL1 = / TBCOL of foreign key component in native HDU FKTYP1 = 'dSlitPK ' / TTYPE of foreign key component in native HDU FKFOL1 = / TBCOL of primary key component in foreign HDU FKFYP1 = 'dSlitPK ' / TTYPE of primary key component in foreign HDU ---------------------------------------------------------------- END
The correspondence between objects and slitlets is not one-to-one, so a separate table is needed to map between the catalog and design. There may be more than one object within a given slitlet. (For the purposes of this database, regions or sub-components of an object which fall into more than one slitlet are deemed to be separately named objects.)
XTENSION= 'TABLE ' / ASCII table extension BITPIX = 8 / number of bits per data pixel NAXIS = 2 / always 2 for a FITS table NAXIS1 = xxx / number of chars needed to describe members NAXIS2 = xxx / number of objects in the catalogs PCOUNT = 0 / required FITS extension keyword GCOUNT = 1 / required FITS extension keyword TFIELDS = 2 / Number of columns in the table ---------------------------------------------------------------- EXTNAME = 'DEIMOS_Slit_Object_Map' / This table identifies objects in slits EXTVER = 1 / Unique index of this Map table in file ---------------------------------------------------------------- Here are the FITS table column descriptions TBCOL1 = 1 / First character in column TFORM1 = 'I6 ' / Fortran 77 format of column TTYPE1 = 'dSlitPK ' / TBCOL2 = xx / First character in column TFORM2 = 'I6 ' / Fortran 77 format of column TTYPE2 = 'ObjPKey ' / Primary key for table of objects ---------------------------------------------------------------- It is not clear that we need or want a primary key in here because every row should be unique. NPRIKEY = 2 / Number fields contributing to primary key PKCOL1 = 1 / native TBCOL of primary key component 1 PKTYP1 = 'slitPKey' / native TTYPE of primary key component 1 PKCOL2 = 2 / native TBCOL of primary key component 1 PKTYP2 = 'ObjPKey ' / native TTYPE of primary key component 1 ---------------------------------------------------------------- We must specify foreign keys into two other HDUs NFORHDU = 2 / Number of foreign HDUs referenced by this HDU The following information permits references to the catalog HDLOC1 = 'path/to/mask/design'/ URI of file containing foreign HDU HDXTN1 = 'TABLE ' / FITS XTENSION type of foreign HDU HDNAM1 = 'DEIMOS_Mask_Design' / FITS EXTNAME of foreign HDU HDVER1 = 1 / FITS EXTVER of foreign HDU HDPOS1 = / Ordinal position of foreign HDU in URI HDSUM1 = '0000000000000000' / checksum of foreign HDU HDDCS1 = ' 0' / checksum of foreign data The following information permits references to the catalog HDLOC2 = 'path/to/catalog' / URI of file containing foreign HDU HDXTN2 = 'TABLE ' / FITS XTENSION type of foreign HDU HDNAM2 = 'DEIMOS_Input_Catalog'/FITS EXTNAME of foreign HDU HDVER2 = 1 / FITS EXTVER of foreign HDU HDPOS2 = / Ordinal position of foreign HDU in URI HDSUM2 = '0000000000000000' / checksum of foreign HDU HDDCS2 = ' 0' / checksum of foreign data NFORKEY = 2 / foreign key component references from this HDU FKHDU1 = 1 / refers to index counted by NFORHDU FKCOL1 = / TBCOL of foreign key component in native HDU FKTYP1 = 'dSlitPK ' / TTYPE of foreign key component in native HDU FKFOL1 = / TBCOL of primary key component in foreign HDU FKFYP1 = 'dSlitPK ' / TTYPE of primary key component in foreign HDU FKHDU2 = 2 / refers to index counted by NFORHDU FKCOL2 = / TBCOL of foreign key component in native HDU FKTYP2 = 'ObjPKey ' / TTYPE of foreign key component in native HDU FKFOL2 = / TBCOL of primary key component in foreign HDU FKFYP2 = 'ObjPKey ' / TTYPE of primary key component in foreign HDU ---------------------------------------------------------------- END
We have constructed several simulated DEIMOS images. The images have been successfully viewed using existing image display clients.
File transfers of 138Mbyte FITS files over the 100Mb/s ethernet have been clocked at 45 seconds, or about 3Mbytes/s.
We are awaiting the official releaes of IRAF 2.11 which will permit us to perform more timing tests. Of particular interest will be the procesor speed with which the Dec alpa with 1Gbyte of RAM runs typical pipeline reduction steps such as those in IRAF ccdproc.
We have received and tested our first set of 2nd generation controller boards, and the results of these detector!CCD controller CCD!controller, tests tests!CCD controller tests were reported at the DEIMOS CCD review held May 20, 1997. Copies of the report from that review are available, and selected chapters (3: CCD System Overview, 5: Science CCD Controller, and 6: Data Capture) of that report are available via the WWW at the following URL: http://www.ucolick.org/~kibrick.
Our existing engineering software tools for operating the SDSU controllers have been updated and tested with the second-generation SDSU controllers boards. We can now successfully program and generate valid CCD clocking waveforms and bias voltages using the second-generation boards, and have used a high-speed oscilloscope to verify the proper operation of the video processing signal chain. Our VME crate (currently SunOS-based) is reliably communicating with the second-generation SDSU timing board and utility board.
We are sufficiently confident with this new hardware and with our ability to generate DSP software for it that we have sought (and obtained) from the DEIMOS CCD Review Board permission to place a large order for second-generation SDSU controller boards. That purchase order has cleared the campus purchasing office, and was issued on June 5. Delivery of second-generation SDSU boards should begin in July and be completed by the end of September.
This section covers the tests of the motor controllers, their firmware, the terminal servers connected to the motor controllers, and the dispatch software interface communicating with the motor controllers via the terminal servers. It describes the extent of the platform independence of the software components, the level of completeness of the software, and the functional proof required for the system designs. It does not cover all the configurations of hardware and software used in the tests.
The motor controller and terminal server tests were conducted in Santa Cruz and at Mt. Hamilton using Lick Prime Focus Camera (PFCAM) and ESI stages. Five stages were available for the tests. The two linear stages and two rotary filter wheels from PFCAM were used separately and together for the majority of the testing. An ESI filter wheel was also tested separately.
A variety of Galil DMC-1500 series controllers were used to control the stages during testing. They included a four axis controller with an auxillary I/O module added (DMC-1540-72), a five axis controller (DMC-1550), an eight axis controller with the auxillary I/O module added (DMC-1580-72), and an eight axis controller without the auxillary I/O module (DMC-1580).
Communication with the motor controllers was via two serial ports on the motor controllers. The controller serial ports were connected to I/O ports on a Lantronix terminal server. RTS/CTS was used for the handshaking protocol. In normal operations the main controller serial port accepts commands and the second auxillary serial port is used exclusively as a diagnostics message port. Serial communications tests of the terminal server used both the main serial port and the auxillary serial ports of the motor controllers extensively. Initial tests of the Lantronix ETS8/UF terminal servers revealed flaws in their communications protocol and scheduling algorithms. Lantronix sent an ETS8P beta unit to us for testing and evaluation. The ETS8P beta unit was used in all of the tests described in this document, unless otherwise noted.
The tests were performed with the terminal server connected to to either a private ethernet in Santa Cruz or to the Mt Hamilton network.
The software communicating to the motor controller via the terminal server ran on a variety of SPARC platforms running either SunOS or Solaris.
During normal control of the stages, the motor controller was running two tasks continuously. One, called UHAUL, monitors the manual control panel. The other, called BEKINS, handles controlling the stages when requested, either by UHAUL or by external commands sent to the motor controller's main serial port. During tests of the Lantronix terminal server, special programs were loaded onto the motor controllers to flood the main and auxillary serial ports with data.
A prototype dispatch process was connected to the motor controller via the terminal server ports to test stage control from De Clarke's prototype dashboard GUI and the existing "show" and "modify" KTL shell commands.
A serial I/O test program was connected to the motor controller via the terminal server ports to test the terminal server handshaking, bandwidth and scheduling.
During tests in Santa Cruz, the dispatch process communicated to the dashboard and KTL shell commands via messages sent to a traffic process running on a local SPARC10 running SunOs. During tests on Mt. Hamiltom with PFCAM, the dispatch process communicated to dashboard and KTL shell commands via messages sent to a traffic running on the same machine in Santa Cruz, then via traffic running on a similar machine on at Mt. Hamilton.
The user interface processes were run from a SPARC5 running SunOS in Santa Cruz and the SPARC10 on Mt. Hamilton.
The Lantronix ETS8P beta version terminal server was tested with the main and auxillary serial ports of four Galil DMC-1500 series controllers connected to the eight serial ports on the terminal server. The baud rate for each port was set to 19200, with RTS/CTS handshaking enabled. A simple test program pumped a test pattern to the controllers and read the test pattern echo back on the main serial port and read the output of the test pattern on the auxillary serial port. The test ran for 48 hours. The average simultaneous throughput per port was 1400 characters per second compared to an expected maximum of 2000 characters per second. Counters in the terminal server indicated RTS/CTS handshaking was working without any errors. No data errors were seen in the test patterns returned by the controllers.
The terminal server also spent two nights riding on the prime focus ring of the Shane Telescope at Mt. Hamilton handling communication to the PFCAM motor controller. No problems were observed with the terminal server during use on the telescope.
We have negotiated an agreement with Lantronix to exchange the model ETS8/UF terminal servers for credit toward the purchase of the improved ETS8P devices. This exchange should be completed by the end of June.
The goal of the motor controller firmware was to provide tasks that handled command requests for homing and moving stages from either a manual control box connected to the digital input ports of the motor controller, or external requests arriving in Galil command language on the controller's main serial port.
The UHAUL and BEKINS tasks were developed by Jim Burrous to satisfy these objectives. The UHAUL task handles the signals from the manual control box. It sets up request information for the BEKINS task and BEKINS handles the request. Incoming requests on the serial port set up the request information similar to UHAUL and BEKINS handles it just like the manual move requests from UHAUL.
Jim performed the validity tests of the firmware using the PFCAM instrument. All of the movement options available from the manual control box were exercised extensively during the construction and testing of the PFCAM instrument. Each stage was homed, jogged at fast and slow speeds, moved to ordinal positions defined in the position data arrays on the controller and stopped during motion via the stop button. The same tests were performed via the serial interface to the controller by typing the commands required by the controller to set up home/move/stop commands. The raw positioning movement mode needed by dispatch was tested via the serial port.
Linear stages with a single encoder were tested in raw position and jog mode out to the secondary limit switches at each end of travel. The firmware was tested for correct handling of all limit switch conditions. Both single and dual encoder rotary stages have been controlled successfully.
Dispatch's MUSIC message handling interface was tested with a basic set of PFCAM stage keywords. The message handling routines used by the PFCAM keyword library and the PFCAM dispatch process are identical to those used for DEIMOS. Only the xxxxxRAW, motor encoder position keywords, were available. The xxxxxRAW keywords provided all necessary services to test reading and writing values to dispatch and handling of dispatch value change broadcasts. The show, modify, and xshow shell commands and De Clarke's dashboard user interface provided the access to the keyword library.
A minor problem was found in the dispatch service loop. It responded too quickly to show keyword commands with more than one keyword in the command line. The show command did not have time to send a request for the next keyword on the command line before dispatch went off to read status information from the motor controller. This resulted in a half second wait before the display of each keyword in the show command line. This has been fixed by adding a small wait inside the dispatch service loop.
The only major change to the dispatch was in the dispatch service routines handling stage I/O requests. The original xxxxxRAW routines were divided into a configuration device type used to generate the xxxxxRAW device data and the device data for the other types of stage keywords, i.e. xxxxxTRG, xxxxxORD, xxxxxNAM, etc. The new device code works fine for reading xxxxxRAW and xxxxxTRG keywords. It looks like it performs everything required to perform xxxxxRAW writes, but it hasn't been tested with a stage for verification.
After discovering problems with the ETS8/UF Lantronix terminal servers received for use in DEIMOS, a new terminal server model, the ETS8P, has been tested and found to perform acceptably.
The major components of the motor controller firmware, dispatch interface and KTL keyword library has been tested successfully. The tests included running the PFCAM instrument during an engineering run on the Shane Telescope at Mt. Hamilton. The dispatch process has been run from both SunOS and Solaris machines, including connecting a remotely run dispatch task with the terminal server via the network connections between Santa Cruz and Mt. Hamilton.
