New "Configuration Parameter"

[AdriaanRol]

Based on a discussion with @damazter I would like to put forward the concept of a configuration parameter.

What is a configuration parameter?

• Behaves like a manual parameter but if it gets set changes flag _configure_required to True.
• Some other parameters call a configure() method whenever _configure_required==True.

What problem does this solve?

• Some instruments require configuration before a measurement can be started. Examples include the ATS driver and the Signal Hound. The configure command usually uses a set of parameters to at once upload/set some configuration.
• The configuration parameter allows interacting with all parameters of the instrument as if they are normal parameters while simultaneously ensuring that the instrument gets reconfigured whenever required.

I think this is a sufficiently common problem that it warrants a new parameter class. The current instruments that need it both have a different solution.

The signal hound driver solves this problem by using manual parameters and the requiring the user to call the configure command by hand. The ill documentation of this functionality, combined with the missing of a simple getable parameter that represents a measurement (based on my shoddy port of an existing qtlab driver) is what initiated this discussion.

The ATS driver solves this problem by introducing an unsetable AlazarParameter that can only be changed using either the private method or the configure command.

I would argue that the concept of a configuration parameter is the prefered solution to this problem. However, I explicitly put this forward as a point of discussion as introducing a new concept must not be done lightly.

( @giulioungaretti, Probably intentional but I am no longer able to apply labels to issues, would make it easier to structure things a bit.)

P.S. as this issue was motivated by the low quality of a driver that I ported this raises a separate issue as to who will work on improving existing drivers, maybe an interesting subject for a discussion on Slack.

[giulioungaretti]

@AdriaanRol in terms of who will improve existing drivers, I think the answer is pretty boring: those who use them. In general it's hard to improve them without "feeling" the limitations they have.
This does not exclude asking for help / suggestions!

As for the configuration parameter, I kind of see what you mean but need to think about it a bit more!
Somehow I feel like this flag should be at driver level (as in some class attribute) rather than a parameter. But idk yet.

[AdriaanRol]

@giulioungaretti , It indeed makes sense to somehow link this to the driver. However seeing as this is a problem that is quite general (and will certainly show up more times) I don't think it makes sense to lock it in the inheritance structure of the instrument classes.

That being said. Let me know when you've given it some more thought.

[WilliamHPNielsen]

@AdriaanRol We have now thought about this issue in the sense that we encountered the same situation in some drivers we wrote. For instance, the ZI UHF-LI sweeper needs to be configured (sweep start, sweep stop, number of points, filter bandwidth, etc.) before the get method of the sweeper parameter can be called without raising an exception. This is, as you pointed out, a quite general situation and always (but not limited to) the case for non-scalar parameters. The way we solve it is by having a boolean class attribute called something like sweep_correctly_configured. All relevant parameters then falsify that boolean in their set methods and some sweep.build_sweep() method must be called to set it back to True (and actually send the configurations to the instrument). This seems similar to the signal hound solution, which I personaly think is a fine way of doing things.

Have you yourself thought more about this in the meantime? I don't really see the advantage of promoting this bookkeeping to the instrument class. What would the benefit be over what we can call the signal hound approach?