[BUG] - Session disconnect is not working properly

[YuanG13]

Describe the bug
A clear and concise description of what the bug is.
if you create a session, and do

session.connect()
session.disconnect()
session.connect()

you will get an error

LabOneQControllerException: Exception ZIAPIServerException with status code: 32789 - Device is already connected to a different server. Extended information: Device 'DEV8755' is already in use with status: In use by xxx.xxx.xx.xxx. when calling method connectDevice with ('dev8755', '1gbe') and {}

I think the session does not disconnect properly after release laboneq 2.4. The name of the function disconnect should mean the devices are completely disable the connection.

To Reproduce
Steps to reproduce the behavior:

1. Define pulse sequence...
2. Execute on hardware / in emulation ...
3. Do additional steps...
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Code & Screenshots
If possible, add example code or serialized LabOne Q data objects, like the Experiment and DeviceSetup, that allow us to reproduce the behavior.
If applicable, add screenshots to help explain your problem.

Versions used:

• laboneq 2.4
• zhinst-core
• others

Context

• Do you know a workaround for the issue? If yes, please provide a short description.
• Does the issue block your experiments?

[YuanG13]

2023.06.21 19:38:13.327 laboneq.controller.controller INFO VERSION: laboneq 2.4.0
2023.06.21 19:38:13.329 laboneq.controller.devices.device_collection INFO Connecting to data server at xxx.xxx.xx.xxx:xxxx
2023.06.21 19:38:13.613 laboneq.controller.communication INFO Connected to Zurich Instruments LabOne Data Server version 23.02 at xxx.xxx.xx.xxx:xxxx
2023.06.21 19:38:24.397 laboneq.controller.devices.device_collection INFO Configuring device setup
2023.06.21 19:38:25.516 laboneq.controller.devices.device_collection INFO Device setup configured
2023.06.21 19:38:25.929 laboneq.controller.controller INFO Shutting down all devices...
2023.06.21 19:38:25.930 laboneq.controller.controller INFO Successfully Shut down all devices.
2023.06.21 19:38:25.930 laboneq.controller.controller INFO Disconnecting from all devices and servers...
2023.06.21 19:38:27.058 laboneq.controller.controller INFO Successfully disconnected from all devices and servers.
2023.06.21 19:38:27.146 laboneq.controller.controller INFO VERSION: laboneq 2.4.0
2023.06.21 19:38:27.147 laboneq.controller.devices.device_collection INFO Connecting to data server at xxx.xxx.xx.xxx:xxxx
2023.06.21 19:38:27.368 laboneq.controller.communication INFO Connected to Zurich Instruments LabOne Data Server version 23.02 at xxx.xxx.xx.xxx:xxxx
2023.06.21 19:38:27.460 laboneq.controller.util CRITICAL Exception ZIAPIServerException with status code: 32789 - Device is already connected to a different server. Extended information: Device 'DEV8755' is already in use with status: In use by 192.168.21.246. when calling method connectDevice with ('dev8755', '1gbe') and {}

[QuantumClemens]

Hi @YuanG13 ,
thanks for reporting this, we will look into it.

[YuanG13]

It turns out that it needs around 2s sleep time between disconnect and connect. I would suggest disconnect release the thread after it fully disconnect. But cannot confirm whether the wait time depends on scale of the device setup or not.

[QuantumClemens]

Hi @YuanG13 ,
thanks for the additional information - we are looking into this and are investigating if this need a change in the low-level API used to communicate to the instruments or how we can solve it on our side. We will be in touch when we know more.
To help us understand, can you give us more detail why you are using the session.disconnect() here, i.e. why do you need to disconnect the dataserver connection and then reconnect again?

[YuanG13]

the second session is actually with different device setup on the same devices.

[QuantumClemens]

So the device setup assigned to the second session has different connections / logical signals / qubits for each device?
cc @ThomasSoini

[YuanG13]

I think the physical connections would be identical, but could contain only part of the rack or have different logicals channels for devices. In our case, we were changing logical signals for some of the qubits. In our backend, we try to reuse the session as much as possible until it needs a different DeviceSetup, and we do session_old.disconnect and session_new.connect

[YuanG13]

Further issue:
two different machines A B.

1. run a experiment on A and keep the old_session/thread.
2. run a experiment on B, the experiment will be successful.
3. run again a experiment on A with the same old_session
4. experiment runs and return an error number of measurement points 0 returned by daq from device 'SHFQA:dev12212' does not match length of recipe measurement_map which is 201

[QianmuZI]

Hello @YuanG13, as discussed, this issue is resolve and we close the ticket.