-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unify different instrument driver solutions #22
Comments
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 have started a list of the Python packages relevant in this space that are currently known to us in #23. |
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: