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
Standford Research SR860 lock-in amplifier driver improvements #1160
Standford Research SR860 lock-in amplifier driver improvements #1160
Conversation
… samples per each trigger signal; a callable argument starts the trigger pulses train - add start_capture_at_trigger that captures a given number of samples once it receives a trigger signal - add parameter for the source of trigger signal - add parameter for the source of reference signal
- capture only the requested number of samples in start_capture_at_trigger, not the full buffer - add min_capture_length_in_kb property - add max_capture_length_in_kb property - make _set_capture_len_parser object method from static method - make _set_capture_len_parser use new capture-length-related properties - make _calc_capture_size_in_kb reuse _set_capture_len_parser - add convenient set_capture_rate_to_maximum method - add convenient _get_list_of_capture_variable_names and reuse it - add convenient _get_number_of_capture_variables and reuse it - remove capture_samples method because it does not make much sense
Codecov Report
@@ Coverage Diff @@
## master #1160 +/- ##
=======================================
Coverage 79.67% 79.67%
=======================================
Files 47 47
Lines 6661 6661
=======================================
Hits 5307 5307
Misses 1354 1354 |
78ee2cb
to
06447a9
Compare
Not-so-useful comment: It would make my editor happy if we could stick to a maximum line length of 79. |
argument to True allows this method to be used as well for set commands of the instrument parameters. | ||
|
||
Args: | ||
capture_length_in_kb (int): The desired capture length in kB. |
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 it is superfluous to write the type down here again. (same for subsequent docstrings)
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.
agree. i will remove it.
capture_len_in_kb (int) | ||
""" | ||
if capture_length_in_kb % 2: | ||
capture_length_in_kb += 1 |
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 don't think it is a good idea to give the user anything else than either exactly what they ask for or a big fat exception. I realise that this is a private method, but I think that principle is still valid.
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 will make it an exception. users will have to be explicit and the driver will be straightforward.
Just for the record, the lock-in itself when given an odd number can convert it to even internally.
""" | ||
return self._parse_capture_length(capture_len_in_kb, issue_warning=True) | ||
|
||
def _parse_capture_length(self, capture_length_in_kb: int, issue_warning: bool=False) -> int: |
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 function has a wrong name; it does not really parse anything. Additionally, I think maybe William is right when he says that the function should return exactly what the user asked (see his comment below). In this case, I think the function should be "validate_capture_length" and should not return anything
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.
@WilliamHPNielsen Yes, this has all been tested on real hardware
- _get_raw_capture_data_block implements the direct low-level call to CAPTUREGET command of the instrument - _get_raw_capture_data allows to get data from the beginning of the buffer avoiding the instrument's 64kB-reading-per-time limit - get_capture_data uses the above functions; it does not have the 64kB limit anymore, instead it's limit is the current capture length (via _get_raw_capture_data function)
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.
Rigorously tested by @astafan8 on the device
- set_capture_length_to_fit_samples - wait_until_samples_captured
… sr860_capture_n_at_trigger
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.
It has been accidentally removed, but now it is back and implemented in a better way rather than "sleeping" for "capture_rate*sample_count" amount of time.
This is more consistent with the names of other methods. It is also a more correct name since the capture is not only started but also stopped within this method.
Before it was not, which resulted in a bug for cases where the capture config had more than one variable, that the function would return before the requested number of samples is acquired.
In "continuous" capture mode, this function does not work at high capture rates because the buffer starts getting overwritten *before* wait_until_samples_captured realizes that enough samples have been captured. This occurs due to the fact that VISA call to capture_bytes in the while in wait_until_samples_captured cannot keep up with the lock-in acquisition speed at high capture rates, hence the data gets "wrapped" (in other words, the buffer gets overwritten) which results in the value returned by capture_bytes to be small again, thus the while loop is not escaped.
It is now up to date with the driver implementation, and covers three popular capture modes.
name | ||
instrument | ||
This argument is unused, but needed because the add_parameter | ||
method of the Instrument base class adds this as a kwarg. |
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 don't understand why the instrument is just not passed to the super method so that the paramter is bound to the instrument. (I realize this is nothing new)
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.
indeed. smth to fix later
The device can actually handle that, so now specifying 1e-6, 5e-9, etc. works without any problems.
An update for the driver for Standford Research lock-in amplifiers SR86x and SR860 in particular. The work is done together with @astafan8.
BUG FIXES:
NEW DRIVER METHODS:
NEW DRIVER PARAMETERS:
EXAMPLE NOTEBOOK UPDATED
Code improvements related to capturing data via the buffer
@jenshnielsen @WilliamHPNielsen @Dominik-Vogel