Introduction

LabRAD Introduction

Summary

The LabRAD Project provides a distributed and modularized platform for instrument control and data acquisition/management applications.

Background

As science advances, novel experiments are becoming more and more complex, requiring a zoo of control devices and electronics executing complicated sequences of steps. Device availability and monetary constrains usually lead to a highly heterogeneous setup with components from several different manufacturers using many different protocols and interfacing mechanisms. This often results in control software being puzzled together to use and provide a multitude of interfacing and control functionality, each using their own calling conventions, data structures, etc. To make matters worse, usually a group of relatively independent programmers is trying to write and maintain the code base. Often this causes extensive duplication of effort as program segments are hard to reuse, since unpredictable changes to the segments by the original authors might compromise other code using these segments.

Approach

LabRAD addresses these and other issues by providing a platform to efficiently separate code into easily (re-)usable modules. The modules communicate with each over the network making the system inherently distributed. A growing library of pre-made modules will be available for download soon.

Benefits

Efficiency

The network distributed, modular nature of LabRAD brings with it two main benefits in terms of the efficiency with which LabRAD applications can be developed:

Since modules can be easily reused, a lot of common functionality, like data storage, graphing, GPIB access, etc., can be implemented in a LabRAD setup simply by downloading Modules shared by other people. Experiment specific custom modules can also be easily reused in many different scenarios. This significantly reduces the amount of duplication of effort during the development process.

Most programming languages were developed for a specific purpose making certain tasks extremely easy to perform while making others a pain. To give a couple of examples, LabVIEW shines when one tries to build a software "front-panel" with buttons and charts, but becomes very frustrating to use when it comes to complicated control flow. MatLab excells at math, but is rather clumsy for the development of interactive applications. For performance critical tasks, Delphi (or C) is an excellent candidate, while for quick turn-around scripting and control-flow Python is a great choice. What all of these languages have in common is networking support, allowing the development of LabRAD modules in the language that best fits the task. For this purpose, LabRAD APIs in many languages (Delphi, LabVIEW, Python) are already available, and others (MatLab, Java, ...) are being developed.

Maintainability

The way in which LabRAD implements the separation of different parts of a software project into modules improves maintainability in two ways:

The unified interface used to access LabRAD Modules allows different programmers to maintain their code virtually independently, preserving the freedom to add new functionality without compromising software projects relying on a prior version. Modules can even be exchanged in their entirety allowing, for example, a hardware device to be replaced by a different model or hooked up to a different computer, without having to rewrite any of the higher functionality of the setup.

A LabRAD setup usually consists of a multitude of small, self-contained modules rather than one giant piece of code. This makes it much more straight forward to test parts of the setup independently to ensure correct functionality as well as to assign responsibility to do so. Protocol enforcement and other error checking mechanisms assist greatly in the debugging process.

Scalability

An experimental setup based on LabRAD is inherently more scalable than one based on conventional control software. This is due to two reasons:

Most experimental setups need to perform tasks that can be logically separated. Data storage, for example, is largely independent of instrument control or even data display. LabRAD allows this separation to be translated directly to the software development effort. This way, the problem can be attacked in pieces from different angles by many people at the same time, greatly increasing the speed of progress. As the setup becomes more and more complex, underlying layers can be abstracted away to keep development at higher levels simple and organized. Complex instrument calibrations, for example, can be automated and effectively hidden from the data taking application.

As instruments get faster and provide higher resolution, experiments become more and more data intense. Much of this data needs to be processed on the fly and can potentially require a large amount of computation. Since LabRAD is inherently distributed, many computers can be seemlessly involved in a setup to provide a cluster-like scalability of processing power.

Next: Concepts

 

~ Markus Ansmann, Dec 10th, 2007