Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent timeout behavior between USB and Ethernet backends #256

Open
hperrey opened this issue Jul 25, 2024 · 1 comment
Open

Inconsistent timeout behavior between USB and Ethernet backends #256

hperrey opened this issue Jul 25, 2024 · 1 comment

Comments

@hperrey
Copy link
Contributor

hperrey commented Jul 25, 2024

spectrometer and system information

  • model: HDX and QE65000
  • operating system: Rocky Linux 8.10
  • python version: 3.9.16
  • python-seabreeze version: 2.9.2
  • installed-via: conda

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:

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
@ap--
Copy link
Owner

ap-- commented Sep 6, 2024

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:

#223

you could probably pass the same through to the ethernet backend?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants