Small alazar fixes

[jenshnielsen]

Add real and imaginary part. Remove strange 0 and add some examples

[ThorvaldLarsen]

A couple more comments to the driver.

• When initilising the setup it sometimes freezes when trying to update data parameter for the alazar channels to the station.
• I get this warning anytime I want to take data by calling .data on a channellist: py.warnings - WARNING - C:\Users\t3user\Qcodes\qcodes\instrument\parameter.py:1107: UserWarning: MultiParameters do not support set at this time. warnings.warn('MultiParameters do not support set at this time.')

[ThorvaldLarsen]

Would it be possible to change the name of 'x' and 'y' to either real/imag or I/Q to keep consistent with the lingo in RF demodulation?

[jenshnielsen]

Sure I have no preference

[ThorvaldLarsen]

I have a couple of request:

• Can we make label and unit of the .data parameter depend on demod_type? So that the label will be e.g. Imaginary (V) or Phase (degree) automatically after changing demod_type?
• Would it be possible to include an update to the ATS9360_ext driver, which has the seq_mode parameter, in this PR to reflect the new setup with settings defined in the yaml file instead? Maybe @nataliejpg has an opinion on updating it.
• Getting snapshot update warnings from 0D parameters. Solved by adding snapshot_get=False in the super.init call of Alazar0DParameter. (snapshot_get = False is default for ArrayParameters so there is no problem with AlazarNDParameter.)
• With the current driver I can simultaneously take data from all channels or slices of channels. Is it also possible to take data from an arbitrary set of channels?

[nataliejpg]

an update so that we can still use the seq_mode sounds great. I don't think there is much to have an opinion on other then that it should be implemented ;)

Otherwise all sounds good.

[nataliejpg]

although I would make the argument that we should merge the fixes and make another pull request for the outstanding things because of the *0 bug which it's pretty urgent to get fixed in the master branch (I totally underestimated this which caused a lot of time lost for T2 people and I'm trying to learn my lesson)

[ThorvaldLarsen]

In my list the only critical part is:
Getting snapshot update warnings from 0D parameters. Solved by adding snapshot_get=False as argument in super().init call of Alazar0DParameter.

I agree that the rest can follow in a later PR.

[Dominik-Vogel]

@ThorvaldLarsen can you post or/and explain the warning? I am happy to add this and merge the PR if the warning really does not make any sense in this context and we don't get side effects from setting snapshot_get to false.

[ThorvaldLarsen]

it tries to update alazar_chan.data during the initialization script which it should not be doing. This results in a warning saying that it could not update the snapshot for alazar_chan.data.
Does that explain it? Otherwise we should just quickly meet at T3 and I can show it.

[nataliejpg]

just wondering if there's a reason we haven't merged this yet?

[ThorvaldLarsen]

Yes, the part mentioned in my previous post is not changed yet.

[nataliejpg]

right, my mistake. If it's not going to get fixed in the next week though I would argue for merging and making a separate pr. I can see it's annoying to get warnings but the *0 fix is so important I don't think it should stay out of the main branch for any reason.

[nataliejpg]

@Dominik-Vogel is a fix in the next week feasible? If not what's your opinion on merging already? You have the deciding vote ;)

[ThorvaldLarsen]

This is a 5 min thing. So if we don't have time for that then I assume we dont have to merge either.

[nataliejpg]

5 mins > 1 second

[ThorvaldLarsen]

Well, T2 is open atm so I am sure it can wait a bit longer and then get the changes I requested by my test instead of merging a non-working PR.

[nataliejpg]

I think it's a really important fix that should be merged as soon as possible and that waiting more than another week isn't an option.