Instrument server does not support meta-instruments

[AdriaanRol]

@alexcjohnson , I finally got around to testing the updates to the instruments
Sadly our code does not run with this out of the box, our problems seem to be related to the use of meta-instruments, that is instruments that contain references to other instruments.

AWG = tek.Tektronix_AWG5014(name='AWG', setup_folder=None,
                            address='TCPIP0::192.168.0.9', server_name=None) 

VIP_mon_4_tek = qbt.Tektronix_driven_transmon('VIP_mon_4_tek',
                                              LO=LO,
                                              cw_source=S1, td_source=S2,
                                              IVVI=IVVI,
                                              AWG=AWG,
                                              CBox=CBox, heterodyne_instr=HS,
                                              MC=MC,
                                              server_name=None)

I show just the AWG instrument and the qubit object, all the keyword arguments (expect server_name) that are passed to the qubit object are instances of (physical) instruments.
There are 2 scenarios in which this fails.

1. I do not specify server_name for either.

AWG initializes correctly, qubit object initialization fails with Empty (see all he way below)

2. I specify server_name =None for the qubit object but leave server_name unspecified for AWG

Both instruments initialize correctly but when I try to load and run a sequence from the qubit object I get an exception Empty (see all the way below).

3. I specify server_name = None for both the qubit object, the AWG and the CBox (but not for MW-sources)

All runs fine, I find however that it fails if either the CBox (FPGA used for data acquisition) or the AWG is running on the instrument server it fails (scenario 2) .

For now using instrument_server = None is a suitable workaround as I am still using MeasurementControl instead of the Loop, however I do want to switch as soon as possible and this would be a major showstopper.

As I made some dummy instruments for playing around with the Loop I should also be able to come up with a self-contained example of scenario 1, scenario 2 might be a bit more difficult to find out.

Error logs

Error corresponding to scenario 1

---------------------------------------------------------------------------
Empty                                     Traceback (most recent call last)
<ipython-input-7-27150ba935e0> in <module>()
     26                                     AWG=AWG,
     27                                     rf_RO_source=S1,
---> 28                                     CBox=CBox, heterodyne_instr=HS, MC=MC)#, server_name=None)
     29 gen.load_settings_onto_instrument(VIP_mon_4_tek, label='VIP_mon_4_tek')
     30 VIP_mon_4_tek.pulse_I_channel.set('ch1')

d:\githubrepos\qcodes\qcodes\instrument\base.py in __new__(cls, server_name, *args, **kwargs)
     67         else:
     68             return RemoteInstrument(*args, instrument_class=cls,
---> 69                                     server_name=server_name, **kwargs)
     70 
     71     def __init__(self, name, server_name=None, **kwargs):

d:\githubrepos\qcodes\qcodes\instrument\remote.py in __init__(self, instrument_class, server_name, *args, **kwargs)
     25         manager = get_instrument_server(server_name, shared_kwargs)
     26         # connect sets self.connection
---> 27         manager.connect(self, instrument_class, args, kwargs)
     28 
     29         # bind all the different categories of actions we need

d:\githubrepos\qcodes\qcodes\instrument\server.py in connect(self, remote_instrument, instrument_class, args, kwargs)
     82             conn = InstrumentConnection(
     83                 manager=self, instrument_class=instrument_class,
---> 84                 new_id=new_id, args=args, kwargs=kwargs)
     85 
     86             # save the information to recreate this instrument on the server

d:\githubrepos\qcodes\qcodes\instrument\server.py in __init__(self, manager, instrument_class, new_id, args, kwargs)
    126         # (like visa timeout) to get back to us
    127         info = manager.ask('new', instrument_class, new_id, args, kwargs,
--> 128                            timeout=20)
    129         for k, v in info.items():
    130             setattr(self, k, v)

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in ask(self, timeout, *query)
    332                 if self._error_queue.empty():
    333                     # only raise if we're not about to find a deeper error
--> 334                     raise e
    335             self._check_for_errors(self._expect_error)
    336 

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in ask(self, timeout, *query)
    324 
    325             try:
--> 326                 res = self._check_response(timeout)
    327 
    328                 while not self._response_queue.empty():

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in _check_response(self, timeout)
    301 
    302     def _check_response(self, timeout):
--> 303         res = self._response_queue.get(timeout=timeout)
    304         if res == SERVER_ERR:
    305             self._expect_error = True

C:\Anaconda3\lib\multiprocessing\queues.py in get(self, block, timeout)
    103                     timeout = deadline - time.time()
    104                     if timeout < 0 or not self._poll(timeout):
--> 105                         raise Empty
    106                 elif not self._poll():
    107                     raise Empty

Empty: 

Error corresponding to scenario 2

Starting measurement: Rabi-n1_VIP_mon_4_tek
Sweep function: Rabi
Detector function: CBox_integrated_average_detector
Programming 'Rabi_sequence' (31 element(s))      
d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py:304: FutureWarning: elementwise comparison failed; returning scalar instead, but in the future will perform elementwise comparison
  if res == SERVER_ERR:
---------------------------------------------------------------------------
Empty                                     Traceback (most recent call last)
<ipython-input-3-759e4f6c580f> in <module>()
----> 1 VIP_mon_4_tek.measure_rabi(np.linspace(-.5, .5, 31))

D:\GitHubRepos\PycQED_py3\instrument_drivers\meta_instrument\qubit_objects\Tektronix_driven_transmon.py in measure_rabi(self, amps, n, MC, analyze, close_fig, verbose)
    267         MC.set_sweep_points(amps)
    268         MC.set_detector_function(self.int_avg_det)
--> 269         MC.run('Rabi-n{}'.format(n)+self.msmt_suffix)
    270         if analyze:
    271             ma.Rabi_Analysis(auto=True, close_fig=close_fig)

D:\GitHubRepos\PycQED_py3\modules\measurement\measurement_control.py in run(self, name, mode, **kw)
     55             self.create_experimentaldata_dataset()
     56             if self.mode == '1D':
---> 57                 self.measure()
     58             elif self.mode == '2D':
     59                 self.measure_2D()

D:\GitHubRepos\PycQED_py3\modules\measurement\measurement_control.py in measure(self, *kw)
     76 
     77         for sweep_function in self.sweep_functions:
---> 78             sweep_function.prepare()
     79 
     80         if self.sweep_functions[0].sweep_control == 'soft':

D:\GitHubRepos\PycQED_py3\modules\measurement\awg_sweep_functions.py in prepare(self, **kw)
     26                          pulse_pars=self.pulse_pars,
     27                          RO_pars=self.RO_pars,
---> 28                          n=self.n)
     29 
     30 

D:\GitHubRepos\PycQED_py3\modules\measurement\pulse_sequences\single_qubit_tek_seq_elts.py in Rabi_seq(amps, pulse_pars, RO_pars, n, verbose)
     45         seq.append_element(el, trigger_wait=True)
     46     station.instruments['AWG'].stop()
---> 47     station.pulsar.program_awg(seq, *el_list, verbose=verbose)
     48     return seq_name
     49 

D:\GitHubRepos\PycQED_py3\modules\measurement\waveform_control\pulsar.py in program_awg(self, sequence, *elements, **kw)
    372         time.sleep(.1)
    373         # Waits for AWG to be ready
--> 374         self.AWG.is_awg_ready()
    375 
    376         for channel, offset in offsets.items():

d:\githubrepos\qcodes\qcodes\instrument\remote.py in __call__(self, *args, **kwargs)
    106 class RemoteMethod(RemoteComponent):
    107     def __call__(self, *args, **kwargs):
--> 108         return self._instrument.connection.ask(self.name, *args, **kwargs)
    109 
    110 

d:\githubrepos\qcodes\qcodes\instrument\server.py in ask(self, func_name, *args, **kwargs)
    134         Query the server copy of this instrument, expecting a response
    135         '''
--> 136         return self.manager.ask('ask', self.id, func_name, args, kwargs)
    137 
    138     def write(self, func_name, *args, **kwargs):

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in ask(self, timeout, *query)
    332                 if self._error_queue.empty():
    333                     # only raise if we're not about to find a deeper error
--> 334                     raise e
    335             self._check_for_errors(self._expect_error)
    336 

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in ask(self, timeout, *query)
    324 
    325             try:
--> 326                 res = self._check_response(timeout)
    327 
    328                 while not self._response_queue.empty():

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in _check_response(self, timeout)
    301 
    302     def _check_response(self, timeout):
--> 303         res = self._response_queue.get(timeout=timeout)
    304         if res == SERVER_ERR:
    305             self._expect_error = True

C:\Anaconda3\lib\multiprocessing\queues.py in get(self, block, timeout)
    103                     timeout = deadline - time.time()
    104                     if timeout < 0 or not self._poll(timeout):
--> 105                         raise Empty
    106                 elif not self._poll():
    107                     raise Empty

Empty: ```

[alexcjohnson]

This is what shared_kwargs class attribute is for - in short, any object an instrument needs that you can't send through a queue, you must provide to the InstrumentServer on its initialization. So in this case you need to ensure:

1. ALL of the physical instruments are running on servers, so that all you need to share is RemoteInstrument objects
2. all of these are in shared_kwargs in the Tektronix_driven_transmon definition (MockInstrument does this now with model):

class Tektronix_driven_transmon:
    shared_kwargs=['LO', 'cw_source', 'td_source', 'IVVI', 'AWG', 'CBox', 'heterodyne_instr', 'MC']
   ...

3. when you instantiate the Tektronix_driven_transmon, provide all of these as kwargs. (we should be able to relax this requirement later... see https://github.com/qdev-dk/Qcodes/issues/83#issuecomment-214872250)

That's what I think the answer should be anyway... I'm not quite sure why you're getting the errors you are, but hopefully when I get to #83 and make better error messages it will catch this case.

[AdriaanRol]

@alexcjohnson , I tried to implement the fix you proposed but I get the following error (see below)

It complains about a non-pickleable command in our CBox driver, namely a function that generates a channel specific get function.

    def _gen_signal_threshold_get_func(self, line):
        def get_sig_threshold_i():
            return self._get_signal_threshold(line)
        return get_sig_threshold_i

This specific example is something we have manual parameters for now but the pickleability constraint does seem quite severe, I know that the same construction is used in the IVVI driver and if I change my driver here it will just pop up there, where I cannot solve it easily.

Data directory set to: D:\Experiments/Simultaneous_Driving/Data
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-6-27150ba935e0> in <module>()
     26                                     AWG=AWG,
     27                                     rf_RO_source=S1,
---> 28                                     CBox=CBox, heterodyne_instr=HS, MC=MC)#, server_name=None)
     29 gen.load_settings_onto_instrument(VIP_mon_4_tek, label='VIP_mon_4_tek')
     30 VIP_mon_4_tek.pulse_I_channel.set('ch1')

d:\githubrepos\qcodes\qcodes\instrument\base.py in __new__(cls, server_name, *args, **kwargs)
     68         else:
     69             return RemoteInstrument(*args, instrument_class=cls,
---> 70                                     server_name=server_name, **kwargs)
     71 
     72     def __init__(self, name, server_name=None, **kwargs):

d:\githubrepos\qcodes\qcodes\instrument\remote.py in __init__(self, instrument_class, server_name, *args, **kwargs)
     23                 del kwargs[kwname]
     24 
---> 25         manager = get_instrument_server(server_name, shared_kwargs)
     26         # connect sets self.connection
     27         manager.connect(self, instrument_class, args, kwargs)

d:\githubrepos\qcodes\qcodes\instrument\server.py in get_instrument_server(server_name, shared_kwargs)
     38                               ).format(server_name))
     39     else:
---> 40         manager = InstrumentManager(server_name, shared_kwargs)
     41 
     42     return manager

d:\githubrepos\qcodes\qcodes\instrument\server.py in __init__(self, name, shared_kwargs)
     63 
     64         super().__init__(name=name, server_class=InstrumentServer,
---> 65                          shared_attrs=shared_kwargs)
     66 
     67     def restart(self):

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in __init__(self, name, server_class, shared_attrs, query_timeout)
    250 
    251         self.query_timeout = query_timeout
--> 252         self._start_server()
    253 
    254     def _start_server(self):

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in _start_server(self)
    254     def _start_server(self):
    255         self._server = QcodesProcess(target=self._run_server, name=self.name)
--> 256         self._server.start()
    257 
    258     def _run_server(self):

C:\Anaconda3\lib\multiprocessing\process.py in start(self)
    103                'daemonic processes are not allowed to have children'
    104         _cleanup()
--> 105         self._popen = self._Popen(self)
    106         self._sentinel = self._popen.sentinel
    107         _children.add(self)

C:\Anaconda3\lib\multiprocessing\context.py in _Popen(process_obj)
    210     @staticmethod
    211     def _Popen(process_obj):
--> 212         return _default_context.get_context().Process._Popen(process_obj)
    213 
    214 class DefaultContext(BaseContext):

C:\Anaconda3\lib\multiprocessing\context.py in _Popen(process_obj)
    311         def _Popen(process_obj):
    312             from .popen_spawn_win32 import Popen
--> 313             return Popen(process_obj)
    314 
    315     class SpawnContext(BaseContext):

C:\Anaconda3\lib\multiprocessing\popen_spawn_win32.py in __init__(self, process_obj)
     64             try:
     65                 reduction.dump(prep_data, to_child)
---> 66                 reduction.dump(process_obj, to_child)
     67             finally:
     68                 context.set_spawning_popen(None)

C:\Anaconda3\lib\multiprocessing\reduction.py in dump(obj, file, protocol)
     57 def dump(obj, file, protocol=None):
     58     '''Replacement for pickle.dump() using ForkingPickler.'''
---> 59     ForkingPickler(file, protocol).dump(obj)
     60 
     61 #

AttributeError: Can't pickle local object 'QuTech_ControlBox._gen_signal_threshold_set_func.<locals>.set_sig_threshold_i'

[alexcjohnson]

It complains about a non-pickleable command in our CBox driver

Wait, why is it trying to pickle a QuTech_ControlBox? Shouldn't it pickle the RemoteInstrument that points to this?

[AdriaanRol]

Shouldn't it pickle the RemoteInstrument that points to this?

@alexcjohnson , my first reaction is it should. I realised however that it does not do that because I made the instrument not run on any server (because of the bug that occurs in scenario 3).

Let me retry with all the instruments as shared kwargs and everything running on a server. Also the issue #120 makes it cumbersome to test these things as I find myself restarting the notebook server all the time.

@damazter suggested to me that things might look better if I try to set all instruments at the same instrument server instead of having them scattered over the GPIB, VISA and SERIAL servers. It occured to me that I have no good understanding of how the server implementation works. @alexcjohnson Would it be possible to do a similar FAQ addition as what you did in #118 for the use of servers? Things I would like to know are when do I want to use no server at all (I now have the impression that is incompatible with Loop but I may be wrong), what are (are there any) constraints on instruments? What's the deal with shared kwargs etc.

I'll get back to you on testing this.

[AdriaanRol]

@alexcjohnson , Ok, looks like we are one step further. If I set all instruments to reside on the instrument server (using server_name='') I get the following error (see below). In this case it is not complaining about not being able to pickle the CBox (if I set server_name=None on the CBox that will reappear, so I would say that that problem is reproducible and understood).

The thing it is now complaining about is that the shared kwargs are not identical. Note that I have added the shared_kwargs argument to the instrument driver.

In the case of the Lutman I use the following code to initialize it

LutMan = lm.QuTech_ControlBox_LookuptableManager('LutMan', CBox=CBox,
                                                 server_name='')

With

class QuTech_ControlBox_LookuptableManager(Instrument):
    '''
    '''
    shared_kwargs = ['CBox']

    def __init__(self, name, CBox, **kw):

The abvious direct solution to this bug would be to make sure that all the shared_kwargs of all instruments in the instrument server are identical. However I do not see the best way to do this as it would involve editing instrument drivers that are supposed to be independent, I think it would make more sense to solve this problem by setting the shared kwargs in the instrument server and appending more if more get added, however I do not understand the internals of that well enough.

I'll try to come up with a self contained example using mock instruments, I'll need to build those anyway for testing the data structures.

Note that you might also observe that the error is being raised in a different instrument now, this is because I had set instrument server = None on all meta-instruments before and the LutMan (lookuptable manager) is just earlier in the initialization script.

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-1-823213492ef7> in <module>()
      9 
     10 # import as * puts all the imports and objects of the init in the global namespace
---> 11 from init.LaDucati import *

D:\GitHubRepos\PycQED_py3\init\LaDucati.py in <module>()
     65                                 server_name='')
     66 LutMan = lm.QuTech_ControlBox_LookuptableManager('LutMan', CBox=CBox,
---> 67                                                  server_name='')
     68 
     69 MC = mc.MeasurementControl('MC')

d:\githubrepos\qcodes\qcodes\instrument\base.py in __new__(cls, server_name, *args, **kwargs)
     68         else:
     69             return RemoteInstrument(*args, instrument_class=cls,
---> 70                                     server_name=server_name, **kwargs)
     71 
     72     def __init__(self, name, server_name=None, **kwargs):

d:\githubrepos\qcodes\qcodes\instrument\remote.py in __init__(self, instrument_class, server_name, *args, **kwargs)
     23                 del kwargs[kwname]
     24 
---> 25         manager = get_instrument_server(server_name, shared_kwargs)
     26         # connect sets self.connection
     27         manager.connect(self, instrument_class, args, kwargs)

d:\githubrepos\qcodes\qcodes\instrument\server.py in get_instrument_server(server_name, shared_kwargs)
     36             raise ValueError(('An InstrumentServer with name "{}" already '
     37                               'exists but with different shared_attrs'
---> 38                               ).format(server_name))
     39     else:
     40         manager = InstrumentManager(server_name, shared_kwargs)

ValueError: An InstrumentServer with name "Instruments" already exists but with different shared_attrs

[alexcjohnson]

@AdriaanRol yes, this is certainly confusing and in need of some good docs & examples.

Every InstrumentServer needs to have identical shared_kwargs among all the instruments loaded there. That's because these args get loaded into the server when it's created, then passed on to each instrument that's loaded there during its construction on the server side.

So in this case, seems you have:

• a bunch of hardware instruments with no shared_kwargs - these can go on the same or different servers, shouldn't really matter.
• a Tektronix_driven_transmon that connects to a whole bunch of hardware instruments - this needs to be on a different server from the hardware, with all of the hardware instruments passed in as shared_kwargs
• a QuTech_ControlBox_LookuptableManager that connects to just one hardware instrument - should be on yet another server, not containing any of the hardware, nor the Tektronix_driven_transmon. Actually, I think in principle it could be on the same server as the Tektronix_driven_transmon IF its shared_kwargs are a subset of the Tektronix_driven_transmon and the Tektronix_driven_transmon is the one used to start the server... but I haven't tested this situation.
• If you have a meta-instrument that links to other meta-instruments, the linking one would need to be on a separate server from the linked one.

Just in case you haven't seen it, note that there's also the default_server_name() class method... but lets get this working first with server_name=... and then you can put the results in that method.

[AdriaanRol]

@alexcjohnson thanks for the clarifications. I got around to testing it. I can now almost correctly initialize my instruments provided I put every meta-instrument on its own server.

The problem occurs now because the qubit object also receives an instance of the MeasurementControl (MC), our equivalent of the loop. The MC is not pickleable (see below for error log, tested by setting MC=None). My current workaround is to run the qubit object with server_name=None

We may argue that compatibility with MC is not required for qcodes, however I think that the same problem will occur when we want to reuse loops (as discussed in #128 ). I would prefer if we could either combine the Loop with instruments that do not run on a server (suboptimal) or if we can somehow get red of the pickleability constraint.

If we want to use something like a qubit object that is able to perform simple measurements (loops) we need to be able to pass a reference to an instance of a Loop or to the station that contains such information. If you want I can send you a slide on how we use the qubit object and envision it related to meta-instruments and the Loop.

---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-1-823213492ef7> in <module>()
      9 
     10 # import as * puts all the imports and objects of the init in the global namespace
---> 11 from init.LaDucati import *

D:\GitHubRepos\PycQED_py3\init\LaDucati.py in <module>()
     76                                     AWG=AWG, LutMan=LutMan,
     77                                     CBox=CBox, heterodyne_instr=HS, MC=MC,
---> 78                                     server_name='qubit_server')
     79 VIP_mon_4 = qb.CBox_driven_transmon('VIP_mon_4',
     80                                     LO=LO, cw_source=S1, td_source=S2,

d:\githubrepos\qcodes\qcodes\instrument\base.py in __new__(cls, server_name, *args, **kwargs)
     68         else:
     69             return RemoteInstrument(*args, instrument_class=cls,
---> 70                                     server_name=server_name, **kwargs)
     71 
     72     def __init__(self, name, server_name=None, **kwargs):

d:\githubrepos\qcodes\qcodes\instrument\remote.py in __init__(self, instrument_class, server_name, *args, **kwargs)
     23                 del kwargs[kwname]
     24 
---> 25         manager = get_instrument_server(server_name, shared_kwargs)
     26         # connect sets self.connection
     27         manager.connect(self, instrument_class, args, kwargs)

d:\githubrepos\qcodes\qcodes\instrument\server.py in get_instrument_server(server_name, shared_kwargs)
     38                               ).format(server_name))
     39     else:
---> 40         manager = InstrumentManager(server_name, shared_kwargs)
     41 
     42     return manager

d:\githubrepos\qcodes\qcodes\instrument\server.py in __init__(self, name, shared_kwargs)
     63 
     64         super().__init__(name=name, server_class=InstrumentServer,
---> 65                          shared_attrs=shared_kwargs)
     66 
     67     def restart(self):

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in __init__(self, name, server_class, shared_attrs, query_timeout)
    250 
    251         self.query_timeout = query_timeout
--> 252         self._start_server()
    253 
    254     def _start_server(self):

d:\githubrepos\qcodes\qcodes\utils\multiprocessing.py in _start_server(self)
    254     def _start_server(self):
    255         self._server = QcodesProcess(target=self._run_server, name=self.name)
--> 256         self._server.start()
    257 
    258     def _run_server(self):

C:\Anaconda3\lib\multiprocessing\process.py in start(self)
    103                'daemonic processes are not allowed to have children'
    104         _cleanup()
--> 105         self._popen = self._Popen(self)
    106         self._sentinel = self._popen.sentinel
    107         _children.add(self)

C:\Anaconda3\lib\multiprocessing\context.py in _Popen(process_obj)
    210     @staticmethod
    211     def _Popen(process_obj):
--> 212         return _default_context.get_context().Process._Popen(process_obj)
    213 
    214 class DefaultContext(BaseContext):

C:\Anaconda3\lib\multiprocessing\context.py in _Popen(process_obj)
    311         def _Popen(process_obj):
    312             from .popen_spawn_win32 import Popen
--> 313             return Popen(process_obj)
    314 
    315     class SpawnContext(BaseContext):

C:\Anaconda3\lib\multiprocessing\popen_spawn_win32.py in __init__(self, process_obj)
     64             try:
     65                 reduction.dump(prep_data, to_child)
---> 66                 reduction.dump(process_obj, to_child)
     67             finally:
     68                 context.set_spawning_popen(None)

C:\Anaconda3\lib\multiprocessing\reduction.py in dump(obj, file, protocol)
     57 def dump(obj, file, protocol=None):
     58     '''Replacement for pickle.dump() using ForkingPickler.'''
---> 59     ForkingPickler(file, protocol).dump(obj)
     60 
     61 #

TypeError: can't pickle _thread.lock objects

[AdriaanRol]

@alexcjohnson , Cheered too soon, I cannot run a measurement when the AWG is on a server. Going back to having all instruments on None.

I do not know why this is, the crash come when I call AWG.is_awg_ready(), a command that runs fine from the notebook itself.

[AdriaanRol]

Now that I think some more about it I am quite sure this last error is caused by #136 .

This only leaves the problem of being able to hand an instance of a non pickleable object, or to be qcodes specific, the ability to start a loop from an instrument or (as suggested in #128 ) hand a reusable loop object to an instrument.

Another alternative I see is to make the loop compatible with instruments that are not running on a server. This would allow using the server = None (non-parallelized) instruments in special cases when you care less about parallelism. This would be suboptimal.

[AdriaanRol]

Closing this issue as I am convinced me continuing troubles are caused by the server timeout bug (which was solved) . The non pickleability of my Measurement control is a constraint of the instrument and not a bug.

If the issue persists I will reopen.