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 2020 2021 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 2020 2021 2022 2023 2024
<== Date ==>		<== Thread ==>

Subject:	RE: PyEpics speed
From:	"Dalesio, Leo" <[email protected]>
To:	Jeremy Iken <[email protected]>, "[email protected]" <[email protected]>
Date:	Mon, 24 Jun 2013 15:39:37 +0000

Hi Jeremy,

From your pyEPICS call, there are a number of layers:

1) Your server (not sure which one this uses)

2) Channel Access server - 2-4 steps are what we would call EPICS comm time < 1 msec

network

3) Channel Access Client

4) EPICS database housing the device - this could have a scan time that could contribute to the delay

- - what is the SCAN field of the record you are getting?

5) EPICS Device Support - this could be immediate for register based devices to slow for GPIB

6) EPICS driver - this matches the time of the hardware and can either read ahead or on

demand and then wait for the hardware.

7) hardware - whatever the protocol response time there is to this - or time to

next trigger

For 200 msecs, the first place I would look is in the scan rate of the database record.

Navigate by Date:: Prev: Re: PyEpics speed J. Lewis Muir; Next: Re: Problem in errlogRemoveListener Michael Abbott; 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 2020 2021 2022 2023 2024
Navigate by Thread:: Prev: Re: PyEpics speed J. Lewis Muir; Next: Re: PyEpics speed Matt Newville; 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 2020 2021 2022 2023 2024

ANJ, 20 Apr 2015