MBE Dreams: Dream Software

Faebian Bastiman

Returning to the theme of “Dream MBE”, I would like to spend a moment discussing molecular beam epitaxy software. Off the shelf MBE software is passable at best. Ok, so it can open and close shutters, perform temperature ramp ramps and execute a sequence of commands in some form of recipe: This is, when all is said and done, the bare minimum. When you spend some time actually considering the features you would like in MBE software, you quickly realise nothing on the market really hits the spot. So… I have spent the past six months writing my own MBE control software: EPIC™.

You cannot create the world’s greatest MBE software in six months, however you can implement an exciting list of features and lay the foundation for fantastic things to follow. Beyond the bare minimum functionality, the features of EPIC™ are:

  1. Comprehensive, optimised software-hardware interface (SHI)
  2. <1 millisecond to process a shutter request
  3. Full device parameter explorer and editor
  4. Ability to monitor PID loops, pyrometers, plasma sources, pressure gauges, pumps, valves, motors, services (LN2, water flow, gas pressures) status and other hardware (e.g. reflectivity data) all from a central, grouped, tabulated status screen
  5. Associate any number of physical devices with an individual control loop
  6. Ramp to temperature set point or output power for PID controllers
  7. Flexible, simple script recipe with full control flow, local and global variables, unrestricted parallel editing and execution including “edit on the fly” and access to any parameter from any device
  8. A colour co-ordinated message box
  9. Wake-up and sleep scheduling
  10. Substrate location and status tracking
  11. Automatic flux scheduling, gathering and Arrhenius/polynomial fitting
  12. Atomic flux, growth rate, doping and composition calculation tools
  13. Material usage tracking and cell fill level estimation
  14. Two data logging modes: SPAM (log at fixed interval) and SMART (log only on change)
  15. Watchdogs warnings and actions
  16. Integrated simulation mode with full hardware emulation

Ok let’s analyse that numbered list. (1) SHI is a fantastic interface with every device possessing its own read and write thread. SHI enables (2) and (3) by its very nature. Not every process requires less than 1 ms shutter response, though since it exists by default I thought I might as well include it in my list. The device explorer is also a nice feature, since the front panel menu on most devices can be a pain.

The status screen (4) is very comprehensive and the layout facilitates ease of reading. A quick glance can reassure you that every part of the MBE system is ok (or equally quickly warn you when it isn’t!). All necessary items are interactive, giving the ability to perform ramps and open/close single/multiple shutters. The ability to associate any number of devices with a control loop (5) is very useful for plasma sources when they may have: a mass flow controller, a RF power controller, a main shutter, several valves and an optical monitor. So too is performing power ramps (6) for certain control loops, like carbon sources.

The recipe script (7) is essentially its own programming language complete with interpreter. Each recipe executes on its own thread and all commands run to 1 ms precision. The control flow allows you to step through each line individually one-by-one or allows the recipe to run freely, you can pause any line, go to any line from any line, skip lines, stop the recipe at any point and edit the recipe on the fly (only when paused for safety) and the recipe checks every line for errors on edit. Local and global variables allow parallel recipes to control complicated processes. Whereas access to any device parameter gives the ability to do almost anything, including in situ reflectivity control (see Dream Machine).

The message box (9) simply keeps you informed with a variety of colour co-ordinated, time stamped status updates including “Recipe X completed”, “Ramp X started”, “Sample X moved to position Y” or the less pleasant but equally useful “device X failed to respond”.

Wake up and sleep is fantastic (9). One can sleep much better knowing the machine will wake up at 06:30, do all the flux checks for the day and wait for you to stroll in at 09:00. Equally, the sleep mode prevents that troublesome “did I ramp down the Gallium before I left?” since it sets the system to a predefined standby state.

When you have more than a handful of substrates and/or more than a single user it is very useful to have a substrate tracking screen (10). Each substrate can be individually tagged with a name, a colour co-ordinated status (new / degassed / grown) and its current location in the system. The substrate tracking paves the way for extended functionality such as automatic run logging, automatic growth sheet creation, automatic sample transfer and batch sample processing (all of which are on my to do list).

Any software that purports to convert effusion cell temperature into growth rate is just plain lying! Beam equivalent pressure (BEP) is typically what you measure and atomic flux in atoms/nm2/s is what you get. Growth rate is simply something you induce depending on the atomic density of your substrate. Software that gathers flux data for you (11) and plots it on a graph is a welcome start. A one click fitting option ranging from simple Arrhenius to 12th order polynomial fitting is sufficient to handle all source and opens the door for much, much more. The first step is enabling conversion from BEP to atomic flux. Once done you can use a growth rate and doping calculator tool that updates to the correct doping density and growth rate for any substrate (12). You can then “ramp to doping density” or “ramp to growth rate” rather than “ramp to set point”. You can estimate the real time composition during growth and calculate the composition ahead of time for a given cell temperature combination. Perhaps my personal favourite is that you can integrate the flux with time every single second and track the cell material usage, display it on a simply bar chart and estimate the fill level of each of your sources to 1%. All of these flux related features are present in the current version.

Of course you want to log all relevant data values (14) and the option to log only on change prevents large data files being created when the system is idle (over a weekend). You also want to monitor the instantaneous data values and be warned when they are outside of an “OK” range. Moreover, for certain values you would like the software to take an action on your behalf to prevent damage (15). Finally you may want to run the software in “off line” mode to “try before you buy” or even to “test a recipe before you run it for real” and in these circumstances the simulation mode is very handy.

Q: What could possibly be missing?

A: Access to the source code.

The reasons for open source MBE software are almost as numerous as the feature list itself, so let’s stick to the two most important ones:

  1. Add device drivers for any hardware
  2. Add/edit/remove content to the user interface

Adding device drivers is somewhat essential. The system hardware changes over time as the system is upgraded or re-commissioned for a new purpose. The current EPIC™ has a generic driver template that can be used to create a new device driver in around 30 minutes. The next step is to make that driver template available to all and to use device driver DLLs. Fairly simple.

The user interface is a very personal thing. The software-hardware interface (SHI) is rather universal once done right, but the user interface is a matter of taste. Script recipes are very powerful but perhaps not for everyone. Tabulated data makes for fast referencing but perhaps diagrams are more your thing. Etc. Etc. Etc. There are three solutions beyond making the software open source:

  1. Create a software development kit (SDK) for EPIC™ to allow everyone to customise it with their own desired features
  2. Allow SHI to be a stand-alone data acquisition tool that can be used either via windows API or via a socket interface to allow the user to create their own graphic user interface or web application
  3. Provide customisation on demand and provide a tailor made solution for each user

Happily EPIC™ will have all three.

One final question: Where can I try the latest EPIC™ beta demo version?



One thought on “MBE Dreams: Dream Software

  1. Pingback: Molecular Beam Epitaxy: Dream Machine | Dr. Faebian Bastiman

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s