-
Notifications
You must be signed in to change notification settings - Fork 319
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
feat/channelization: Add channels to instruments #568
Conversation
* feat: Add a Keysight_34465A driver Add a first file for a driver for the Keysight 34465A DMM and a benchmarking notebook * Add trigger parameters to driver Add four trigger parameters to the driver. * refactor: Remove 'READ?' as volt get_cmd Make a more general get_cmd for the volt parameter. Using simply 'READ?' is wrong in many cases. * feat: Add sampling parameters Add four parameters for sampling. * fix: Fix wrong volt parameter get_cmd * WIP: Add Array parameter * feat: Add functioning data buffer parameter * Move notebook * Respond to review
Initial commit of two new classes to allow for channelization of instruments. This includes ChannelList, a container for channels in an instrument, and InstrumentChannel which implements a base class for an instance of a channel.
Add a driver for the Lakeshore Model 336 temperature controller using new channelization implementation.
Commits a channelized version of the Harvard DecaDAC driver using the new channelization implementation. Note that this driver at the present time also fixes a number of open bugs in the previous driver, including occasional crashes (microsoft#546), incorrectly reading DAC voltages (microsoft#563), reset (microsoft#478). This commit also adds a number of new features to the driver including: - Feature and version detection - Access to calibrated high-resolution mode of DAC - Parameter read from memory - Validation of writes
Fix bug in slicing/adding code, not correctly passing along channel list name.
- Removed useless methods - Whitespace
@spauka looking great. Did not check in super detail but ticks all the boxes! I will tag @MerlinSmiles, since he had strong opinions about this as well! |
@spauka this looks really great! I haven't tested anything on this, but i'm really happy to see this. What does the 0 in
I have one point that I did not see covered. And that is access to the channels in another notation, (the slicing you show is great, but not the only useful way :) One could of course make it on the driver level and define Now im thinking of another syntax also:
|
@MerlinSmiles For each of your points: The 0 in Regarding different ways of addressing channels, agreed, there should be a way of having "named" channels. I suspect that the solution I am working on to store channel metadata will solve this, new commits coming soon. However, I think it also makes sense to keep separate the idea of named and numbered channels, i.e. addressing the DAC as For the last syntax Anyway, let me know whether the below commits address your points... |
@spauka totally agree with you! |
qcodes/instrument/channel.py
Outdated
|
||
self._parent = parent | ||
self._name = name | ||
if not isinstance(chan_type, type) != type or not issubclass(chan_type, InstrumentChannel): |
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.
As far as I can see the first part of this condition will always be True?
not isinstance(chan_type, type) != type -> not bool != type -> not False.
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.
Yep, that's true. Fixed in a future commit :)
I'm happy to help writing some of the tests of anything else if you don't have the time |
@jenshnielsen sorry, got a bit distracted by other projects for the last few weeks but am currently doing work on implementing snapshotting. Any help you can give on tests would be much appreciated. |
Allows certain channel lists to be excluded from snapshots. This is helpful when, for example, there are multiple ways to access the same channel.
This feature is implemented by creating the idea of a submodule in the instrument class. This is just a class which implements the Instrument class, and may be a channel list or may just implement a logical collection of parameters within a parent instrument. For example, looking at the Lakeshore Model_336 driver, each channel can either be accessed as a member of a channel list, or by using the name of the channel: ```python3 therm = Model_336("therm", "...") # These two accesses are equivalent therm.A.temperature() therm.channels[0].temperature() ```
Channel lists should now be snapshotable. This is implemented by creating the concept of a submodule in an instrument, where a submodule is just a class that implements the A side effect of this is that it is now also possible to create sub-instruments, which may be logical groupings of parameters, inside instruments. To see an example of this, see the therm = Model_336("therm", "...")
# The below two lines access the same parameter
therm.A.temperature()
therm.channels[0].temperature()
# The next statement evaluates to true
therm.A == therm.channels[0] |
Should think about the best way to implement this change.
@spauka Great I will start working on some tests |
channels.append(channel) | ||
self.add_submodule(chan_name, channel) | ||
channels.lock() | ||
self.add_submodule("channels", channels) |
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 fails for me with TypeError: Submodules must be subclasses of instrument.
I guess the check in add_submodule
should be a bit more permissive?
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, you are correct, submodules need to be subclasses of Metadatable, Instrument is too restrictive. This is fixed in 4a3e517
Submodule objects must be Metadatables at minimum, instrument is too restrictive for channels.
And error clearly if you try to measure multiple multiparameters
Work in progress support for slicing Array parameters and tests are in https://github.com/jenshnielsen/Qcodes/tree/feat/channelization_with_array Seems to work good but names are currently incorrect for array and multi parameters saved to dataset via loop. (missing channel prefix in names i.e. this and that instead of ChanA_this and ChanA_that and so on |
I pushed some changes to spauka#2 adding support for ArrayParameters |
@WilliamHPNielsen is experimenting on porting the QDac driver |
Add a QDac driver using the new channelisation feature
…array Feat/channelization with array
I added three commits to @jenshnielsen's PR that:
I learned that it could be very de-confusing for some instrument drivers if the channel list could be optionally 1-indexed. |
Make the paramclass returned by __getattr__ be customisable.
Add a channelised driver for the QDac. This requires changing the base code for channels a bit to allow for custom MultiChannelInstrumentParameter subclasses.
…array Driver/QDac_channels
The QDac driver now contains its own subclass of @spauka I think we should merge soon, did you have a chance to look at the Decadac driver? |
PEP8 would be nice, but I think we can merge now. @jenshnielsen ? |
Yes It would be nice to have spauka#2 merged into this before merging I think |
I will merge spauka#2 tomorrow (Sydney time) if that's ok with you all, but
I agree with above, let's lock features here and deal with new additions in
future pull requests.
…On Thu., 15 Jun. 2017, 11:56 pm Jens Hedegaard Nielsen, < ***@***.***> wrote:
Yes It would be nice to have spauka#2
<spauka#2> merged into this before merging
I think
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#568 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAmyvAc_SlfuiEmHh6Ksp9C37UB3DV-Xks5sES3fgaJpZM4M5o7H>
.
|
Add support for array parameters to MultiChannelInstrumentParameter
Implements #273
This merge implements channelization in much the way that was discussed in #273, and commits two sample instruments that demonstrate the key features. Briefly, the syntax allows the creation of lists of channels within an instrument and manipulation of those channels. Examples of usage appear at the bottom of the commit.
Changes proposed in this pull request:
For example:
Things left
@giulioungaretti