Skip to content
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

Faster qdac (#53) #730

Merged
merged 6 commits into from
Sep 13, 2017
Merged

Conversation

jenshnielsen
Copy link
Collaborator

  • add support for faster setting of qdac voltage
  • add option to qdac to ignore return read on voltage set
  • SR830 fail early in buffered readout if butffer is not full as expected

@WilliamHPNielsen

* add support for faster setting of qdac voltage

* SR830 fail early in buffered readout if butffer is not full as expected

* add option to qdac to ignore return read on voltage set

This ivery experimental and likely to break if you are not careful
@@ -553,7 +570,8 @@ def write(self, cmd):

nr_bytes_written, ret_code = self.visa_handle.write(cmd)
self.check_error(ret_code)
self._write_response = self.visa_handle.read()
if not fast:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens to the response if fast? Isn't it still in some output queue of the QDac?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this in general is a bad idea but they wanted it. Hence off by default and the warning in the doc string

@@ -108,7 +108,8 @@ def get(self):
# parse it
realdata = np.fromstring(rawdata, dtype='<i2')
numbers = realdata[::2]*2.0**(realdata[1::2]-124)

if self.shape[0] != N:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a good precaution (and I guess it's indeed related to fast measurements with the QDac), but shouldn't it be a separate PR?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it should but the commits have already been squashed because its a backport and I don't really see the point of splitting them

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair enough.

jenshnielsen and others added 2 commits September 11, 2017 10:44
This has too many potential issues and may result in crashes
Copy link
Contributor

@WilliamHPNielsen WilliamHPNielsen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A good choice, in my opinion. I think the other changes are fine.

@jenshnielsen
Copy link
Collaborator Author

Need to implement this for the channel version too

@jenshnielsen
Copy link
Collaborator Author

Should be ready now

@@ -553,7 +562,6 @@ def write(self, cmd):

nr_bytes_written, ret_code = self.visa_handle.write(cmd)
self.check_error(ret_code)
self._write_response = self.visa_handle.read()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woops! We need to still get the _write_response.

Copy link
Contributor

@WilliamHPNielsen WilliamHPNielsen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Super!

@jenshnielsen
Copy link
Collaborator Author

We could do this in a smarter way perhaps.

Concatenate the two write commands and then:
Make write take an optional number of newlines to read back and either

  • Read n times at the end of write
  • Temporary change the termination to m * \n where m is the number of commands written.

I suspect that the first method may be solver but without benchmarking it's hard to know.

@WilliamHPNielsen WilliamHPNielsen merged commit 41ce6d8 into microsoft:master Sep 13, 2017
@jenshnielsen jenshnielsen deleted the faster_qdac branch September 13, 2017 12:35
giulioungaretti pushed a commit that referenced this pull request Sep 13, 2017
Author: Jens Hedegaard Nielsen <jenshnielsen@gmail.com>

    Faster qdac (#53) (#730)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants