University of Illinois at Urbana-Champaign

WWL: EM Control Library

This document is a preliminary draft specification and description of the EM Control Library and its role in the World Wide Laboratory project. It is intended as a working document and we invite input from anyone interested. Please write to us with any comments, specifically we would like to hear about the following:

  • Can all of these functions be reasonably implemented on most instruments.
  • Suggestions for new functions
  • General library design issues
  • Comments on terminology, descriptions, wording
  • Anything else

Please send all comments to wwltem@mail.itg.uiuc.edu

This library is part of larger organization of software for developing applications that control a TEM. The organization is a traditional layered approach to software development. The software is built on layers, where each layer is only permitted to interact with the layers below it. Generally speaking the layers are divided as follows (note layer 1 can only be accessed by layer 2). Also note this structure will be modified somewhat in the future as it is unclear where the automation library will actually reside, and its also unclear that layer 1 can not be accessed by anything other than layer 2.

Layer 1. EM Device Dependent Library

This library is a set of functions for controlling an instrument. This layer may be provided by the instrument manufacturer and contains functions that can be very specific to an individual instrument. In our case Philips provides a library called RCM on a PC. We recreated this library on the Unix platform using their documentation of the serial protocol used to control the instrument. In principle it is possible to implement layer 2 directly without a specific device dependent control library. However we found that having a separate library specifically tuned to the instrument being controlled to be very useful in debugging the software and developing small device specific applications.

Layer 2. EM Control Library (EMC Library)

This is described by this document. Basically we try to implement a hardware abstraction layer for TEM applications. We define a set of functions which must be implemented by an EM Control Library. The EM Control Library is free to implement these functions in any way that it chooses. In our case each EMC Library function is implemented using one or more calls to our layer 1 device dependent instrument control library.

This allows an application which uses the EMC Library to be relinked to a different EMC Library in order to support a new instrument.

Layer 3. EM Automation Library

Once at this layer we are completely abstracted from the underlying instrument. In theory everything from here on up should work on any instrument provided that the EMC Library (layer 2) is sufficient to cover all instrument operation.

The EM Automation Library consists of higher level functions such ones to perform autofocus. In the future this layer may become a part of layer 2 depending on whether the automation functions will require access to layer one functions. So far they do not, but this may change.

Layer 4. EM Command Line Applications

At this layer we have written several command line applications which allow basic access to the instrument. For instance applications called "emget" and "emset" have been written which provide an enduser interface to the emGetXXX/emSetXXX functions in the EMC Library and are currently being used in a variety of shell scripts.

Layer 5. EM Scripting Extension

One of the goals of this project is to make it easy for non-programmers to develop EM applications and tools. The proven way to make this possible is the use of macro and scripting languages. To this end layer 5 is implemented as an extension to the Tcl/Tk scripting language. This makes it easy to control the EM from a simple environment.

Layer 6. EM Graphical User Interface

Using layers 2-5 it is then possible to create a full-blown application with a sophisticated graphical user interface. Either using the graphical interface provided by the Tcl/Tk scripting environment, or through a native application.

PREVIOUS Page 2 of 54 NEXT