Experiment Server
I've been working on writing a server to allow for flexible experiment control. Most of the lab's current software is written in LabVIEW, which is easy to write, and great for fancy user-interfaces, but I have never been able to use their typedefs well. I also find myself wishing I could hot-plug diagnostic software in on the fly to help with troubleshooting. Hopefully, this experiment server will allow robust and flexible control.
This project was inspired by EPICS, an experiment-control framework for larger experiments. Much
Architecture
The server acts as a telephone book, allowing specialized processes to register their names at a central location. The processes are currently sorted into two categories, clients and sub-servers, depending on whether they issue or respond to commands. For example, a command-line client could issue commands to a digital-output sub-server.
A simple example transaction:
- CmmdLine sends "DigOut:SetOut 0" to the server.
- The server sees that the message is bound for DigOut, looks it up in the sub-server list, and passes "SetOut 0" on to it.
- DigOut sets its output to 0 as requested, and sends a confirmation message "SetOut 0 DONE" back to the server.
- The server passes "DigOut:SetOut 0 DONE" back to CmmdLine.
- Command line is very happy to have successfully carried out your orders :p
Of course, things can get much more complicated, but that's the general idea. The main benefits of this approach are
- Leveraging the power of ASCII, the universal interface.
- The ability to hot-plug diagnostic tools with access to all levels of the system.
- Easy, integrated logging (just print everything that goes through the switch).
- Robustness to sub-system failure.
- The code for a single compiled executable come in smaller, cleaner packages.
- Limited resources (eg. a digital output card) can be shared by several processes who are completely ignorant of each other.
Implementation
I used unix domain sockets for all the interprocess communication and pthreads for the multithreading (see choo and Multithreaded Programming with Pthreads [example code]).
The server currently only handles a single outstanding request per-sub-system, although in the future I hope to allow more. I also hope to add more EPICS-like 'publish-subscribe' communication as well as the current 'request-respone' format (for more efficient logging and monitoring). Once that happens multithreading can be bundled into the server, which will make programming the modules easier for the uninitiated :p.