ExampleSetup
LabRAD Example Setup
Connection Diagram
Logical Diagram
Overview
| Name | Module Type | Provides | ||||
|---|---|---|---|---|---|---|
| EXPT | N/A | Readings from and control mechanisms for the experiment | ||||
| RS232 Server | Base Server | Byte-level read and write access to COM ports | ||||
| GPIB Server | Base Server | Byte-level read and write access to a GPIB bus | ||||
| DataStrg Server | Base Server | Storage and retrieval of experimental datasets | ||||
| FnGen Server | Abstraction Server | Access to features of a function generator | ||||
| DAQ Server | Abstraction Server | Access to features of the data acquisition hardware | ||||
| Graphing Client | Client | Graphs of new data incoming to the DataStrg Server | ||||
| ExptScrpt Client | Client | Scripts to run the experiment |
Details
RS232 Server
Discovers the list of available COM ports on the computer it is running on and provides methods to open a port, choose the baud-rate and data format, send bytes, and read bytes. It does not know anything about the type of hardware connected.
This Module is written in Python, which makes access to COM ports easy through the pySerial package. Since COM ports are very low bandwidth interfaces, Python's execution performance is not a limiting factor for this task.
GPIB Server
Gives access to a GPIB controller card, allowing the selection of a target address and the sending and receiving of raw data. Might do some basic device discovery by sending '*IDN?' commands to all addresses, but is otherwise unaware of the actual hardware connected and how it operates.
This Module is written in LabVIEW, since GPIB access is very convenient in this language using the VISA libraries.
DataStrg Server
Manages data storage by providing functions to create new datasets, list datasets, add and retrieve data points, store experimental parameters as meta-data, etc.
This Module is written in Python, where dynamic typing makes it straight forward to handle the different meta-data formats.
FnGen Server
Maintains a list of all function generators hooked up to the LabRAD system through possibly multiple GPIB Servers running on many different computers. It creates a central location for access to the higher level functionality of these devices by name, i.e. "Output a 5kHz 0.5Vpp square wave on 'Input A'". These requests are turned into the required command strings and passed on to the correct GPIB Servers.
This Module is written in Python, because of its string assembly and parsing abilities.
DAQ Server
Allows other LabRAD Modules to ask for the different readings provided by the experiment. It retrieves these by sending the correct command strings to the RS232 Server to tell the custom DAQ board to record voltages. It then parses the returned strings to extract the readings.
This Module is written in Python, because of its string assembly and parsing abilities.
Graphing Client
Monitors the DataStrg Server for new datasets being created or existing ones being updated. It automatically shows plots of incoming data as it arrives in the DataStrg Server. It might provide the user with an interface to perform some quick on-the-fly data analysis, like fitting parabolas to extract maxima, or exponentials to gauge decay times. The Graphing Client can also be used to browse all existing datasets ever stored using the DataStrg Server.
Since multiple copies of the Graphing Client can be run simultaneously on any computer connected to the Internet, collaborators can be watching the incoming data live and suggest changes to the runs in a teleconference.
This Module is written in Delphi for performance reasons and because Delphi programs compile into a stand-alone executable that can be shared easily with collaborators without requiring them to purchase or install other software. Alternatively, for small datasets, LabVIEW could be a natural choice for its plotting capabilities (for larger datasets, LabVIEW's plotting functions become extremely sluggish).
ExptScrpt Client
Can either be a single script or a collection of scripts that send commands to the FnGen Server to set up the experimental parameters and request readings from the DAQ Server. The so collected data is then passed to the DataStrg Server.
This Module is written in Python, because of the simplicity and speed with which Python scripts can be developed.
Benefits
High Turn-Around
The ExptScrpt Clients do not need to worry about how the FnGen Server and the DAQ Server perform the requested actions or what happens to the data after it is passed on to the DataStrg Server. This makes the development of these clients extremely fast and clean allowing for a very high turn-around of new experiments.
Reduced Duplication of Effort
Common functionality, like storing or plotting data, can be easily packaged into a separate LabRAD Module. This reduces the code necessary to implement these features separately in all locations where it is used.
Flexibility
Should the hardware layout of the experiment change, a new DAQ card, for example, can be swapped in and supported by the DAQ Server without a change in the interface that this Server provides to the System. Thus, all other parts of the system will remain functional (without even a recompile).
Performance
Since the ExptScrpt Client does not need to worry about displaying or storing the data, its performance will not be impacted by potentially complex plotting functions or slow data storage access. Since the "Store Data" Requests can be sent to the DataStrg Server in a fire-and-forget manner, the overall system's data taking speed will not be impacted by the rate at which the data can be stored or displayed by the (potentially numerous) Graphing Client.
Since Modules can have multiple LabRAD Requests "in flight" at the same time, execution can be parallelized and even pipelined to a large degree in a very straight forward manner. Many of the common headaches associated with these practices like race conditions, etc., are handled gracefully behind the scenes, since Requests are always executed atomically and serialized correctly within a Context.
Maintainability
Different programmers can service the different modules of the system independently. This reduces the burden on everyone to understand the entire system down to the last detail.
Next: Quick Start (for now)
~ Markus Ansmann, Dec 12th, 2007