yokogawa GS200 randomly has error setting voltages
Open
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 459
- Forks
- 359
- Avg merge
- 3d 6h
- Merged PRs (30d)
- 73
Description
Steps to reproduce
- run a loop where you sweep yoko.voltage
- try this a few times, it's not clear if it's random or specific values
File "<ipython-input-63-df8f784eae66>", line 35, in <module>
do1d(yoko.voltage, yoko.voltage(), -0.4, step_num, 0.01, CavPrep_Task, vna.channels.S21.trace, CavSet_Task, vna.channels.SPEC.trace)
File "c:\users\triton2acq\qdev-wrappers\qdev_wrappers\sweep_functions.py", line 249, in do1d
do_plots=do_plots, use_threads=use_threads)
File "c:\users\triton2acq\qdev-wrappers\qdev_wrappers\sweep_functions.py", line 153, in _do_measurement
_ = loop.with_bg_task(plot.update).run(use_threads=use_threads)
File "c:\users\triton2acq\qcodes\qcodes\loops.py", line 738, in run
self._run_wrapper()
File "c:\users\triton2acq\qcodes\qcodes\loops.py", line 787, in _run_wrapper
self._run_loop(*args, **kwargs)
File "c:\users\triton2acq\qcodes\qcodes\loops.py", line 835, in _run_loop
set_val = self.sweep_values.set(value)
File "c:\users\triton2acq\qcodes\qcodes\instrument\parameter.py", line 417, in set_wrapper
raise e
File "c:\users\triton2acq\qcodes\qcodes\instrument\parameter.py", line 399, in set_wrapper
set_function(parsed_scaled_mapped_value, **kwargs)
File "c:\users\triton2acq\qcodes\qcodes\utils\command.py", line 177, in __call__
return self.exec_function(*args)
File "c:\users\triton2acq\qcodes\qcodes\instrument_drivers\yokogawa\GS200.py", line 369, in _get_set_output
self._set_output(output_level)
File "c:\users\triton2acq\qcodes\qcodes\instrument_drivers\yokogawa\GS200.py", line 409, in _set_output
self.write(cmd_str)
File "c:\users\triton2acq\qcodes\qcodes\instrument\base.py", line 611, in write
raise e
File "c:\users\triton2acq\qcodes\qcodes\instrument\base.py", line 607, in write
self.write_raw(cmd)
File "c:\users\triton2acq\qcodes\qcodes\instrument\visa.py", line 195, in write_raw
nr_bytes_written, ret_code = self.visa_handle.write(cmd)
File "C:\Users\Triton2acq\Anaconda3\envs\qcodes\lib\site-packages\pyvisa\resources\messagebased.py", line 207, in write
count = self.write_raw(message.encode(enco))
File "C:\Users\Triton2acq\Anaconda3\envs\qcodes\lib\site-packages\pyvisa\resources\messagebased.py", line 185, in write_raw
return self.visalib.write(self.session, message)
File "C:\Users\Triton2acq\Anaconda3\envs\qcodes\lib\site-packages\pyvisa\ctwrapper\functions.py", line 1864, in write
ret = library.viWrite(session, data, len(data), byref(return_count))
File "C:\Users\Triton2acq\Anaconda3\envs\qcodes\lib\site-packages\pyvisa\ctwrapper\highlevel.py", line 188, in _return_handler
raise errors.VisaIOError(ret_value)
VisaIOError: ('VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.', "writing ':SOUR:LEV -1.84731e-01' to <GS200_ext: yoko>", 'setting yoko_voltage to -0.18473124999999999')
This happened many times for a range of values:
eg also can replace last line with
VisaIOError: ('VI_ERROR_TMO (-1073807339): Timeout expired before operation completed.', "writing ':SOUR:LEV 1.00000e-03' to <GS200_ext: yoko>", 'setting yoko_voltage to 0.001')
You then cannot talk to it before clearing the message queue on the instrument by running
yoko.write('*CLS')
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in qcodes/instrument_drivers/yokogawa/GS200.py at _get_set_output and _set_output, then reproduce the voltage sweep described in the issue through qdev_wrappers/sweep_functions.py. Determine why writes time out and require *CLS, and verify that repeated sweeps across the reported values complete without the timeout or leaving the instrument unable to communicate.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100