Home

About LaSER-Project

Welcome to the wiki for LaSER-Project. The brilliant minds at UCLA Physics' Hudson and Cambpell Labs use LabRAD as their platform of choice for experimental control. Generally speaking, LabRAD provides a platform to allow one to easily break complex software into smaller, simpler modules that can communicate with each other over a network using a server/client protocol based on procedure-calling.

pylabrad is a package designed to provide a Python wrapper over the core LabRAD system, which was written in Scala. EGGS-Campbell, the experimental control software repository used by both the Hudson and Campbell labs, is built on top of pylabrad and implements several servers related to scheduling and running experiments, which not only write commands to various instruments, but also measure and record the data they acquire.

The goal of this project is to give these labs the ability to simulate various instruments used in these experiments as desired, by writing the internal logic of each instrument as a Python class. Simulation takes place at a level low enough to fine-tune how an instrument should respond to any specific command with the power of any Python library at one's disposal, but at a high enough level that one gets to write in Python and also does not have to concern themselves with how bytes get to the device and leave it. When writing a device, all one must do is extend a base class and provide a mapping of command strings to handler functions using a specific, simple-to-read-and-write format, write the handler functions, and add properties specific to the device (to represent some sort of state of the device) that the command handlers will save values to, or get values from. Because so much freedom is given to the programmer, the degree of simulation is up to the programmer, and depending on the use case this may be as simple as doing nothing for some or all commands (meaning the purpose is just to ensure valid commands are being written to it), or as complicated as using complex data generation algorithms to get a return value. Also, one doesn't even have to specify every command, just the ones they plan on using.

There are two main servers in the EGGS-Campbell repository that communicate with hardware directly, the SerialBusServer (for Serial devices) and the GPIBBusServer (for GPIB devices). Simulation logic is added to these servers with care using a "real boy" philosophy. Of course, at a minimum it's essential that when clients (usually other servers) interact with these servers, the sequence of procedure calls is exactly the same whether the device is real or simulated. However, we take things a step further; those who find themselves browsing the repository code will note that most logic specific to simulation is packed within one module, the HardwareSimulationServer. Of course, other servers must communicate with this server in order to communicate with simulated devices, but within those servers logic specific to simulation is as limited and walled-off from other code as possible, and is nonexistent by the time a Python object representing a connection to an instrument is initialized. Specifically, in the GPIBBusServer simulation-specific logic strictly takes place in server initialization and in methods that handle signals from the HardwareSimulatedServer about the current array of available simulated devices. In the SerialBusServer, in addition to those areas there's also simulation logic in the polling process and in a method that initializes a python object representing the device. This is fortunately not necessary in the GPIB case because in that case logic takes place at a lower level, in a pyvisa backend that wraps the NI-VISA driver c code in python (much like the default pyvisa backend) while also providing simulation logic based on the address of the instrument one opens a connection to.

When one adds a device to a bus, they create a fake port also, so one can create an unlimited number of devices with different states. Simulated devices survive and maintain their state even when if the node they are logically connected goes down (since they all live in the global HardwareSimulatedServer). A device can also be added to a fake port on a fake bus by communicating directly with the HardwareSimulatingServer instead of doing so through a Bus Server.

Using LabRAD's signaling feature, a change in a state to one device can automatically affect the state of another device, no matter if either or both of those devices is simulated. This is done by user-specified "SimulatedConnections" between devices where the user can state how a value of some attribute in one device should be consistent in some fashion with a value of some attribute in another device.

Potential use cases:

• Finding bugs in experiment scripts without needing actual devices plugged in
• Running an experiment where one only has a subset of the devices needed at the current moment (especially when onboarding multiple new students so they can all conduct the same experiment simultaneously).
• Testing out a device before buying it

Important Resources

pylabrad EGGS-Campbell pyvisa pyserial