EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: generalTime & EventTime
From: Kay-Uwe Kasemir <[email protected]>
To: Kalantari Babak <[email protected]>, David Thompson <[email protected]>
Cc: Andrew Johnson <[email protected]>, Korhonen Timo <[email protected]>, [email protected]
Date: Wed, 02 May 2007 11:07:16 -0400
Hi:

5. An API (e.g. a config command) will be provided to specify which
event card (e.g. EVR/EVG) in a system is to be used by EventTime driver.
This should be called at the startup (by users). In principle we could
implement the same method for NTP Time provider to specify which NTP
server has to be used.

The API used to configure a time provider (NTP, MySpecialGPSReceiver, ...)
is of course a bit up to the implementor of that time provider.
NTP might look like this:

# Configure an NTP time provider to use given NTP server IP,
# and tell it to register with "generalTime" at priority 5
NTP_time_provider_config("123.45.24.8", 5)

# Configure an NTP time provider to use another  NTP server IP,
# and tell it to register with "generalTime" at priority 6
NTP_time_provider_config("123.45.24.7", 6)

For MySpecialGPSReceiver, it might look a bit different
MySpecialGPSReceiver_config(base address, poll interval, debug flag, ...., generalTime priority)

I thought the point was that the API on the general time side must include
a user arg.
When a time provider registers, it's not only
  generalTimeAddTimeProvider(my_get_time_routine, level)
but
  generalTimeAddTimeProvider(my_get_time_routine, my_user_arg, level)

That way, I can use that from within NTP_time_provider_config to
pass the specific IP address (structure with that IP plus whatever else
I need to remember) via my_user_arg.

-Kay


On May 2, 2007, at 10:54 , Kalantari Babak wrote:

Hi Andrew,

I have summarized our discussion in the last EPICS meeting at DESY
regarding the generalTime/EventTime driver issues as the following:

1. Central part of generalTime which manages the time providers will be
moved to EPICS base. The time providers (VW, NTP, Event, etc.) are
plugged in as drivers. The iocClockRegister.c will be integrated in this
central part and has to support all platforms (OS).

2. EventTime driver will completely rely on generalTime as an external
time reference (e.g. at init or when the master clock wants to lock to a reference time). It never contacts NTP server directly. To do so we have to change the generalTime such that a time provider which is correct can
read generalTime clock by implicitly excluding itself from the list of
time providers.

3. The generalTime API has to be changed in order to separate GetEvent()
and GetCurrent() registration because epicsTimeGetEvent() only makes
sense for the event system.

4. In EventTime we should provide the users with possibility to specify automatic/manual clock validation after clock failures. The manual clock
validation will be implemented by an "aoRecord" soft device support in
which VAL field determines the tolerance of the difference between
EventTime time and the reference time (which is given by generalTime,
see point 2.) at the time of validating.

5. An API (e.g. a config command) will be provided to specify which
event card (e.g. EVR/EVG) in a system is to be used by EventTime driver.
This should be called at the startup (by users). In principle we could
implement the same method for NTP Time provider to specify which NTP
server has to be used.

6. The OS time (e.g. vxWorks) should be the last time provider which
always has to give a value for the time when all the other time
providers are faulty.

7. This is more a question: the point from Stephanie Allison is still
not clear to me; my understanding was that she is only interested in
event time only when she has given a positive event number to TSE field
and otherwise (TSE=0) she is not interested in the time which is
provided by event system. But this means to use two different time
provider at the same time (priority problem?).

8. Finally we may change the name "generalTime" to something different;
maybe iocTime or iocTimeManager whatsoever.

Please let me know your comments if something needs to be changed or
something is missing.
Sorry that the e-mail is a bit too long.

Regards,
Babak


Replies:
RE: generalTime & EventTime Thompson, David H.
References:
generalTime & EventTime Kalantari Babak

Navigate by Date:
Prev: generalTime & EventTime Kalantari Babak
Next: RE: generalTime & EventTime Thompson, David H.
Index: 2002  2003  2004  2005  2006  <20072008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: generalTime & EventTime Kalantari Babak
Next: RE: generalTime & EventTime Thompson, David H.
Index: 2002  2003  2004  2005  2006  <20072008  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 ·