Experimental Control

Title: Experimental control using Erlang/OTP
Author: Matt McDonnell
Date: 2006-04-10
Notes: Preliminary draft, expect changes soon


The research group of which I am a member performs quantum information processing experiments using trapped ions. The experimental side of this research involves setting up optical and electronic systems to enable control of the quantum state of the trapped ions using laser pulses. This requires hard real-time control with microsecond resolution for the actual pulse sequences.

At present control of the experimental system as a whole is via a control program written in Pascal on a computer running DOS 6.2. This computer has a number of data acquisition cards attached to it that allow access to analog-to-digital converters (ADCs) for input, digital-to-analog converters (DACs) and digital outputs (DOs) for output.

The advantage of using DOS as the underlying operating system is that real-time low level access to the computer hardware is obtained.

The main disadvantage of the present approach is that high level drivers for devices are unavailable, for example there are no USB drivers for DOS, and the GUI for the control program must also be written in Pascal. This means that higher level programming tools are unavailable such as lexer/parser constructors, GUI construction toolkits, version control software, etc. Additionally the networking capabilities of the controller are limited, as DOS is not a multiprocessing operating system and so the flow of execution must go from control of the experimental apparatus to networking when data needs to be transferred over the network.

Problem definition

The basic problem is to retain the low level real-time hardware access for the computer controlling the experimental hardware, while at the same time allowing access to modern device drivers and higher level programming tools to enable scalability of the system. The ability to use scripting or batch processing of the behaviour of the hardware in a high level language would also be useful.

A number of possible solutions exist:

The second approach has the advantage that modern devices can be attached to the overall control computer and controlled by the main control program. These devices tend to be things such as oscilloscopes or function generators that can be triggered by an external TTL pulse, so hard real-time control is retained by triggering the devices from the microncontroller.

System architecture

This approach is similar to the satellite real-time control example in Chapter 14 of "Concurrent Programming in Erlang" (2nd Ed) by J. Armstrong et al. The basic structure of the system in this example is a data manager that controls the external data handler that accesses the underlying hardware, and marshals data from external controllers to the hardware and from the hardware to display clients. Eventually I plan to implement this system using the Open Telecom Platform (OTP) behaviours, but to start with a simpler system is considered as discussed below.

The application consists of:

In addition there is an extra Erlang module currently outside the OTP application:

Modifications required for the existing experimental program:

Write a test "microcontroller program" ie a Pascal program that represents the experimental control program on the existing experimental computer. An extra layer of communication (over say the serial port or GPIB) is required for the actiual experimental control application, however this is just a process that echoes its input to the communications channel. Hence the complete set of non-Erlang programs are:

  1. A program to access the serial port.
  2. A program that represents the microcontroller process running on the remote machine.

In the current implementation only the second program is currently implemented, in the Pascal program testport.pas.


(WARNING: the Pascal port simulating the microcontroller drops core when it terminates, I haven't been able to fix this yet.)

The initial stage of development of the Erlang program to control the microcontroller didn't use the OTP libraries. Instead separate basic Erlang modules were written and loosely coupled together.
The files can be found in [erl_expt_basic.tgz], to run them do:

With this as a basis the construction of the OTP version was fairly simple, following the directions of [Pete Kazmier's "Writing an Erlang Port using OTP Principles"] tutorial. One difference is that my port_server module expects asynchronous inputs (casts) instead of synchronous inputs (calls). This is closer to the behaviour described in the real-time control example in the book, and is appropriate for the case where the hardware "pushes" data to the data manager. To change to the data manager "pulling" data from the hardware would require the microcontroller to store data until it is requested by a "get data" command from the port. This is not a problem for the current system, where the microcontroller is actually a full computer with a several GB hard drive, but could be impossible with a small microcontroller.

The code for the OTP version of the experimental control program is in [erl_expt_otp.tgz], to run them do: