Experimental Physics and Industrial Control System

I agree that a PLL would be used to produce a smoothly advancing time
estimate for the epicsTime feed, and that the vxWorks tick counter should
not be changed. On vxWorks, the two inputs to the PLL would be the register
that counts off the vxWorks tick (there is an unpublished interface for this
that is used by windview) and a periodic time sync event from the network
(or alternatively from a real time clock).

Jeff

> -----Original Message-----
> From: Thompson, David H. [mailto:[email protected]]
> Sent: Tuesday, March 09, 2004 11:59 AM
> To: Korhonen Timo; [email protected]; [email protected]; Chernousko, Y
> (Yuri); Jeff Hill
> Cc: Kalantari Babak; [email protected]; Williams Jr, Ernest L.
> Subject: RE: Timestamp (drvTS) progress
> 
> I am glad to hear this.
> 
> I had to go part way down this path with the SNS timing system since it
> has suffered with noise causing scan tasks to fail due to an assert that
> checks for negative local seconds from epoch.  I bridge data link
> outages by counting 16.667 ms (1/60 Hz) at each event link cycle start.
> If the timing system is unavailable the driver reverts to polling NTP
> every minute or so.   Most our time stamps are "time of last cycle
> start" so the resolution is not an issue.  I didn't want to spend too
> much time writing an NTP client, or duplicating the one in drvTS, all of
> which is in static functions.  Between NTP polls I use the raw vxWorks
> tick counter to calculate the elapsed time from the last poll.  If drvTS
> could run NTP when a hardware event system is present, with an NTP like
> PLL, then if the timing system has problems the failover could be made
> seamless. The hardware event driver should either fetch time from the
> NTP driver or return an error if it knows that its time is invalid.
> 
> It sure would be nice to be able to configure the IOC to have a stable
> NTP time available as a fallback if needed.
> 
> I would be sort of cautious about trying to sync vxWorks time.  Maybe
> someone knows better than I, but I would think that jumping the tick
> counter would cause waiting watchdogs and IPC calls blocked with
> timeouts to misbehave.  If you limit it to +/- 1 tick you might get away
> with it most of the time but I can think of applications from my
> robotics days where that could be a problem.  My approach to using the
> tick counter is to use it in conjunction with an offset provided by NTP
> to calculate the epics time stamp.    The old driver that I inherited
> here did this and caused system freezes when the timing cables were
> unplugged.
> 
> 
> 
> -----Original Message-----
> From: Korhonen Timo [mailto:[email protected]]
> Sent: Tuesday, March 09, 2004 12:13 PM
> To: [email protected]; [email protected]; Thompson, David H.; Chernousko, Y
> (Yuri); Jeff Hill
> Cc: Kalantari Babak; [email protected]
> Subject: Timestamp (drvTS) progress
> 
> Hello all,
> 
> I do not remember who all were interested in this topic in the
> beginning, but please feel free to forward this and also let
> me know who should also be involved.
> 
> More than two years ago in San Jose we had a time stamp meeting where I
> listed a number of problem points in the drvTS code. I also promised
> to start working on them. Finally last autumn we (myself and Babak
> Kalantari who actually has done most of the work) finally were able
> to get started with this work. Since that we have already got quite
> far (although many things still need to be done.)
> 
> The improvements so far include:
> -monitoring of the event receiver status and the link health, fault
> statistics
> -automatic switching to soft timing if there are problems with
> the EVR
> -synchronization of the local (vxWorks) clock with the "hard" time
> continually (this way we can switch from hard to soft time without
> jumps)
> -Channel Access interface to be able to monitor the status and to switch
> 
> between soft/hard timestamp modes
> -several problems with startup were corrected (if the communication with
> the master timing does not work, etc.)
> -and so on...
> 
> Now the system is really robust (well, at least in lab...) The switching
> 
> happens smoothly (we tested it by pulling the plug - and could not see
> any jumps in timestamps, within the available resolution.) We plan to
> take this new stuff in operation at SLS in one of the next shutdowns.
> 
> 
> The work so far has been done starting from the existing drvTS version.
> Actually, we would like to rewrite the whole thing at some point and
> make a better link to (S)NTP, etc., but to be sure that we understand
> the issues we decided first to rework drvTS.
> 
> This might be something of interest for the next collaboration meeting.
> I would be happy if you have some comments even before that.
> 
> best regards,
> 
> Timo
> --
> Timo Korhonen  PSI (Paul Scherrer Institut)
>                 CH-5232 Villigen PSI
>                 tel + 41- 56 3103262  fax + 41 - 56 310 3383
> e-mail:	       [email protected]

Replies:

Re: Timestamp (drvTS) progress Korhonen Timo

References:

RE: Timestamp (drvTS) progress Thompson, David H.

Navigate by Date:

Prev: RE: Timestamp (drvTS) progress Thompson, David H.

Next: Re: Bug in MVME167 BSP? Andrew Johnson

Index: 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: Timestamp (drvTS) progress Thompson, David H.

Next: Re: Timestamp (drvTS) progress Korhonen Timo

Index: 2002  2003  <2004>  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024