Closed WilliamHPNielsen closed 5 years ago
I am looking into this. @WilliamHPNielsen would you agree that this is an issue with the qcodes parameter rather than with the StationConfigurator
? The station configurator sets the scale correctly. The same behavior is observed here:
from qcodes.tests.instrument_mocks import DummyInstrument
d = DummyInstrument(gates=['ch1', 'ch2'])
d.ch1.scale = 0.001
d.ch1(500)
Thinking twice about it I am inclined to say that it is probably a matter of taste. I feel that the current implementation is correct: you define a scale for a parameter and the validation takes place on the unscaled value (think about a device that takes mV but you want to define the parameter in V, here you would want to define the limits/validator also in terms of volts)
Now in the presented use case the user probably wants to introduce a new parameter with a different unit and scaling as the original instrument parameter. For this reason I introduced the DelegateParameter
as a 'proxy'. The delegate parameter has its own scaling and now you can set a limit to the unscaled value on the instrument and to the scaled value of the proxy.
The corresponding yaml file would be:
instruments:
dummy:
driver: qcodes.tests.instrument_mocks
type: DummyInstrument
init:
gates: ['ch1', 'ch2']
enable_forced_reconnect: true
add_parameters:
mygate_mV:
source: ch1
scale: 0.001
unit: mV
@WilliamHPNielsen I can see this is a bit confusing. I appreciate any help in changing the syntax/naming to make this more obvious.
would you agree that this is an issue with the qcodes parameter rather than with the
StationConfigurator
?
I am not sure. I think the QCoDeS parameter does the correct thing and punishes you for forgetting about validation when scaling. I am not sure that the StationConfigurator - living at a higher level - should act the same way. I think it's fair to say that parameters are primarily designed for use in drivers (i.e. to be used "statically"), so when adding them dynamically, some extra care is called for.
I see that I was just using the wrong "command", which is a big relief. So perhaps this is just a question about documentation/training? It's not so clear to me why anyone would ever prefer parameters
over new_parameters
... Perhaps you can explain the intended use cases for each?
I agree. The reason the StationConfigurator does this, is that it was supposed to be a thin wrapper. Now the add_parameters
became somehow thicker because it was oriented towards the actual use case.
Do you have any suggestion for where to put the documentation to make this more clear?
Hmm... I am tempted to go down a road of warning users when using scale
with parameters
if the scaled parameter has a validator (with an extra yaml option to silence that warning, kind of i_know_what_im_doing: true
), but that will probably be a bit too much.
Since this use case of wanting to rescale something to mV
is quite common, a fine solution for now is probably to add this as an example in the (otherwise splendid) https://github.com/qdev-dk/qdev-wrappers/blob/master/examples/station_configurator/exampleConfig.yaml and perhaps write one or two lines about how scale
and limits
work together when using add_parameter
.
documentation has been added.
As seen in the lab:
When creating a new parameter that is a scaled version of an existing parameter, the validation of the new parameter's values does not correctly match the scaling. As an example, we consider the
DummyInstrument
. We recall that the "gates" by default have validators<Numbers -800<=v<=400>
.Now, in python
if we set
dummy.mygate(500)
, we get aValueError
that the value is out of bounds, although this would correspond to only 0.5 volts on the instrument. Similarly, if we had scaled the value up in the yaml file, we would now be allowed to exceed the safety range defined by the instrument driver.@Dominik-Vogel