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
<2007>
2008
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
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|