Customising tool functionality with the SmartSEM Application Programming Interface

Read the documentation and find example code for API programming or post your own!
Post Reply
user-42
Posts: 27
Joined: Thu Jan 01, 1970 1:00 am

Customising tool functionality with the SmartSEM Application Programming Interface

Post by user-42 »

INTRODUCTION

Innovative electron microscopic experiments often require new functionality that is not provided by the default operating software of the microscope. Automation of complex operation sequences in customised software applications using a programming interface to the microscope controls provides such functionality. It can leverage the instrument to perform tasks that exceed its core capabilities by far, turning ideas about new experiments into reality.

ZEISS electron and ion beam instruments can be custom programmed according to specific application needs using their application programming interface (API). The ZEISS SmartSEM Remote API provides access to almost every microscope parameter available on ZEISS scanning electron microscopes or CrossBeam focused ion beam-scanning electron microscopes. It provides full access to the microscope controls, allowing automation of complex operation sequences and implementation of new workflows.

The Remote API enables complete control over electron and ion optics, stage, vacuum system, detectors, scanning and image acquisition from custom programs running on the local microscope PC or on a remote PC. Documentation and example code in various programming languages as well as technical support are provided upon purchase of the Remote API to ensure that new developers quickly achieve results.


SOME TECHNICAL CONCEPTS

The application programming interface (API) consists of an Active X control that provides access to the SmartSEM software and via this software to the SEM microscope settings. It provides methods to set and get analogue microscope parameters and digital states, to send commands to the microscope, or to grab images. It can be accessed by various programming languages such as Visual Basic, Visual C++, or Visual C#. Thus, application developers can take advantage of the virtually unlimited programming possibilities of the Microsoft .NET framework. Example code written in C# is available in a separate thread. The API can as well be accessed from various scripting languages such as VBScript and JavaScript.

The following series of microscopes are supported:
  • 14xx
  • 15xx
  • Auriga
  • EVO
  • Merlin
  • NVision
  • Sigma
  • Supra
  • Ultra
Please note that it is necessary to have an agreement with Carl Zeiss Microscopy to develop applications that utilise the CZEMAPI.OCX. Upon the signing of such an agreement, Carl Zeiss Microscopy will provide the necessary support files and technical information to allow development to proceed.

The main part of the SmartSEM software is the EM Server. The Server maintains a list of states and parameters of the SEM. The SmartSEM UIF or external applications can send instructions (such as “Filament Heating On&#8221 ;) or modify parameters (“Magnification = 10000&#8221 ;) , which are then processed by the EM Server. The CZEMAPI ActiveX control is the main channel of communication to the EM Server. It can run on the same computer as the EM Server or on a second computer. When the 3rd party software runs on a separate computer then the API Active X will take care of the communication between client and EM Server.

The control of the instrument, and hence the interface between user interface components and the instrument control, is based on the concept of parameters, states and commands. All messages to the server from client applications that refer to any parameter do so by means of a unique identifier that is derived from the type of parameter and the low-level parameter ID. When using the CZEMAPI control you just refer to the parameter symbol as a string and the control will get the parameter ID.

Setting of a parameter and display of a parameter value are two different functions. If the user sets a value on the UIF, this results in a request to the EM Server to set the value. As appropriate the value is subject to limit and validity checking and then routed to perform the required function. Parameter value changes result in a notification message being sent to the server, which is passed on to CZEMAPI.OCX, which then notifies interested UIF objects that a parameter or state has changed. This separation ensures that all objects are correctly updated and setting of parameters is subjected to consistent checks that are localised to the modules concerned.

Since there are a very large number of parameters on the SEM, a mechanism is provided to reduce the number of choices presented to the user according to the user’s requirements. Each parameter, state and command is assigned to a category: Novice, Expert or Service and a user may select a „User Level‟ of Novice/Expert/Service which restricts the number of parameters presented for selection according to category.

Analogue parameters are those that have a full numerical range between defined limits. Example: “Image Shift X”. All parameter values are in standard SI units, e.g. currents are in Amps, distances are in Metres, etc. When parameters are displayed on the UIF, a suitable display string is made, using for instance mm, μm, nm, etc. rather than 10[SUP]-3[/SUP] m, 10[SUP]-6[/SUP] m, 10[SUP]-9[/SUP] m etc. Every analogue parameter has a unique numerical identity, which is associated with a symbol starting AP_, e.g. AP_ MAG. Attributes of an analogue parameter are its name, limits, type (normal, X of XY pair, Y of XY pair), units type, among others.

Digital parameters are those parameters that have a discrete set of values. For example, the digital parameter “Spot Mode” has the states “On” and “Off”. Every digital parameter has a unique numerical identity which is associated with a symbol starting DP_, e.g. DP_STAGE_IS. Attributes of Digital Parameters are, for example, its name, enabled/disabled, and state values. Dynamic conditions of the instrument, e.g. the “Beam State” which includes not only the static states like “EHT Off” but also all transitional states such as “ramping” and “shutting down”, are represented by a set of such state values.

There is also a small number of string parameters, e.g. SV_SERIAL_NUMBER.

Commands are functions that initiate some action, e.g., “Beam On”. Every command has a unique numerical identity which is associated with a symbol starting CMD_ , e.g. CMD_BEAM_ON.

Here is a very simple C# code example to read out the Mag:

using System;
using System.Runtime.InteropServices;
using APILib;

namespace Example_Get_Mag
{
class Program
{
static void Main(string[] args)
{
// Create an ApiClass instance named CZEMApi
ApiClass CZEMApi = new ApiClass();

// Initalise communication between CZEMApi and EM Server
CZEMApi.Initialise("");

// Initialise a VariantWrapper object to reference the parameter value
object value = new VariantWrapper((float)0.0f);

// Get parameter numeric value
CZEMApi.Get("AP_MAG", ref value);

// Write value to the console
Console.WriteLine("Mag = " + value.ToString());
Console.ReadKey();
}
}
}
Post Reply