Extend instrumentation base classes to allow for other instrument types

[cmeyer]

In order to facilitate microscope acquisition and control applications that function independently of specific microscope vendors, the instrumentation kit should include instrument controllers. Vendor specific controllers can be derived or implement functions from the general controllers.

The STEMController base class serves as the generic STEM controller with Nion-specific and simulator-specific implementations distributed separately but adhering to the interface defined in STEMController.

We could add base/abstract controllers for TEM and SEM microscopes.

How much of the functionality in STEMController is applicable to either TEM or SEM base classes?

Should the controllers be structured as a class hierarchy (subclasses inherit functionality) or as class protocols (implementations can pick and choose what functionality to implement)?

What are the fundamental API's for each instrument type or instrument protocol?

[w-markus]

I'll try to answer the last question for our Zeiss instruments (SEMs, FIB, TEM).

We can access the instruments in a two step way. We have home brewed wrapper library that can make use of the vendor provided API in a very nice and clean way. We can get/set values but also notifications/errors can be catched. For more details I have to refer to Victor and Sören, who actually did the programming. The library provides a Python interface.

The second step is a webserver (Python) which exposes a RESTful-API to possible clients and communicates with the instrument via the library mentioned above. This webserver based solution will allow us to run instrument software, e.g. detector software, nionswift, ..., on another computer via the network.

As far as I understood, what is more or less missing is a kind of dictionary for querying the webserver specific properties of the instrument (e.g. get magnification, or setting, or issuing commands). But this seems to be some routine work to do. However, if I understood correctly this is than more towards class protocols, isn't it?

[cmeyer]

Thanks for the feedback.

However, before considering the specific implementation details for a particular microscope, an important question to answer is:

What characteristics define a STEM vs TEM vs SEM vs FIB?

Once that question is answered, we might also ask if there are sets of characteristics common to multiple (or all) microscopes?

As an example, I assume that all STEM microscopes have an associated scan system with a probe position that is active when the system is not actively scanning. Also, since scanning is fundamental to STEM, we can also define a hierarchy of scan types: a wide field of view context scan, and then sub scans or line scans. These STEM characteristics are common to all STEM microscopes, but they are independent of how we communicate with a specific microscope. They define an abstract representation of a STEM microscope.

Also, some characteristics may be common to multiple types of microscopes. A scan context, sub scan and line scan are applicable to an SEM -- but probably not to a TEM (?).

We might begin by defining some base classes within the instrumentation-kit: TEMController and SEMController (and perhaps FIBController?). Then anyone implementing specific microscope controllers (e.g., MyMicroscopeTEMController) can derive from those classes. However, I'd like to get feedback if this seems like a good place to start.

Eventually, we can re-evaluate to see if there are common characteristics between the microscopes, such as 'support scan, sub scan, and line scan' or 'supports eels' or 'supports energy filtered TEM', etc. To be clear, I'm not sure what those common characteristics are -- that's the point of discussion in this issue. But I'm almost certain that after implementing specific microscope types, there will be some common characteristics.

[cmeyer]

Another important feature of the base instrument controller classes is to record metadata about the microscope with acquired data. For instance, for the STEMController, it currently records high tension and defocus (and soon collection and convergence angles). The base class also gives the manufacturer-specific STEMController (AutoSTEMController for the Nion microscopes) a chance to record additional metadata specific to our microscope.

Each type of microscope (STEM, TEM, SEM, etc.) may have metadata common to all microscopes of that type but not common with other microscope types.

[w-markus]

Okay. I think I got your point.

I think the main difference between a scanning microscope and a TEM (also light microscope) is the type of illumination, i.e. focused/convergent vs.parallel illumination. However, one could regard TEM illumination as a limiting case of STEM with (almost) zero convergence angle. :-)

But for TEM one does not scan the beam spatially, but one may scan the illumination direction (precession).

As for our TEM there are five pair of modes between one can toggle:

(Low-Mag - Mag) , (TEM - Spot) , (Imaging - Diffraction), ( Imaging - EELS), (Bright field - Dark field)

Almost each combo makes sense.

Mag - Spot - Diffraction -Imaging is used for STEM Mag - TEM - Imaging - EELS - BF is used for EELS and so one

Therfore I am just wondering whether on can achieve a higher level of abstraction by defining an "ExperimentController".

When one electron microscopists talks to another about a specific experimental technique they quite precisely known of each other what type of ray path, detectors etc. has been used, what parameters are important to be controlled and to be recorded (-> metadata). However, how this is implemented is generally not known, i.e. which button to click, which API-functions to use. This hidden in the (S)TEM/FIB/SEM operators brain and the UI of the instrument(s) (=microscopes, detectors, external biases, ...). I think it is much easier to define what parameters have to be controlled, if one looks experiment wise.