slaclab / pysmurf

Other
2 stars 9 forks source link

PV gets timing out / saturating max # of tries in releases > v7.1.0 due to difference between `epics.caget` and `epics.PV.get` default timeout #780

Closed swh76 closed 1 year ago

swh76 commented 1 year ago

Describe the bug

Users report register gets are timing out and saturating the max number of caget attempts in newer releases (>v7.1.0). This coincides with the change in v7.2.0 over to PV caching, and is apparently due to a subtle difference in the pyepics default timeout for register gets using epics.caget (which has a default timeout of 5 sec, and is what we used to use before PV caching) versus epics.PV.get (which is what we now use, but apparently has a default timeout of 2 sec).

Snippet for verifying in latest release v7.3.4;

In [3]: epics.__version__
Out[3]: '3.5.1'

In [4]: %timeit -r1 -n1 epics.caget('tmp')
cannot connect to tmp
5.01 s ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)

pv=epics.PV('tmp')
pv.get(count=1)
In [8]: %timeit -r1 -n1 pv.get(count=1)
2 s ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)

Will fix by adding timeout as an option to the underlying pysmurf _caget call with 5 sec default value. E.g.

# this should fix.
In [11]: %timeit -r1 -n1 pv.get(count=1,timeout=5)
5 s ± 0 ns per loop (mean ± std. dev. of 1 run, 1 loop each)