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

Subject: generalTime time provider consternation
From: Michael Westfall <[email protected]>
To: [email protected]
Date: Thu, 12 May 2016 16:21:42 -0300
We are trying to  use a Bancomm bc635VME Time and Frequency
Processor as a Time Provider for epicsGeneralTime. It seems to work OK only under certain conditions.

We register the Bancomm as a time provider with this call:
generalTimeRegisterCurrentProvider("bc635",
                                    bc635TimePvt.priority,
                                    bc635TimeGetCurrent);

where bc635TimePvt.priority is some some priority (we set it to 20) and
bc635TimeGetCurrent is a function that fills in an epicsTimeStamp with the time read from the Bancomm board.

Our problem comes when the Bancomm board is not locked to it's reference signal and happens to have a time set that is in the past compared to NTP time.
EPICS timekeeping becomes erratic and eventually grinds to a halt, and records set to scan at periodic rates quit processing.

My understanding is that generalTime prevents "backwards time" transitions, and if the time read from the current time provider is in the past compared to the previous time read, then it will not update the time, but return the previous value.

It's not clear to me what happens after that. The next time generalTime tries to read the current time, does it attempt to use the highest priority time provider again, or does it then fall back to the time provider that last gave a good time?

If the former, how does the time ever get updated if the highest priority provider continues to give backwards time? If the latter, does generalTime ever check to see if the highest priority provider is giving good time yet, and to restart using it?

Why does time keeping become erratic when  "backwards time" is prevented?

Thanks for any thoughts on this....
--
Mike Westfall
Control Systems Software Engineer



Replies:
Re: generalTime time provider consternation Andrew Johnson

Navigate by Date:
Prev: EPICS Meeting schedule Timo Korhonen
Next: Model 8743 Closed-Loop Picomotor,Controller / Driver D Peter Siddons
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: EPICS Meeting schedule Timo Korhonen
Next: Re: generalTime time provider consternation Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 15 Jul 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·