Architecture

Users of the microscope have two different programs they can use to control the microscope. In most cases they will use an IDL graphical user interface (GUI) program called sm_gui.pro. For repeated, pre-programmed operations, they may instead use a C++ program sm_script.pro to drive the microscope.

What happens ``under the hood'' is a bit more involved, as is shown in Fig. 2.1. The users' computer is referred to as the client computer; on it, the programs sm_gui.pro or sm_script.pro call routines in an IDL library sm_client.pro to generate TCP/IP socket calls to a server computer (they also call some helper routines for file I/O and so on in sm_image.pro).

The server computer is a PC running Windows 2000. It runs a C++ server daemon program called sm_server.cpp which uses a C++ class sm_services.cpp to receive commands from the client, and send responses back. The program sm_server.cpp then employs a class sm_scan.cpp to handle all communication with microscope hardware. Below that level, each particular device has its own C++ class as shown in Fig. 2.1 and as described below. This modularity of the software has made it possible for various participants in the effort to each concentrate on a separate module for testing and debugging.

Finally, just as the client has a program sm_script.pro for executing commands (such as those specified in a text file), the server has a functionally equivalent program sm_script.cpp. It is anticipated that the server program sm_script.cpp will be used primarily for debugging efforts; users will likely want to do all microscope control from the client computer.

Figure 2.1: Relationship between software modules on the server computer.
\includegraphics[width=6.in]{images/software_modules}

Holger Fleckenstein 2008-07-08