EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: VWTime driver
From: Andrew Johnson <[email protected]>
To: Kalantari Babak <[email protected]>
Cc: [email protected]
Date: Fri, 14 Aug 2009 10:53:09 -0500
Hi Babak,

On Friday 14 August 2009 05:31:55 Kalantari Babak wrote:
>
> I have a question regarding the vxWorks time driver of generalTime
> (drvDevVWTime.c) which we use in EPICS 3.14.8 and mv2304/mv5500.

We don't use that here, so there's not be much I can say about it...

> Shouldn't the VWTime (for systems with vxWorks OS) be always available
> even if it is not synced? (It could at least be set to EPICS epoch.)
> Is it also like this in 3.14.10 after changes in generalTime?

This is the code from osiClockTime.c in R3.14.11 which deals with this case:

/* Time Provider Routine */

static int ClockTimeGetCurrent(epicsTimeStamp *pDest)
{
    struct timespec clockNow;

    /* If a Hi-Res clock is available and works, use it */
    #ifdef CLOCK_REALTIME_HR
        clock_gettime(CLOCK_REALTIME_HR, &clockNow) &&
    #endif
    clock_gettime(CLOCK_REALTIME, &clockNow);

    if (!ClockTimePvt.synchronized &&
        clockNow.tv_sec < POSIX_TIME_AT_EPICS_EPOCH) {
        clockNow.tv_sec = POSIX_TIME_AT_EPICS_EPOCH + 86400;
        clockNow.tv_nsec = 0;
        clock_settime(CLOCK_REALTIME, &clockNow);
        errlogPrintf("WARNING: OS Clock time was read before being set.\n"
            "Using 1990-01-02 00:00:00.000000 UTC\n");
    }

    epicsTimeFromTimespec(pDest, &clockNow);
    return 0;
}

Thus if still unsynchronized it will print a warning message the first time 
you try and read it and set the clock to 1990-01-02T00:00:00.0Z which is 
guaranteed to be after the EPICS epoch no matter what timezone you're in.

> The other issue is RTC:
> It seems that vxWorks clockLib (clock_gettime, clock_settime, ...) does
> not make use of on-board RTC. If I call clock_gettime() after a soft
> reboot it always starts from 0 while the RTC should run at least as long
> as there is power. Wouldn't it be better to use RTC to maintain time
> sources like VWTime?

Not by default since vxWorks runs on boards that don't have an RTC, and we 
also want things to continue working even if the RTC battery dies.  However 
the nice thing about the plugin architecture we now have is that you can 
write a time provider plugin that knows how to access the RTC for your 
particular board, and your vxWorks clock will then get synchronized to the 
RTC if you do this.

Note that there is no standard RTC interface in the vxWorks BSPs, so you will 
probably have to write a different one for each CPU board.  This code can be 
as clever as you like, including synchronizing the RTC to higher priority NTP 
sources and even measuring how good the RTC is and correcting for a measured 
slow or fast oscillator.

HTH,

- Andrew
-- 
The best FOSS code is written to be read by other humans -- Harold Welte

References:
VWTime driver Kalantari Babak

Navigate by Date:
Prev: VWTime driver Kalantari Babak
Next: proper thread cleanup on Linux? Jeff Hill
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: VWTime driver Kalantari Babak
Next: proper thread cleanup on Linux? Jeff Hill
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·