Re: Unpredictable behaviour with PyEpics

[Matt Newville via Tech-talk <tech-talk at aps.anl.gov>]

Hi Simon,

On Tue, May 26, 2020 at 3:47 AM Simon Rose via Tech-talk <tech-talk at aps.anl.gov> wrote:

Hello all –

 

I am trying to set up something to do some automated testing of communication with a running IOC with PyEpics, but unfortunately I am running into some inconsistent behavior which makes it difficult to use as a reliable testing mechanism.

 

Specifically, if I have an IOC (EPICS base 7.0.3.1) up and running on the same machine, and run the following script:

 

from epics import PV

pv = PV(“test”)

assert pv.connect()

  

then most of the time, this works exactly as intended. However, somewhere around 1 in 5 times or so, it fails. I have tried to look at the network traffic (using Wireshark) between the IOC and the python client, but unfortunately I don’t see a difference between successful and unsuccessful connection attempts.

 

I am running both IOC and client inside a linux VM on my mac. 

The default "connection timeout" is 2 seconds.  That is, PV.connect() will poll for up to 2 seconds for the channel created when initializing the `PV` to be connected. 

For PVs provided by a running IOC on the same local (virtual) machine, the connection should be much faster than that.  I sort of suspect something else must be wrong. 

If this was on a more complex or slower network, I would suggest increasing the timeout (`PV.connect(timeout=5)`, for example).  I might also suggest not using `assert` to raise an exception for unconnected PVs in real code, but rather view "unconnected PV" as something that you want to deal with gracefully instead of simply raising an exception.    But, that all seems like it should be unnecessary if the IOC and client are on the same machine.

To follow-up on Jure's suggestion, `PV.wait_for_connection()` is not really much different from `PV.connect()`, but with a) first do `PV.connect()` if not already connected, and then b) wait for connection.  Yes, that sort of means that default timeout (still 2 seconds) will be waited twice before giving up on connecting a newly created PV.  Again, that seems like it would only reduce your failure rate from 20% to 10%, which still seems too high for locally-provided PVs.

--Matt