Experimental Physics and
| |||||||||||||||||
|
Hi Greg,
Sorry for the trouble and confusion. On Tue, Aug 30, 2016 at 9:43 AM, Guyotte, Greg S. <[email protected]> wrote: The situation with `epics.caget()` is somewhat different. Here, the `timeout` value is used as the timeout for getting a value from a connected PV, and the connection timeout (this time, not doubled!) is currently set to 5.0 seconds, without an option to change that value.I’m experiencing unexpected timeout behavior on PyEpics 3.2.4. Yes, I see that too. It looks to me like you've exposed 2 separate flaws in the code for PV timeouts. Using epics.caget(), the timeout value seems to be ignored and I There are meant to be 2 different wait times: a timeout for connecting to a PV, and a timeout for getting a value. When you do (I'm deliberately using different and non-default timeout values here): p = epics.PV('idontexist', connection_time=2.5) this does not actually wait for the connection to happen, but does set the connection timeout. Later, when you try to get the value with val = p.get(timeout=1.5) it will notice that the PV is not connected and try to connect (calling `p.wait_for_connection()`). This should wait up to 2.5 seconds. In fact, it's currently effectively doing that twice the first time, so waiting 5.0 seconds -- this is what you see, and the code should be fixed to not wait twice. But, because the PV here never connects, the timeout for getting the value is (and should be) irrelevant. print "" Both of these should be simple to fix: A) do not wait 2*connection_wait_time for the initial connection B) use `timeout` in `epics.caget()` as the timeout for the entire operation (connection + get). I'll push these changes to the master branch soon. --Matt
| ||||||||||||||||
ANJ, 30 Aug 2016 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |