Experience of a new user/intro

[bilderbuchi]

Hi!

I just found exopy and tried it out, and I want to tell you about my experience, so if you want you can take this into account when working on the documentation/implementation.
Let me also say that I realise this is alpha-level software (At least according to setup.py), so half the things I encountered are probably not implemted yet, so no hard feelings! I just hope that the experience of a "fresh" set of eyes can be useful for your dev effort.

• The installation process was very smooth, I created a new conda environment, two commands, done. Very very nice!
• Docs are available, and it's not only autogenerated API reference, looks promising! Although, an experiment automation GUI package, and not a single screenshot feels very strange!
• I am presented with a reasonable GUI - not totally empty, not cluttered, looking good.
• Let's start. Ah, there is a "first steps" in the docs, nice. Hm, the "creating a measurement" section only describes this in general terms, no concrete examples. Let's see if I can create something from scratch...
• Hm, so "tasks" seem to be mainly single Python commands (break, continue, sleep, loop)...very weird, let's try to make a loop incrementing a value (Hint: A simple, but concrete tutorial would be super useful at this step to introduce your nomenclature and expected structure/data model of a measurement).
• Am I supposed to program Python scripts, only with point-and-click? I must be missing something...
• Apparently there is no way to run a user-specified python script as a task. Don't know how I am supposed to program more complex logic here??
• I have tried several ways to increment a counter in a loop, and enqueue to check.
  • Even found out this "definition" task, which apparently creates "global" vars, but i don't know how to access those in another task?
  • I added a definitiontask in a loop task (is that the correct way) and tried to assign item0 + 1 to item0 - doesn't find it.
  • Let's try with Rohrer_index to get the index of the loop? no.
  • {Rohrer_index} as suggested somewhere in the docs? no.
  • btw the autocomplete that is mentioned did not work, or I did not know how to trigger it.
  • OK, I don't get it, let's move to the instruments.
• Guessing there is a list of predefined instruments I can choose from... Go to tools- instruments - open browser...hm, every single dialog/window I am finding is empty. I cannot even add any own instruments, as there is no type to select. Very weird, maybe some database/subpackge was not loaded, but I did not see any errors.
• At this point, I just start browsing around. I do not know what to do with the "database editor" tab - nothing is actually editable, and it just contains some strings which apparently indicate what variables are available in what scopes... Right-clicking to add access exceptions like the tooltip suggests doesn't do anything.

Finally, this looks like it could be very useful if polished. 👍 The GUI looks clean and I guess modular. If you can plug existing instrument libaries (instrumentkit, lantz, pymeasure,...) in there, it could be quite useful and reduce your development effort. A plotting window to select and plot variables during a measurement would be important I think.
The whole workflow surrounding "tasks" (you really had my hopes up because I was looking for such a thing) is *super confusing and I could not make sense of how to use this/what to use this for. Instruments totally lacking (Even no dummy/fake/test instrument) was very weird, I just thought there must be something wrong in packaging.

I hope this was useful to you, and you're not thinking I am complaining!

[MatthieuDartiailh]

Hi @bilderbuchi

I will try to answer to your question point by point (and then answer to your ping in pymeasure).

• I am happy the installation ran smoothly, it should and I am always happy to know it does
• the fact that the docs are lackin in screenshot is indeed an issue but I never found time to fix that. Hopefully in the coming weeks as interns will join the lab, I will try to have them improve this part.
• Your third point is actually related to a number of the others and come from the fact that Exopy try to provide a generic framework into which users can come and plug their own machinery (instrument drivers, tasks, etc). Which is why the core library only include very general terms, and as I don't want to advertise too much our lab package (exopy_hqc_legacy, which you can install if you want to play a bit more with the system) which is quite crappy in some respects, I cannot give good real world example. Once again I hope to improve that in the future.
• Tasks are meant to be an abstraction layer for an operation to perform during a measurement, such as saving data, reading an instrument etc. You can look at more concrete examples in the above cited packages. Actually in most fields of tasks, you can enter one line python expression and use { } to reference a value set by another task. If this was not clear from the docs, it REALLY needs to be clarified.
• As for your other comments I believe I already answered to them. For instruments, actaully one can in principle use any external package, but you will probably have to write tasks to actually do anything. For I3py I am working on a bridge smart enough to understand the driver capability, but this requires a certain level of introspection on the driver that may not be available on all the packages you mentioned.

Anyway thanks for your feedback and for testing. Do not hesitate to ask more questions.

[MatthieuDartiailh]

One thing I forgot to mention : plotting !
Live plotting from inside the acquisition is from my point of view a very bad idea ! I prefer to isolate both processes. Currently we use an old crappy piece of code to do the live plotting but that it fully independent from the execution. I DO NOT want plotting to interfere with the measurement.

[bilderbuchi]

Thank you for your reply!

• Generic framework and plugin system: In general this is a good idea! If this is well-structured it can be pretty flexible/accomodating to different usecases, I think. Are you saying that exopy should always remain just a "scaffold" offering a common API, and many different plugins interchangeable for every layer of the application (instruments, tasks, GUI/plotting,...)? If so, this could maybe be a good anchor point (maybe) for what we were discussing in [discussion] InstrumentKit pymeasure/pymeasure#53...
• Maybe it's not too presumptuous and actually a good idea in terms of usability to include some default solution, but make it clear which components can easily be exchanged with a plugin approach!
• For the tutorial, I am not talking about a real-world example (though that would be good to have available to act as a "style/usage guide" for the user later. I am talking about simplistic examples, just things like incrementing a variable in a loop, or calling some Python function in a loop, or adding a FakeInstrument,... these would already give a "feeling" how the GUI is used to create a measurement/etc.
• The _legacy part of your package name and the transitory nature mentioned in the description made me think this is an old thing, not used anymore, or soon to be discarded.
• I realised that I could enter Python one-liners, but it was not clear to me how scoping worked between tasks (apparently not equivalent to Python), which variables I could carry over and how to address them (without variables there's not much useful you can do in one line), and autocomplete didn't do anything, either. The {} syntax I stumbled over in a tooltip, I think.
• Btw, why do you need to fumble around with some templating/replacement syntax? Why can't you just address like SurroundingLoop.value instead?
• Sounds good that other instrument packages are possible to include, but how do you conform to their API and different capabilities? Does someone have to define a wrapper/translation layer to make exopy understand, e.g., InstrumentKit or Lantz instruments? I3py sounds like it would become that, right. Why not use some other existing, documented, tested library isntead of reinventing, though?
• I totally understand about non-interference! I think that plotting will be essential. For example, in an experiment in my lab we need to supervise (and are able to select to plot) about 30 variables. I can't see how this would be practical/intuitive using just a big table of database entries that change with every timestep. Can't you do the plotting in a separate process or thread, maybe even with some message passing, to isolate the acquisition? Maybe it can also be a plugin that you can exchange if needed or not use.

[MatthieuDartiailh]

• bullet 2: if through user experience we can define some good generic default task then yes they could be included but I lacked time to port cleanly some part of HQCMeas, hence the legacy stuff that is supposed to go away sometimes in the future (distant).
• bullet 3: agree I will try to improve on this
• bullet 4: actually without this package the lab would not run. Once cleaned up it may become the lab extension package.
• bullet 5: this needs to be clarified in the docs. Basically the {} syntax allow you to access any value stored by a task and once you open a { you get auto-completion. The only entries you cannot access are the one created in a ComplexTask (Loop for example) if you are outside that loop.
• bullet 6: I will try to think about getting rid of the template syntax
• bullet 7: You could easily use any instrument package, the one key difficulty is that you would need task to cooperate with the drivers. Let's say that you have a voltage source with a voltage attribute it would work out of the box with the SetDCVoltage task in the legacy package.
• bullet 8: in an ideal world I would love to exchange with a server responsible for saving the data and with whom a plotting system could interact. Otherwise it is possible to define monitors exchanging with the measurement process. As I said, I never took the time to implement such a feature because we have an old system simply polling textfiles to do the live plotting.

[bilderbuchi]

Thanks for clarifying this!