-
Notifications
You must be signed in to change notification settings - Fork 315
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
Feature/simulated instruments #859
Feature/simulated instruments #859
Conversation
@QCoDeS/core, I think this is a good time for review. There is now a PyVISA-sim based test for the AMI430 that (as far as I can tell) carefully reproduces the existing test. This is, too me, proof-of-concept that we can indeed use PyVISA-sim for writing driver tests. And the new test is 5 times faster than the old one! 🎉 I know that this PR got kind of really messy, but just disregard all the validation stuff and my OCD-like pep8'ing. The relevant files are: |
Let's give Travis a fair chance to test this
error: ERROR | ||
dialogues: | ||
- q: "*IDN?" | ||
r: "QCoDeS, AMI430_simulation, 1337, 0.0.01" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could think about adding an explicit method to determine whether an instrument is simulated while we keep the idn is identical to the non-simulated instrument. This is in any case necessary for drivers that read the idn to determine their model specific behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can determine whether the instrument is simulated by checking what VISA backend you are using. And you are absolutely right, we sometimes need to write several different simulated instruments per driver with different firmware and/or model numbers.
@QCoDeS/core Okay, save for documentation on how to write simulated instruments, all the above issues should be addressed. |
I have an issue with the device clear function. I get a not implemented errror when I call the constructor of the instrument with the default option device_clear=True.
The instrument is: (lakeshore_model336.yaml)
and the script is:
with the traceback:
I can look into it with more detail if you @WilliamHPNielsen don't know already what is happening |
@Dominik-Vogel I just know what you already discovered; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks good. Left some small inline comments
qcodes/utils/validators.py
Outdated
validate: function of two args: value, context | ||
value is what you're testing | ||
context is a string identifying the caller better | ||
|
||
raises an error (TypeError or ValueError) if the value fails | ||
|
||
valid_values: a property exposing _valid_values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not really a great explanation :)
qcodes/instrument/base.py
Outdated
@@ -190,25 +172,28 @@ def snapshot_base(self, update: bool=False, | |||
try: | |||
snap['parameters'][name] = param.snapshot(update=update) | |||
except: | |||
logging.info("Snapshot: Could not update parameter: {}".format(name)) | |||
logging.info("Snapshot: Could not update parameter:" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you are here could you change this to debug?
qcodes/tests/drivers/test_ami430.py
Outdated
adds in the FieldVector as well. | ||
""" | ||
|
||
print(set_target) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove?
qcodes/tests/drivers/test_ami430.py
Outdated
adds in the FieldVector as well. | ||
""" | ||
|
||
print(set_target) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I think we should remove this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove this
…ielsen/Qcodes into feature/simulated_instruments
update the Creating Instrument Drivers notebook to be correct and to mention simulated instruments
Now there's even documentation. I'll let @Dominik-Vogel answer and then possibly apply the changes he wants. When that's done, I think we should merge this one. |
So will we require all new drivers submitted to include tests? I think we should |
@sohailc IMHO yes at least for visa instruments |
@WilliamHPNielsen regarding the |
@sohailc I agree that it would be great having a test for every instrument driver. And possibly this could be something that we do as main developers. But requiring it generally, I think, is a little bit too strict. We don't want to lose contributors by requiring test. Tests in general are, to my experience, something that nobody without a deeper background in programming is familiar with. Bear in mind, that Delft may be exceptional in that way that there are many highly experienced qcodes users. |
@QCoDeS/core I think this is ready now. |
Author: William H.P. Nielsen <[email protected]> Feature/simulated instruments (#859)
Integrate microsoft#859 changes to ask_raw in VisaInstrument in overriden ask_raw function. Should fix Codacity 'String statement has no effect'warning.
For testing purposes, it would be very useful to be able to instantiate drivers connecting to a simulated instrument rather than a real one. No simulation can (reasonably) be expected to perfectly match the behaviour of a real instrument, but this would still be good to have, as simply seeing whether the driver instantiates can be very helpful in the CI process. As an example things like #849 would be caught.
To test the driver code, it is important to leave that code untouched. We should therefore distinguish between a mock driver and a mock (simulated) instrument. Note that we have a single test that already does this (for AMI430), but with a home-made implementation of a mock instrument. This PR suggests using PyVISA-sim (https://pyvisa-sim.readthedocs.io/en/latest/index.html#) to create simulated instruments to communicate with.
PyVISA-sim is the "correct" solution in the sense that it is a part of PyVISA that we are already heavily using. Non-VISA instruments won't work, but we'll be able to write tests for some 80% - 90% of our drivers, which is a lot more than what we currently have. The simulated instruments are just
.yaml
files, so we may be able to auto-generate them from the QCoDeS parameters in some cases.NB: The current state of this PR is still very much WIP.
Changes proposed in this pull request:
sims
folder with a simulated instrument (dummy.yaml
) and a dummy driver to communicate with it (dummy.py
)VisaInstrument
class to detect that we are using thesim
backendIPToVisa
to allow us to use PyVISA-sim with the AMI430 driverStill pending:
@QCoDeS/core