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
{{ message }}
This repository was archived by the owner on Feb 2, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 2, 2026. It is now read-only.
instrument_handle = "TCPIP::169.254.14.7::INSTR"
c = vxi11.Instrument(instrument_handle)
c.timeout = MY_TIMEOUT_IN_SECONDS
would work appropriately for setting the socket timeout duration.
Unfortunately, it seems the socket timeout duration is the same regardless of me setting this value.
Any thoughts on this?
What leads you to believe that the timeout is not set on the socket?
In [1]: import vxi11
In [2]: vxi11.list_devices()
Out[2]: ['192.168.1.108']
In [3]: instr = vxi11.Instrument('192.168.1.108')
In [4]: instr.client
In [5]: instr.open()
In [6]: instr.client
Out[6]: <vxi11.vxi11.CoreClient at 0x7ff6cb26aa58>
In [7]: instr.client.sock.timeout
Out[7]: 11.0
In [8]: instr.timeout
Out[8]: 10
In [9]: instr.timeout = 30
In [10]: instr.client.sock.timeout
Out[10]: 31.0
I am using your library to search for instruments at predetermined IP addresses and rely on quick timeouts on addresses to make my search reasonably quick. Admittedly, this is a pretty dumb way to do this, but it's what I have to work with. I was using this method, and changing the timeout parameter in the instrument class did not seem to have an effect.
Looking through your code some more, it seems on first connection, the first socket opened on line 260,
as part of TCPClient does not have a timeout set explicitly. Only after a valid connection is established is the timeout set to the socket. I don't believe this is a bug in your implementation, just a weird use case I have.
I managed to set a timeout for initial connections by calling socket.setdefaulttimeout(val) before attempting to communicate with an instrument. This solved my particular issue. After seeing your list_devices() command, I may be abandoning this method sometime in the future.
I'm closing this as I don't think that the average user will need to set this parameter for initial socket connections. I have no idea how VXI-11 is laid out, so I have no idea how useful this info will be to others. Thanks for an amazing library.
Aha, I see. You're talking about the timeout for the portmapper call. I will take a look at implementing a good way of setting that. It may also be a good idea to roll a similar function into the list_devices call. Right now it uses UDP broadcast, which is not completely reliable. Having the option to attempt TCP connections to an explicit list could be a useful feature.
Activity
alexforencich commentedon Jan 23, 2017
What leads you to believe that the timeout is not set on the socket?
kchau101 commentedon Jan 23, 2017
I am using your library to search for instruments at predetermined IP addresses and rely on quick timeouts on addresses to make my search reasonably quick. Admittedly, this is a pretty dumb way to do this, but it's what I have to work with. I was using this method, and changing the timeout parameter in the instrument class did not seem to have an effect.
Looking through your code some more, it seems on first connection, the first socket opened on line 260,
as part of TCPClient does not have a timeout set explicitly. Only after a valid connection is established is the timeout set to the socket. I don't believe this is a bug in your implementation, just a weird use case I have.
I managed to set a timeout for initial connections by calling
socket.setdefaulttimeout(val)before attempting to communicate with an instrument. This solved my particular issue. After seeing your list_devices() command, I may be abandoning this method sometime in the future.I'm closing this as I don't think that the average user will need to set this parameter for initial socket connections. I have no idea how VXI-11 is laid out, so I have no idea how useful this info will be to others. Thanks for an amazing library.
alexforencich commentedon Jan 23, 2017
Aha, I see. You're talking about the timeout for the portmapper call. I will take a look at implementing a good way of setting that. It may also be a good idea to roll a similar function into the list_devices call. Right now it uses UDP broadcast, which is not completely reliable. Having the option to attempt TCP connections to an explicit list could be a useful feature.