You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a mixed-spectrometer setup, I noticed that while the Ethernet connection on the HDX would time out after O(10)s, the USB connection to the QE65000 would not. The relevant parts of the code are:
The value for self._device.pyusb_device.default_timeout seems to be quite different from my (arbitrary) choice of 10000ms for the default socket timeout.. This is likely also related to #146
I can configure the timeout by calling spec._dev._raw_device.socket.settimeout(timeout_in_s) directly but was wondering whether there is a less awkward mechanism in seabreeze of setting that -- and if not, how one would best introduce one :)
Some more details on my user story:
While 10s seems a reasonable default timeout for internal triggers, in my particular case, I am setting up hardware triggers which might only be generated after much longer time than 10s. So before the setup generates the first trigger, the HDX would have already raised a TimeoutError.
(From my short investigation into the state of the HDX after the timeout, I actually believe that the hardware is still stuck waiting for triggers and I am not sure at this point whether one can recover from the software side without either sending a trigger or resetting the hardware. But this is not what I wanted to raise in this issue.)
steps to reproduce
Using a USB connection:
In [1]: import seabreeze
...: from seabreeze.spectrometers import Spectrometer, SeaBreezeError
...: seabreeze.use("pyseabreeze")
In [2]: spec_usb = Spectrometer.from_serial_number("QEPB0123")
In [3]: spec_usb.trigger_mode(3) # hw triggers
In [4]: spec_usb.intensities(0,0) # this does not time out even after minutes
Using an Ethernet connection and the HDX:
In [1]: import seabreeze
...: from seabreeze.spectrometers import Spectrometer, SeaBreezeError
...: seabreeze.use("pyseabreeze", network_adapter="192.168.254.200")
In [2]: spec = Spectrometer.from_serial_number("HDX01234")
In [3]: spec.trigger_mode(1) # hw rising edge
In [4]: spec.intensities(0,0) # this would time out after 20s
The text was updated successfully, but these errors were encountered:
So a while ago a fix was added to pyseabreeze to extend that timeout dependent on the integration that was set. It was combined into another PR which is why it wasn't very visible:
spectrometer and system information
current problem
In a mixed-spectrometer setup, I noticed that while the Ethernet connection on the HDX would time out after O(10)s, the USB connection to the QE65000 would not. The relevant parts of the code are:
python-seabreeze/src/seabreeze/pyseabreeze/transport.py
Lines 233 to 236 in 8090c59
python-seabreeze/src/seabreeze/pyseabreeze/transport.py
Lines 503 to 509 in 8090c59
The value for
self._device.pyusb_device.default_timeout
seems to be quite different from my (arbitrary) choice of 10000ms for the default socket timeout.. This is likely also related to #146I can configure the timeout by calling
spec._dev._raw_device.socket.settimeout(timeout_in_s)
directly but was wondering whether there is a less awkward mechanism inseabreeze
of setting that -- and if not, how one would best introduce one :)Some more details on my user story:
While 10s seems a reasonable default timeout for internal triggers, in my particular case, I am setting up hardware triggers which might only be generated after much longer time than 10s. So before the setup generates the first trigger, the HDX would have already raised a
TimeoutError
.(From my short investigation into the state of the HDX after the timeout, I actually believe that the hardware is still stuck waiting for triggers and I am not sure at this point whether one can recover from the software side without either sending a trigger or resetting the hardware. But this is not what I wanted to raise in this issue.)
steps to reproduce
Using a USB connection:
Using an Ethernet connection and the HDX:
The text was updated successfully, but these errors were encountered: