Slide 2: DEIMOS Mechanical Overview My primary project at this time is a large new multi-object spectrograph called DEIMOS. As you can see this is a fairly complex electromechanical assembly with lots of components, many of which are moved by solenoids or servo motors, or need to be monitored via telemetry.
At Keck, instruments and telescopes are controlled by software using the Keck Tasking Library. This library imposes a keyword/value metaphor for realtime control.
Slide 3: show/modify/waitfor commands You "show" or read keywords to see system status, and "modify" or write them to send commands. An instrument like DEIMOS might require upwards of 400 keywords: read-only, write-only, and read-write. Mr William Lupton at Keck wrote a Tcl extension for the KTL API library, so that Tcl can be used to show, modify, and monitor KTL keywords. The "dashboard" application is baseD on this "Ktcl" Tcl extension.
Before we really get started I should note that less than 20 lines of code in the GUI source are actually KTL specific. Any realtime API library using a keyword/value metaphor, for which a Tcl extension can be written, could easily be substituted for KTL.
Traditionally we build our instruments with handcrafted code and
documentation, in which definitions of these keywords keep recurring in
Slide 4: FIORD table source This code, for example, is clearly boilerplate, and varies depending on the attributes of keywords. For DEIMOS I ventured to treat the keyword dictionary as a central knowledge base, stored as a relational database. From this database we generate documentation, and even some sections of boilerplate code such as this.
Among the body of code that we have traditionally handcrafted for
each instrument are the various GUI required for testing, diagnosis,
Slide 5: xhires colour screen dump This interface for the HIRES spectrograph is one of many handcrafted interfaces written in C and using various X11 libraries. All any KTL UI really has to do is read and write keyword values. But this UI took several programmer months to write, and has resisted evolution since its deployment because of the difficulty and cost of alterations.
With the keyword knowledge base in hand, I wished to try a different approach for the DEIMOS GUI: to get away from handcrafting.
Slide 6: simple dashboard with a couple of meters This GUI, nicknamed "dashboard" for obvious reasons, is really just a more user-friendly version of show and modify commands. Here we see a few meters associated with KTL keywords.
I wanted to make a GUI which would derive from the knowledge base a complete dictionary of instrument keywords. The designer or user can select from a limited list of graphical metaphors for each keyword. Basic knowledge of
The application is both a GUI BUILDER and a GUI. It can be live during development (meters start working as soon as they are created). So it serves as an ad hoc test UI for engineers; but it can also be frozen, packaged and delivered to end users.
It has access to the keyword semantics, so it's also a documentary interface. Context sensitive help is built in.
Slide 7: simple dashboard with a couple more meters Here I added a couple more meters. I pick a graphical metaphor, enter a keyword name, and Make Meter. I can then drag the meters around wherever I want them; as you can see I've been changing their colours too. I edit their graphical attributes with an interactive pop up editor, which we'll see later.
Dashboard is about 12K lines of code, and runs against any KTL keyword library (a shareable object library). It can save layout and keyword information as ASCII files. This same 12K lines of code can construct a dashboard for any KTL instrument.
Of course a few meters on a dashboard is not a GUI. A real GUI needs annotation, decoration, overall design -- and some ability to reflect conditions and alarms visually. Things should appear, light up or move around to get the user's attention when needed. It should have a colour scheme, look and feel that reflect the designer's ideas and the user's needs.
Slide 8: Dashboard condition editor A fairly simple mechanism permits the designer to establish conditional attribute sets for visible objects on the dashboard. The conditions are written as simple Boolean expressions using keyword names as terms; the designer does not need to worry about the actual infrastructure acquiring the keyword values. Here we see the Condition Editor being used to establish conditional attributes for a graphical object. Every object has a 'Normal' state, but can have an arbitrary number of other states as well. Here I'm deciding that this object should turn red instead of green, and its text should change to 'halted' instead of 'running', when the value of the IROTHALT keyword is as shown in the Boolean expression.
Slide 9: HIRES interface, with photon arrows The condition handling enables the UI to be semi-animated; in this slide, the horizontal arrows indicate photons travelling through the instrument. If any cover on the light path is closed, the photon arrows after that cover will disappear. This feature is implemented quite simply, as discussed in the paper, by a series of conditional expressions. I should note here that the HIRES instrument was used to test Dashboard, and that the actual HIRES spectograph has been controlled from this interface; the interface took about 3 days to construct.
Slide 10: DEIMOS interface, at rest
Condition handling also enables the designer to flag such states
as "user has changed target value". In this slide the UI is
"at rest", but in
Slide 11: DEIMOS interface, changed this one the user has changed a couple of Desired values so that they no longer match Actual values. In response the UI has immediately changed the colour of the relevant decoration. You can easily imagine how the user hits the Go or Commit button, and these two stages now changed to a colour (maybe orange) indicating that they are In Motion. When they complete their movement, Desired and Actual will match once more and the highlighting will vanish, leaving the GUI once more green and peaceful.
We want the user to be able to tell at a glance, over their shoulder, from across the room, at 3 AM, at 14,000 feet, whether the instrument is or is not ready to take the next exposure. Creative colour scheme manipulation by means of conditional expression evaluation gives us great flexibility in communicating with the user. The same mechanism (evaluating simple Boolean expressions) also enables the UI to deliver pop-up alarms and to execute arbitrary Tcl code in response to fairly complex instrument states. We can send mail, write logs, shut down systems, etc. as easily as we can make green widgets yellow.
Slide 12: Summary There are many more features in this application than I have time to discuss here, so I would like to move on to the moral lessons. We are all used to Tcl/Tk's virtues: rapid development and deployment, portability, etc. so that's not too exciting. The more interesting lessons I draw from this project are: