The distance between the two pi/2 pulses is not equal to the sequence duration parameters.

Moreover, the distance gets longer when adding pi pulses to the sequence.

Is this the intended behavior?

One of our students has discovered what appears to be semantic error in the Keysight_6000X_Scope.py code while attempting to run the driver.

Lines 35–37 refer to sData, which is not actually initialised until line 39. I managed to fix the code semantics by deducing that what was intended was to refer to sHead0 (which presumably contains metadata of sorts).

That sorts out the semantic errors; however, I am not going to submit a PR just yet as we are still working through some deeper issues with timeouts when reading data through the driver in line 39 (granted, we are using a 2000 Series and not a 6000X, but I would not expect the fundamental functions to be very different). These issues may partially be due to the fact that there may be some remnants of the LeCroy scope driver that this driver was based on (as evidenced by the unchanged driver class docstring!).

Will update once we have more info.

Hi,

As far as I understand from the code and the tooltips, the "match main sequence waveform size" option in the "Readout" section is supposed to only change the number of points of the readout waveform to be identical to that of the main qubit pulse waveforms.

However, it seems to me that the start time of the readout pulse is affected by this option.
I think this is due to the control flow in part of the sequency.py ,

                # get the range of indices in use
                if (pulse.pulse_type == PulseType.READOUT and not
                        self.readout_match_main_size):
                    # special case for readout if not matching main wave size
                    start = 0.0
                    middle = self._round(step.t_middle - step.t_start)
                    end = self._round(step.t_end - step.t_start)

resetting the start time of the readout pulse to zero when this option is unchecked. Is it supposed to be like this? I'm confused about what this option is supposed to do.

I think it's easier to work when the start of the readout pulse aligned to the end of all the qubit pulses by default but I don't think the option "match main sequence waveform size" describes that at all.

This is another issue, but the alignment behavior of readout pulse when the option "match main sequence waveform size" is checked seems to be unaffected by the delay of XY and Z pulses that we can specify in the "Waveform" section of GUI. I think this is an additional inconsistency which needs to be addressed. I know this is due to the part

                elif pulse.pulse_type == PulseType.READOUT:
                    waveform = self.readout_iq
                    delay = 0

in the sequence.py setting delay of the readout pulse to be unaffected by neither xy nor z pulse delays.

Thanks in advance,
Eunjong

A recent commit #33be3bb deleted the Keysight FPGA Demod. Was this on purpose? If so what should we be using instead?

Description:

The Lab Brick LMS Synthesizer Labber driver appears, at first sight, to be compatible with the newest 64bit vnx_fmsynth.dll available on the Vaunix website as long as the "Run in 32bit mode" flag is set to False.

However, random "silent crashes" can happen in this situation, with the source behaving erratically even though everything looks fine within the instrument server. E.g. there can be a wrong output state, frequency or power depending on the situation, but Labber behaves as if all was fine.

For reference, this "silent crashes" situation occurs with the 64bit vnx_fmsynth.dll found in the "LMS Win64 SDK 6-16-18_v1.zip" archive obtained through Vaunix's support. The md5 checksum of the tested version of the dll is 6ac4a10bee16422cb4ba830f29c992fe.

Reproducing the issue:

To reproduce the issue, one can simply launch a lot of measurements in quick succession via Labber or manually spam the device with commands by loading the provided python interface like this (where 12345 is the device id of the source):

import LabBrick_LMS_Wrapper as LB
labbrick = LB.LabBrick_Synthesizer()
labbrick.initDevice(12345)
 
i=0
while True:
    print("Iteration:,", i)
    i = i+1
    try:
        labbrick.setRFOn(False)
        labbrick.setFrequency(6e9)
        labbrick.getRFOn()
        labbrick.getFrequency()
        labbrick.setRFOn(True)
        labbrick.setFrequency(4.5e9)
        labbrick.getRFOn()
        labbrick.getFrequency()
    except:
        labbrick.setFrequency(3e9)
        labbrick.setRFOn(True)
        labbrick.closeDevice()

The source is typically crashed after a few thousand iterations.

A proper fix would most likely only involve this LabBrick_LMS_Wrapper.py wrapper.

Workaround:

Loading an older driver in 32bit mode is a viable workaround until the issue is fixed.
For reference, the 32bit version of vnx_fmsynth.dll found in the "LMS Win32 ANSI SDK 6-16-18_v1.zip" archive obtained through Vaunix's support, with md5 checksum eb59aaf900c14a8f806242d59b6a4df8, seems to be stable using the code snippet provided above.

However, as newer driver normally come with bug fixes, new features, and improved stability, it'd be ideal to have proper support for the newest 64bit drivers.

Edit:

It turns out that the Labber driver still crashes using the 32bit Vaunix DLL, but it seems to happen less often.

The second bug is that I can not set the Trace from the multi-qubit pulse generator as the Source of the AWG in Signal connections. Even though I have added that generator in the Measurement Editor, run it, add the Trace - I1 in the Channels, when I double click Ch1 of the AWG in Signal connections, Trace - I1 doesn't appear in the list of Source signals.

Hello,
I have an issue to control keysight pxi awg in linux OS.
In your folder, I think it is usable in Windows system because you requires the SDcore1.dll and .py files. I also notice that the files can be generated after installing the keysight program in Windows OS.
But I would like to know

1. whether it can be used directly in linux
2. ways to control the instrument in linux

Thank you for your help!

Probably some labber python API files (such as 'VISA_Driver.pyc' under labber\python-labber\multiproc-include\py37) should be updated to work with newer versions of pyvisa. I guess in 'VISA_Driver.pyc', it still uses the command 'imports visa' to load the pyvisa module, and this causes some 'import visa' error when using a newer version of pyvisa. Since pyvisa 1.6, the importing command of pyvisa is not 'import visa' anymore, it banned the use of 'visa' in order to avoid conflict with other python packages with the same name 'visa', instead, we have to use 'import pyvisa' or 'import pyvisa as visa' instead.

Dear,

This is not a question regarding the drivers, but to the Labber python software installation. My python version and the Labber package seem to be inconsistent with each other. I have tried many ways of installing, but none of them works. What generally happens is that I cannot install the Labber package in a certain conda environment, but only globally. Because of that, my Spyder somehow does not open anymore. I prefer Spyder to Jupyter notebook, but Jupyter does open when the Labber package is installed. However, in Jupyter, the Labber package is never found.

Basically, do you have any experience with this installation issue? Or do you now someone in the Labber organization who does? I need to have access to the Labber package to analyze the data from the Keysight Agilent Multimeter.

Best,
Thijs de Gijsel

I want to set the Sequence in the Measurement Editor by double click that item, but when I try to set a new value for it, there is an error as follows:

12:55:17,329: An error occurred when sending a value to an instrument.

Instrument name: Simon's Multi-Qubit Pulse Generator (Simon's Multi-Qubit Pulse Generator)
Address:
Quantity: Sequence
Value: Pulse train

Error message:
2

Unfiltered error message:
Traceback (most recent call last):
File "BaseDriver.py", line 458, in processOperation
File "BaseDriver.py", line 491, in performOperation
File "BaseDriver.py", line 756, in _performSetValue
File "E:\GitHubRepositories\labber-drivers\MultiQubit_PulseGenerator\MultiQubit_PulseGenerator.py", line 45, in performSetValue
new_type = SEQUENCES[value]
KeyError: 2

Do you know what's going on?

At the moment, the DRAG scaling parameter needs to be some very small number to get a resonable amplitude. E.g, if I set that parameter to 1, the amplitude of the derivative channel is in the 1e7 range.
I suggest that DRAG scaling=1 should equal the same amplitude of the Gaussian and the derivative channels.

Is it possible to develop a Labber "driver" that utilizes stdin/stdout pipe automation interface for other applications on the system rather than direct VISA comms to a physical instrument? My company's apps expose the automation interface and handle all the low-level instruments comms themselves -- we don't need to reinvent the wheel inside of Labber to do higher-level tasking with our system (which includes multiple instruments).

I know I can use Python to do such pipe communications -- the question is whether this could be supported as an "instrument" within Labber?

When defining a Gaussian pulse with either the single or the multi qubit pulse generator, the pulse does not start at zero.

This leads to extra spectral content in the pulses, unless you use a large truncation range.

I suggest to subtract the minimum value from the pulse after truncation and then rescale the amplitude to achieve the desired amplitude. I'm happy to implement this myself if you agree that this is a good idea.