Add trigger, and program feature to Yokogawa GS200, and digitizer feature to Keithley 7510

[liangosc]

First of all, this PR includes changes to two instruments.

The reason why I want to include two changes in one:
The changes made to the Yokogawa GS200 will add the ability of programming source data pattern, and sending out external triggers. Hence, it'll be great if I can measure the pattern with a dmm which can receive the trigger.

The changes made to the Keithley 7510 will add the ability of receiving external trigger, and performing a "digitize" measurement, which is ideal for high speed measurement.

It feels "incomplete" if I include the new changes to each instrument in its existing QCoDeS example, so I combine two together in this one PR, with one new example notebook, but I can always split this PR into two separate ones if necessary.

Changes proposed in this pull request:

For the Yokogawa GS200:

• A "GS200_Program" class is added, so that the user can program the source data pattern. Each step in the program is executed in order, and each step has a fixed execution time. User can also set the slope time, and generate step responses, ramp responses, and various waveforms such as triangular waveforms.
• BNC trigger in and out are added as parameters.

For the Keithley 7510:

• The "Buffer" class is added, same as the one for Keithley 2450, and several related parameter/methods are also added to the driver.
• A new "DigitizeSense" class is added. The digitize sense function is similar to the normal sense, but has some of its own method. In other words, the "digitize sense" and "sense" each has some unique methods, so I decided to make a new class, instead of subclass the "Sense" class.

@sohailc

[codecov]

Codecov Report

Merging #2138 into master will decrease coverage by 0.13%.
The diff coverage is 55.23%.

@@            Coverage Diff             @@
##           master    #2138      +/-   ##
==========================================
- Coverage   71.74%   71.60%   -0.14%     
==========================================
  Files         156      156              
  Lines       20749    20919     +170     
==========================================
+ Hits        14886    14979      +93     
- Misses       5863     5940      +77     

[jenshnielsen]

There does not seem to be an example of reading the buffer into a qcodes parameter. Is this supported? It is an esential feature for a qcodes driver to be able to capture the data as a parameter so it can be storred in a dataset easily

[liangosc]

There does not seem to be an example of reading the buffer into a qcodes parameter. Is this supported? It is an esential feature for a qcodes driver to be able to capture the data as a parameter so it can be storred in a dataset easily

I have made data a parameter, and the usage is as following:

buffer.data_start = 1
buffer.data_end = total_data_points
v=buffer.data()

the type of v is a list, with float-type elements.

User can specify several different elements, such as time, measurement, unit...

buffer.elements(['measurement', 'time', 'measurement_unit'])
data=buffer.data()

In this case, the data will be a 3xN matrix/array, of which all the elements are str-type.

I didn't add the vals=Arrays(...) nor the parameter_class, for the data parameter, because:

1. the shape of the data is not fixed, it depends on how many elements the user wants;
2. the parameter_class=... part can only be added if there is the vals=Arrays(..)
   suggestion? @jenshnielsen

(Maybe I can just save everything -- all total 14 elements)

[jenshnielsen]

Why is self.buffer_name needed. It seems like this will always be equivalent to self.short_name which is already defined on all instruments

[liangosc]

It turns out self.short_name works. (not self.name though)

I was not sure if I should use self.name or self.short_name, so I created my own... :D

[jenshnielsen]

(Maybe I can just save everything -- all total 14 elements)

I think you can set this up dynamically from the parameters that determine the size. Have a look at
https://qcodes.github.io/Qcodes/examples/Parameters/Simple-Example-of-ParameterWithSetpoints.html?highlight=parameterwithsetpoints and see if it is possible to do something similar to the parameter with setpoints

EDIT:

It would be nice to have it as a ParameterWithSetpoints so that one can register what setpoints the axes corresponds to

[liangosc]

(Maybe I can just save everything -- all total 14 elements)

I think you can set this up dynamically from the parameters that determine the size. Have a look at
https://qcodes.github.io/Qcodes/examples/Parameters/Simple-Example-of-ParameterWithSetpoints.html?highlight=parameterwithsetpoints and see if it is possible to do something similar to the parameter with setpoints

EDIT:

It would be nice to have it as a ParameterWithSetpoints so that one can register what setpoints the axes corresponds to

I tried to match what they did in the example, and here it is...

My concerns:

1. a dummy_setpoints variable is used -- is it necessary?
2. I have to remove the datatype validation because the result may not be Array (it can be list of string values)

All those extra works just to make the data a parameter. Suggestion? @jenshnielsen

[jenshnielsen]

Please rewrite this section so that we only show how to make measurements with qcodes. We do not want to promote manual measurements with this driver that are different from every other driver

[liangosc]

The make measurement section has been rewritten.