Version 0.3 of PLACE represents a departure from prior versions.  It has been rewritten from the ground up, with a strong focus on modular, object-oriented design. Additionally, the web interface for PLACE, which has been in development for some time, now serves as the primary interface to the application. Running on completely new architecture and design principles, it is hoped that PLACE can provide value to a much wider audience in the near future.

History

PLACE began as a collection of scripts and drivers used routinely in the Physical Acoustics Lab at the University of Auckland. In 2014, Jami L. Johnson, Henrik tom Wörden, and Kasper van Wijk bundled these scripts into a new Python-based laboratory automation package. Their paper, PLACE: An Open-Source Python Package for Laboratory Automation, Control, and Experimentation, demonstrated the strengths of modular design and provided a vision for the future development of PLACE. Development of PLACE continued at a constant rate until, early this year, there was enough desire for new features to support a redesign.

Core Design

The purpose of PLACE is to automate data acquisition in a laboratory setting by coordinating activity between laboratory instruments. Some of these instruments take measurements, while others facilitate the measurements.

Flowchart for a Scan object

Steps involved in PLACE data acquisition.

As with prior versions of PLACE, version 0.3 uses an object called a Scan as the central component of the architecture and this object is responsible for organizing the series of actions that occur during data acquisition.

Where PLACE 0.3 differs from prior versions is in the way it handles instruments. Instruments are now viewed as completely autonomous modules, and the Scan object does not command their behavior.  Instead, each instrument has its own configuration data and is only responsible for its own execution. This design means that plugins describing new instruments can be written without needing to know anything about what is happening in the rest of the system, leaving developers free to customize PLACE in unlimited new ways.

To interface with PLACE, an instrument need only worry about three events.

Event 1 – Configure Instrument

When a scan is started, the user provides PLACE with data describing the entire scan to perform. Configuration data that is provided for an instrument will be provided to the instrument during this phase. The instrument should use this data to ready itself for data acquisition to begin.

It may seem counter-intuitive for the Scan module to be unaware of what each instrument is doing, but it really isn’t necessary. The user knows what each instrument need to do, and the instruments each know what to do. The Scan module is simply holding the checklist, making sure everything happens at the right time.

Event 2 – Update Instrument

Updates occur one or more times during data acquisition. Again, the Scan module orchestrates these updates, ensuring each instrument receives the update command at the appropriate time. The instruments themselves need not worry about what other instruments are up to, and should only perform their portion of the experiment. For example, a thermometer would probably record the temperature on each update. Whether or not a laser is involved in another part of the data acquisition is of little consequence to the thermometer.

Event 3 – Cleanup Instrument

At some point, PLACE will stop performing updates. Perhaps something has gone wrong with one of the instruments, or perhaps data acquistion is simply finished. In any case, this is where the instrument should wrap up. If it has been saving data, perhaps this is where it will write that data to disk. If it has locked a hardware or software resource, this is where it should be freed. You’re still here? It’s over. Go home.

JSON and the Arguments

For PLACE 0.3, the dashed argument style conventionally used in Linux programming has been abandoned for a single, more verbose, JSON-formatted, string argument. As with many decisions for PLACE 0.3, it came down to modularity. Supporting an unlimited number of instruments would mean supporting an unlimited number of command-line arguments, which is, frankly, not possible. JSON provides verbosity and portability. JSON-formatted data acquisition configurations are easy to understand and highly portable.

Consider the following configuration:

{
    "scan_type": "basic_scan",
    "updates": 180,
    "filename": "sample7403.h5",
    "comments": "24 May 2017",
    "instruments": [
        {
            "module_name": "alazartech",
            "class_name": "ATS660",
            "priority": 100,
            "config": {
                "clock_source": "INTERNAL_CLOCK",
                "sample_rate": "SAMPLE_RATE_10MSPS",
                "clock_edge": "CLOCK_EDGE_RISING",
                "decimation": 0,
                "analog_inputs": [
                    {
                        "input_channel": "CHANNEL_A",
                        "input_coupling": "DC_COUPLING",
                        "input_range": "INPUT_RANGE_PM_2_V",
                        "input_impedance": "IMPEDANCE_50_OHM"
                    }
                ],
                "trigger_operation": "TRIG_ENGINE_OP_J",
                "trigger_engine_1": "TRIG_ENGINE_J",
                "trigger_source_1": "TRIG_EXTERNAL",
                "trigger_slope_1": "TRIGGER_SLOPE_POSITIVE",
                "trigger_level_1": 128,
                "trigger_engine_2": "TRIG_ENGINE_K",
                "trigger_source_2": "TRIG_DISABLE",
                "trigger_slope_2": "TRIGGER_SLOPE_POSITIVE",
                "trigger_level_2": 128,
                "pre_trigger_samples": 0,
                "post_trigger_samples": 1024,
                "averages": 16,
                "plot": "yes"
            }
        },
        {
            "module_name": "xps_control",
            "class_name": "LongStage",
            "priority": 20,
            "config": {
                "start": 10,
                "increment": 0.25
            }
        }
    ]
}

As can be imagined, managing the configuration options for even a few instruments would be cumbersome using command-line parameters, and would prove impossible with a large enough set of instruments. The new process provides good documentation of configurations and supports an endless number of instruments, using any number of parameters.

Despite the strengths of the JSON configuration, it is easy to see that PLACE is more difficult to execute from the command prompt. To combat this, the command supports JSON configuration files, which will allow users to edit and save scans without the pressure of writing correct JSON into the terminal. Additionally, the web interface for PLACE is now up and running, providing a point-and-click method for generating data acquisition configuration data.

PLACE Web Interface

The PLACE web interface in its unconfigured state.

The PLACE web interface in its unconfigured state.

Generating the configuration data for data acquisition with PLACE is simplified by using the PLACE web interface. Like the PLACE source code, the web interface is also modular, meaning the interface is built of smaller webapps, each responsible for the configuration of one piece of the experiment. At the top of the interface, the options for data acquisition are configured. Below that, individual boxes control the configuration options for each active instrument.

PLACE web interface showing JSON configuration data.

JSON configuration data is viewable in the web interface.

JSON configuration data is generated for each instrument and, optionally, viewable at the top of the web interface. Typically, calling “Start scan” will send the JSON data to PLACE, but the web interface can also be used to generate configurations that can be saved to a file for execution at a later point.

PLACE web interface showing instrument configuration.

Each instrument is configured in its own box within the web interface.

Instruments that are needed for the desired data acquisition can be activated within the web interface, and the nested webapp module for the instrument will present the options available. The JSON configuration data generated for the instrument is continually updated in the scan module.

The web interface itself is JavaScript, but the JavaScript is generated from the Elm programming language. Therefore, developing a plugin for the PLACE web interface is as simple as writing a basic Elm module, and the PLACE repository provides the well documented Counter instrument for use as a template.

replace this

Plot data can be returned to the web interface through socket communication.

In addition to setting configurations, the web interface maintains a socket, through which instruments can return data to be displayed in the web interface. This is intended for plotting data, but any HTML data should be displayed without much issue. The Counter instrument demonstrates this feature with dummy data.

Current Implementation

As of today, the current version of PLACE is version 0.3.1.  The Scan module currently provides access to “basic scans” which means an experiment with any number of updates, socket access to the web interface plot, and data written to an HDF5 file specified by the user. Basic use of the AlazarTech 660 and 9440 oscilloscope cards is supported. Two stages, a long and a short, are supported through the Newport XPS C8 controller. A software Counter provides testing, demonstration, and other support features. It could also be useful for recording the current update count during data acquisition and/or injecting arbitrary sleep times between update rounds.

Additional instruments are expected to be added in the near future. Current priorities include additional stages and a vibrometer. Support for more advanced results visualizations will also be added in the near future.