Skip to content
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

Open
bilderbuchi opened this issue May 1, 2018 · 3 comments
Open

Unify different instrument driver solutions #22

bilderbuchi opened this issue May 1, 2018 · 3 comments

Comments

@bilderbuchi
Copy link

bilderbuchi commented May 1, 2018

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?

@bilderbuchi
Copy link
Author

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!

@bilderbuchi
Copy link
Author

bilderbuchi commented May 1, 2018

I have started a list of the Python packages relevant in this space that are currently known to us in #23.

@JAnderson419
Copy link

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants