EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Unpredictable behaviour with PyEpics
From: Matt Newville via Tech-talk <tech-talk at aps.anl.gov>
To: Simon Rose <Simon.Rose at ess.eu>
Cc: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Date: Wed, 27 May 2020 10:29:15 -0500
Hi Simon, 


On Wed, May 27, 2020 at 1:33 AM Simon Rose <Simon.Rose at ess.eu> wrote:

Hi all –

 

I am not using a python interpreter from within the IOC; I am using python outside the IOC (but on the same VM) to test the IOC.


OK, I think that simplifies the problem.

 

Something that I have noted: the default delay of 2 seconds can be shortened quite a bit (about 0.05 seconds seems as far as I can push it).


Yes, there does seem to be a real and possibly unavoidable time between creating a PV and actually being fully connected.  20 to 50 ms is about normal, I think.  That time can be shared over multiple connections so that one can create hundreds of PVs and be able to use them quickly.

I think that I was wrong earlier in the expectation that  `assert pv.connect()` should just work.   In fact, `pv.connet()` is now more like an extra-explicit request to connect.  It will not set `PV.connected` itself but merely mark "connection has started".  So the right way to verify connection after creating a PV should really be

    mypy = PV(pvname)
    mypv.wait_for_connection()

But this should not really be necessary - connection will happen and getting/putting data for the PV will also wait for connection.  
 

However, if I run wait_for_connect() and debug what path it takes through that function in order to connect, I see the same consistent behavior as initially described: about 1 in 5 times it fails to connect on the call to connect(), but then succeeds when it hits the call to ca.poll() (although it may take a few poll()s before it succeeds).

 

Note that this does not depend (!) on the length of the delay: a delay of 10 seconds yields the same pattern as a delay of 0.05 seconds.

You should use 'wait_for_connection()` as the method that will wait to return until connection has completed.  If that is not working, can you post the actual code you're having trouble with?

 

(Regarding Jaroslav’s earlier question, although it may be moot: the PYEPICS_LIBCA in both cases is the same)


Setting PYEPICS_LIBCA should not be necessary for your case. 
Hope that helps, 

--Matt 

References:
Unpredictable behaviour with PyEpics Simon Rose via Tech-talk
Re: Unpredictable behaviour with PyEpics Jaroslav Adam via Tech-talk
Re: Unpredictable behaviour with PyEpics Matt Newville via Tech-talk
Re: Unpredictable behaviour with PyEpics Simon Rose via Tech-talk

Navigate by Date:
Prev: Re: SoftIOC and Labview Paul Sichta via Tech-talk
Next: Re: SoftIOC and Labview Baily, Scott A via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Unpredictable behaviour with PyEpics Simon Rose via Tech-talk
Next: Mirror Control Room Elio Valenzuela via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  <20202021  2022  2023  2024 
ANJ, 28 May 2020 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·