You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There was a big discussion over at pymeasure/pymeasure#53 about the Python experiment control landscape.
Some important points I gleaned from that discussion were:
It would be great to aggregate developers in one place to hopefully gain critical mass that would enable continuous activity/progress, as opposed to many fragmented, short-lived, insular implementations.
It's a very big and complex task to try to unify all of the aspects involved in python laboratory automation:
instrument/hardware communication
live monitoring or running predefined procedures
GUI/presentation layer
Hopefully a more manageable goal would be to unify the different "instrument-driver" layers floating around into one package, optimally with a featureset that is a union of what is available in the different packages (unit support, validators, testability/unit tests,...). That way at least that part of the measurement&control space is unified (GUI and sequences and automation not considered for now), and we would get user adoption because the "boring" part of controlling a setup, i.e. implementing drivers, would hopefully be already done. To quote a comment:
One weakness of python in this space is the time required to build up ui things as compared to labview and thats where it becomes a hard sell in industry.
We should catalogue (e.g. in this repo's Wiki) the different packages out there to analyse their design approaches, amount of implemented drivers, feature set (e.g. unit support, backend protocols,...) and potential for unification.
Also, check out this document in the wiki, that surely represents collected wisdom about the shape of an "ideal" instrument library.
Please discuss! Would people want to pitch in, assist, develop, merge efforts (or not), etc?
The text was updated successfully, but these errors were encountered:
An important point: We should find out if there is already a well-structured package out there that could become this unified solution, and would accept modifications/enhancements with ideas/drivers/features from other packages!
I just want to note that, from reading the various discussions across different python instrument control repos, both @hgrecco and @scasagrande have recently come back to working on their respective packages. Perhaps this would be a good time to renew discussion on this topic. (also, instrumentkit/InstrumentKit#175).
There was a big discussion over at pymeasure/pymeasure#53 about the Python experiment control landscape.
Some important points I gleaned from that discussion were:
Hopefully a more manageable goal would be to unify the different "instrument-driver" layers floating around into one package, optimally with a featureset that is a union of what is available in the different packages (unit support, validators, testability/unit tests,...). That way at least that part of the measurement&control space is unified (GUI and sequences and automation not considered for now), and we would get user adoption because the "boring" part of controlling a setup, i.e. implementing drivers, would hopefully be already done. To quote a comment:
We should catalogue (e.g. in this repo's Wiki) the different packages out there to analyse their design approaches, amount of implemented drivers, feature set (e.g. unit support, backend protocols,...) and potential for unification.
Also, check out this document in the wiki, that surely represents collected wisdom about the shape of an "ideal" instrument library.
Please discuss! Would people want to pitch in, assist, develop, merge efforts (or not), etc?
The text was updated successfully, but these errors were encountered: