EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: Timestamp (drvTS) progress
From: "Thompson, David H." <[email protected]>
To: Korhonen Timo <[email protected]>, [email protected], [email protected], "Chernousko, Y (Yuri)" <[email protected]>, Jeff Hill <[email protected]>
Cc: Kalantari Babak <[email protected]>, [email protected], "Williams Jr, Ernest L." <[email protected]>
Date: Tue, 09 Mar 2004 13:59:13 -0500
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 Jeff Hill

Navigate by Date:
Prev: RE: Timestamp (drvTS) progress Jeff Hill
Next: RE: Timestamp (drvTS) progress Jeff Hill
Index: 2002  2003  <20042005  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 Marty Kraimer
Next: RE: Timestamp (drvTS) progress Jeff Hill
Index: 2002  2003  <20042005  2006  2007  2008  2009  2010  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 ·