yaq/introduction


the yaq project

The question of software correctness ultimately boils down to, “Does it do what we have in our minds, even the things we have not gotten around to thinking about yet?”
— Alistair Cockburn

Instrumentation development is a key part of the scientific enterprise. Scientists have always relied on their creativity and wit to assemble new instruments capable of carrying out new experimental procedures. As technology has advanced, scientists are increasingly able to directly purchase pieces of their instruments. A modern instrument might contain a motor from company A, a sensor from company B, a specialty light source from company C, and a totally custom robotic sample stage. The brand new scientific instrument, doing a brand new experiment, is cobbled together from a few dozen parts, some new some old. The instrumental novelty arises from the creative way that all of those pieces are assembled and controlled in the context of the experiment.

Software integration can be a frustrating piece of the modern instrument development process. Each individual component has its own drivers and interface. A lack of standards means that each scientist must develop her own acquisition software which communicates to all of the relevant components. Weeks can be spent just integrating one new component into an existing project. Code reusability is typically poor, and technical debt grows quickly in an academic / educational context. Scientists may struggle to rapidly innovate on their experimental design when each hardware addition requires major software development. The yaq project aims to reduce this burden. In this way, yaq can ensure that your instrument is always racing ahead to "yet another acquisition".

separate, but close

The yaq project defines a simple framework for communicating with instrument hardware components. In yaq, each component of an instrument is supported by a tiny lightweight process that runs in the background of your computer: a daemon. Since each component has its own process, each daemon can be developed separately. No more troubleshooting all hardware at once using one monolithic acquisition software! No more worrying about how to simultaneously use 32 and 64 bit drivers!

This well-defined separtation between each daemon and client makes the yaq control framework less fragile than monolithic applications. At the same time, the language-agnostic and separate distribution channels for each daemon make it trivial to use and reuse pieces from instrument to instrument, as needed. No more rewriting basic hardware support just because you're changing your graphics framework! The developer-friendly TCP communication standard makes it easy to write flexable clients for any application. The communication layer can be routed over IP for communication between machines.

read more about the yaq communication protocol

complexity, corralled

Each component of a scientific instrument may have many parameters. Similar components typically have similar parameters, but there may be incidental differences between each implementation. For example, consider two different monochromators. The driver for monochromator A may expose the function "set wavelength", while the driver for monochromator B exposes "set angle". Any experimentalist wishing to switch from monochromator A to B must first go through their entire codebase to fix all of the small differences in the driver implementation.

The yaq project defines a family inheritence structure that aims to unify the interface signature for classes of hardware. By enforcing this structure, yaq highlights the similarities been different daemon instances, making it easier to create more flexable and generic clients. The family inheritence helps ensure that good conventions are known and applied well to each applicable daemon.

Of course, the yaq communication standard is totally generic. yaq daemons are by no means required to have family members.

read more about the yaq family tree

yaq also implements traits.

read more about yaq traits