search

labscript-suite-temp-2 / blacs

BLACS, part of the labscript suite, provides an interface to hardware used to control a buffered experiment. It manages a queue of shots to be run as well as providing manual control over devices between shots.
Other
0 stars 0 forks source link

Analoge Inputs #23

Open philipstarkey opened 7 years ago

philipstarkey commented 7 years ago

Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

Analoge Inputs should be displayed in BLACS device tab just like analoge outputs. They should not be editable and when in manual mode update at a given rate. This would allow quick checks of Voltages without needing to run a script to do so and make troubleshooting easier. This should not be to hard and I'm probably gone create a pull request for this in the next few days/weeks. Just wanted to post this here to get comments on wether this is something others are interested in.

philipstarkey commented 7 years ago

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

Yes, this is something we've wanted for a while. I would also like to see maybe the ability to popup a live graph or similar. The main implementation detail to be aware of is that we want this to be done using ZMQ PUB/SUB sockets. So the aquisition worker will publish to a named ZMQ socket, and the tab will subscribe to sockets as appropriate. This allows other things (even those outside of BLACS) to access the data as well, over a standard interface, with minimal overhead. @chrisjbillington will probably have some more to say when he gets back from leave!

philipstarkey commented 7 years ago

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

Ok I think I got this almost figured out. I'm guessing the idea was acquisition workers publish to a broker that lives in BLACS and subscribers subscribe to that Broker.

Just one minor detail as you mentioned that other things would also want that data should we put the Broker ports into the lab config? The port can't be random if we want it so be accessible from outside.

philipstarkey commented 7 years ago

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

I think the idea may have been to have one broker per device, that lived in the subprocess actually acquiring the data, but i'm not sure if that is correct or feasible if you need to assign each one a port....

Ok, ZMQ docs indicate that the PUB/SUB model has the PUB socket created where the data is. So it definitely needs to be in the worker process. So we'd need some way of creating ports. Possibly BLACS GUI tabs should request a port number from something centrally in BLACS and then pass this on to the worker process? BLACS could publish a list of device name/ports on which data is being published so that it can be accessed outside of that device tab. Not sure if this is a good plan though, it seems a bit messy. I sort of assumed Chris Billington had this figured out mostly already, but unfortunately he's not available to discuss again for a while.

There is also the risk that a slow subscriber slows down the consumption of data in the PUB/SUB model, which could affect the performance of the worker process.

philipstarkey commented 7 years ago

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

The Publisher lives in the Worker and publishes to the Broker that lives in BLACS. The Broker works as a hub. Any Subscriber (GUI or other ) could than subscribe to that broker only and listen to any topic they'd like. Performance of the worker process should not be affected by this.

The only question is where to set/config/store the publishing port (that subscribers subscribe to) for the broker.

philipstarkey commented 7 years ago

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

To make it more clear this is kind of what I'm going for: Forwarder

And the forwading port that subscribers subscribe to has to be fix if we want apps other than BLACS to access analog input data.

We could however make that a second pull request and start off with BLACS binding to a random port that it passes to it's analog in widget update thread.

philipstarkey commented 7 years ago

Original comment by Philip Starkey (Bitbucket: pstarkey, GitHub: philipstarkey).

I see. Yes then, we should have the broker port in labconfig. The broker should definitely exist in a separate BLACS thread. We should possibly consider whether it should even be a separate process so that it doesn't get slowed down by anything else in BLACS, or cause BLACS to consume ridiculous amounts of RAM (I don't know how much it will buffer, or how much CPU it will use...but we could considerably have dozens of analog inputs streaming data though this broker. Might be worth it to spend the time avoiding the Python GIL now)

philipstarkey commented 7 years ago

Original comment by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).

Yeah sure it can live in it's own process why not. I'll add all those changes to my 'beta' version of analog in widgets and then create a pull request later this week maybe even today.