Our notion of the way to configure DEIMOS (i.e., correctly loading removable elements and updating the dynamic configuration database) has evolved considerably since PDR and CDR. As of CDR we were still thinking of a dashboard-like GUI out on the platform, probably on a laptop, which would offer menus for moving the instrument to preset unload positions. We imagined that the user would be scanning certain elements just prior to loading them (filters, gratings).
Since that time, several significant changes have occurred. First, safety interlocks have been installed which prevent any GUI (or any keyword commands) from driving the filter wheel, the grating sliders, or the slitmask mechanisms if their respective access hatches are open. Second, CARA is planning to add a safety interlock which will inhibit any GUI (or any keyword command) from rotating DEIMOS if there is any person on the Nasmyth platform. These safety interlocks obviously limit the usefulness of a laptop computer on the platform.
We have come up with what we think is a simpler interface, one easier to use at 14,000 ft and in extreme cold. Possibly the most important new discovery we have made is that the barcode labels are scannable when the elements are loaded, i.e. they can be scanned in place.
The dremel daemon listens for two types of event. It monitors and logs any opening of the access hatches for filters, gratings, or slitmasks. Also, it listens for any "bar code scanned" event from the hand-held barcode scanner.
Bar code scan events are of two kinds: "magic" codes which cause dremel to take an action (listed below), or ordinary barcodes (alphanumeric sequences that are not magic).
The scanning of a barcode causes dremel to evaluate that barcode. If it is not magic, dremel attempts to match the barcode in the RDBMS tables of removable elements. If it cannot match the code, an error is logged. If the code is valid for a removable element, dremel attempts to determine whether the hatch is open for access to that element and whether the relevant stage is in an unload position. If so, it accepts the mapping of position N to element E, and "remembers" the name of that element for use in confio.
Magic barcodes include:(Card 1):
- auto-scan entire slitmask cassette now
- commit configuration now
- assign temporary label "User_N" to current element
- read back the list of today's configuration changes
- read back the complete instrument configuration
ASCII names of the base complement of glass elements (in case of damaged labels on the element holders)
(The "read back to me" options rely on a fairly capable text-to-speech package, which we think we have obtained and will be testing over the next couple of months).
Interactive feedback is provided in the form of audio samples and/or text2speech played back over the headphones. The headphone rig also works as a "digital walkie talkie" to any machine equipped with audio-over-tcp software and able to get IP access to roto.
When "dremel" is instructed to commit its cached data, it generates an input file for confio and runs confio much as the getconf/putconf scripts do.
Scanning of the inserted elements can take place during loading, one element at a time; or loading and scanning can be separated into two activities which take place sequentially. In practise, is is likely that users will want to scan gratings one at a time, after insertion, because of the lengthy traverse time of the grating transport stage. Filters might be scanned all at once because of the easy and quick manual filter-wheel control. The dremel code should be able to handle either case.
This is what the checklist or HOWTO would look like.
We should note that the "Auto Scan Slit Masks" task should be asynchronous; it should be able to run in the background while the instrument tech or scientist completes other configuration changes. Thus, the really efficient way to reconfigure DEIMOS would be this: first install the slitmasks and tell the slitmask system to auto-scan its contents. While it is busy doing this, rotate to the filter/grating access position(s) and get those elements installed and scanned. When done, and when the slitmask auto-scan is done, scan the "COMMIT" special barcode.
If barcode labels are damaged they may become unreadable. If a label will not scan (the scan gun will not beep, and there will be no audio confirmation through the headphones either), and it appears damaged, scan the preprinted label for the name of that element instead, if one is available. (See final item in list of "magic" barcodes, above; but it's not clear whether this is really a good idea, as it might encourage people to scan these labels, assuming that they know which element is in the current holder, rather than scanning the real barcode label on the element holder itself).
In this case, the magic barcode would be the short (menu) name of the element, and it would be an "action" barcode for dremel. The action would be to look up this name in the database, ensure that it is recognized, and gather any additional data needed for config files; this name would then be associated with the current Unload position, as if it had been looked up via a bar code.
If this element has arrived recently from outside, has not yet been documented in the database and/or has no label, scan one of the "User" labels on the preprinted sheet. This will associate the name "User_N" with this device until the next configuration. It should also send mail to someone, somewhere, requesting that they get some info about this element and update the database.
Benefits of new scheme:
The "inconfig" utility shipped with ESI was not a big hit. Its screens were complex and it required manual typing of removable element names (easy to make a typo). The "confio" utility which followed it was simpler in one sense (editing an ascii file was the means of changing configuration). But again the user has to type element names by hand. This is not something one really wants to do with cold mittened fingers out in the dome; yet it's artificial and inefficient to separate the physical and virtual configuration activities by a great distance.
By using a simple one-trigger bar gun scanner (which can be operated even in mittens) and using audio feedback we bring the virtual and physical configuration activities together, but without displays and keyboards in the hostile platform environment. The user never types any text, so typos are eliminated; nor is there any remembering involved -- elements are scanned in situ, after being inserted in positions which dremel can "sense". No one has to carry handwritten scraps of paper back to the control room to be transcribed into tools like inconfig, or into a text editor; they may print out prompt-sheets or checklists to aid in picking and installing the elements, but the 'data entry' portion of the task is eliminated.
The headphones should block out the base level of background noise in the dome, allowing audio cues to be heard clearly. Using audio cues leaves the tech/IS's with freedom of motion and gaze. The bar gun takes only one hand to operate. Our expectation is that all these features will make it more intuitive and simpler for the person stuffing parts into the instrument also to update the software configuration, with as little overhead, mode-switching, expert intervention, and opportunity for error as possible.
This new configuration scheme is currently at Proof of Concept level, and we expect to complete it during commissioning. A version of dremel has been run which does correctly interpret barcode scan events; we have acquired and built a text2speech suite called "Festival"; we have verified the ability to transmit audio over tcp between roto and other computers; we have data in the Sybase database today for the base set of glass elements. We feel there are no technical gotchas likely to prevent successful implementation. However, we would like very much to hear the opinions of CARA personnel on this scheme, before it gets closer to a final version.
