Glossary

[bilderbuchi]

To avoid confusion, we need to agree on a common set of terms. These have been proposed, adapt as needed:

Director

The director is more or less what in my implementation is called mainControl, i.e. a main controller. An object which can issue commands to actors, possibly request data from individual actors possibly read data from an observer ...potentially a GUI could be attached here too.

Actor

The actor is a unit which (typically) instantiates an Driver class. Actions which the actor can take could be anything from measuring on a regular basis ("acting" as a sensor), advising hardware devices through the use of the driver to X or Y, just pushing out random numbers, ...potentially a GUI could be attached here too.

Driver

A component that communicates with some hardware in a manner we don't care about here... This can be a pymeasure.Instrument augmented with some functionality, or mabe better a wrapper class with a given API that contains an Instrument or other object In fact, concerning the topic in here, I would draw the abstraction boundary at the driver -- the details on how this communicates with the hardware should not be relevant for the zmq/protocol stuff.

Coordinator

A component which represent the intermediate zmq brokers, proxies - multiple coordinator instances might be necessary for the full framework, but potentially we can put all of them together into a single process/script. This should avoid the complexity/scaling of a purely point-to-point approach. Currently, this corresponds to the zmq majordomo broker, and/or a zmq proxy.

Observer

A component that only consumes message streams, but does not command actors. A consumer of data, which puts this data in some kind of datastructure, to be viewed/displayed/exported either at a later stage or live, or both Note: depending on setup, some commanding might be necessary, e.g. to subscribe/register.

Notes

Actor-Driver separation

I would dearly like to keep actor and Driver separated, to leave the entry threshold as low as possible, the learning curve flat, and the usability of pymeasure modular. If someone wants to just connect with the Driver instance, directly, that should be possible, and when looking at the class, easily understood (and implemented). Once a user is familiar with that, and a slightly bigger system is envisaged by a them, one or two Driver classes might get packed into actors (which might already exist for this specific instrument in pymeasure, or have easy templates), and a director attached to them (via broker/proxy/whatever), so both can be controlled together (e.g. in a sequence like fashion, Procedures as they are now should maybe not rely on actors, but could, and again, need to look into it further). Once a user is familiar with this bigger framework, they can then add new actors, to grow their system one by one. For quick tests, some simple measurements (and the first steps), one can still just open a python interpreter, connect to the hardware with Instrument, and measure a small sequence of things, ideally with out-of-pymeasure's-box classes for devices, and the only thing one needs to understand for it, is Instrument (and maybe not even that really). No need for servers, proxies, brokers, GUI, databases, etc.
At the same time, it is not necessarily necessary to use an Driver at all, an actor could contain a wide variety of a) logic (referencing "Custom functions (PID controllers) with defined inputs & outputs" and "dll based device" from the gist of @bilderbuchi), and b) arbitrary connections to hardware which is done by whatever piece of code a person might find. If they use an (pymeasure) Instrument, most attributes and methods should be easily accessible to the communication protocol, but if it does not exist, that should be fine too. This would give users a broad freedom, while at the same time they can be guided in a small-step by small-step fashion to master bigger challenges and journeys.

[bklebel]

I just now wanted to start changing this here, in order to make it more general - there are still comments here referencing "me", without good references who that "me" actually is, but I cannot edit the issue comment - should I make another comment, copying the above and then editing it? or should I maybe make a PR for a glossary document in the first place?

[BenediktBurger]

We can discuss individual terms in their own issue. However, the above mentioned terms are already defined. Therefore, I'd say, make a PR for a glossary document with these terms.

[bilderbuchi]

Yeah, after copy pasting stuff out of the original github discussions for a long time, I lost track of precise origins for the various snippets. A PR makes sense, just make a markdown document for now, we can add a sphinx+myst+mermaid skeleton structure later.

[bilderbuchi]

12 should give us a basis for discussion & iteration.