Understanding pyleco applications and limitations

[mmerlo]

I'm looking into developing a gui that interfaces with multiple instruments. In several use-cases, these instruments are connected to the same computer but are simultaneously running different experiments (e.g., different procedures and producing different data streams to be saved to different files).

I've made a quick mock-up with just pymeasure and it seems like a lot of the library is aimed towards a single procedure producing data instead of multiple procedures running concurrently.

From the little I understand about pyleco, it seems to help with concurrent procedures and data streams, but I'd like to see what the community thinks.

Questions to start:

1. Is pyleco appropriate for use-cases where all instruments and GUI are on a single computer?
2. Is pyleco Windows only? I notice several mentions of Windows services and it is unclear if pyleco could be used with macOS and/or Linux.
3. There is mention of starting the Coordinator, a proxy_server, and a Starter with a Windows service on startup. Do any of these require being started in this way? Could these be started when a gui is opened instead?

Thanks!

[BenediktBurger]

Sorry for the late reply.

First answers to your questions:

1. You can perfectly use pyleco on a single computer. That is, where it originated from.
2. PyLECO works wherever you can install python (3.8 or up) with zmq as a dependence, which includes windows, macOS, and Linux.
3. The windows service is a suggestion, as it makes live easier, if your infrastructure is started at computer startup and restarted whenever it might have crashed.

• You can create systemd tasks if you whish (if applicable). They should start the coordinator, proxy_server, and starter. You might open a pull request with a description on how to add them.
• You can also open these programs in their own processes (started from your GUI). For example PyMoDAQ starts a coordinator, if none present yet. It calls (see https://github.com/PyMoDAQ/PyMoDAQ/pull/301/files):

def run_coordinator():
  command = [sys.executable, '-m', 'pyleco.coordinators.coordinator']
  subprocess.Popen(command)

I've made a quick mock-up with just pymeasure and it seems like a lot of the library is aimed towards a single procedure producing data instead of multiple procedures running concurrently.

Exactly, the pymeasure experiment is single process.

From the little I understand about pyleco, it seems to help with concurrent procedures and data streams, but I'd like to see what the community thinks.

Exactly. In #46 I explain my setup. Most instruments happily publish any new data they read (like radio broadcast) and any number of data loggers can log any subset of this data. For example one data logger creates an entry every second over the average of all the data received (for long term observation), while another one collects the data of every shot of the laser system (at 20 Hz).
So some devices may be used at the same time by different researchers.
It allows even some funny multiplexing: We have stepper motor cards for several stepper motors at once. As the motor card driver is a LECO component, different measurement software (maybe from differen researchers) can access the driver card at the same time, maybe one researcher controls one motor and the other one a second motor.
If a measurement software had taken control of the dirver card, no other software could use it at the same time, even though the connected motor is not used.