Design notes for a generic communication protocol to control experiments and measurement hardware.
This initiative was born out of a desire of PyMeasure developers, contributors and users to achieve improved and more flexible experiment orchestration/execution, and to achieve (better) interoperation with other instrument control libraries.
LECO is meant to be a specification for a (programming-language-independent) protocol to enable users to run experiments with a number of hardware devices, including logging, data storage, plotting, and GUI.
PyMeasure is an obvious candidate for working with this protocol, and as such will influence the design somewhat, but we will take pains to make sure the protocol will be agnostic to the actual interface package (or language) used. The authors draw on their varied experience setting up such solutions in a number of research laboratories.
This is an overview over the LECO protocol. See the documentation for a more exhaustive description of the protocol and its elements.
Communication happens via messages (using zeromq) between participants (called Component) in a single application or distributed over the network.
There exist two different communication protocols in LECO.
A LECO network needs at least one Coordinator (server), which routes the messages among the connected Components.
Each Component has a name unique in the network, by which it may be addressed.
This name consists of the name of the Coordinator (Namespace) they are connected to and their own name.
For example N1.component1
is the full name of component1
connected to the Coordinator of the Namespace N1
.
That Coordinator itself is called N1.COORDINATOR
, as Coordinators are always called COORDINATOR
.
There are LECO implementations in the following languages: