Experimental Physics and
Industrial Control System

"Thompson, David H." <[email protected]> · Wed, 02 May 2007 13:41:41 -0400

Not sure what I missed.  Sounds like a lot of progress was made.

The calls to epicsTimeGetCurrent()  come from task schedulers and the
calls to epicsTimeGetEvent() come from record processing.  It seems to
me that you would always need to have at least one instance of both
kinds of providers in a system, and they can be the same.  For
getCurrent calls you want a stable monotonic source, for getEvent calls
you want a  timing system time if you can get it.  Thus two priority
lists generally in opposing order.

You can define what event "0" means in your event provider, in our case
it is the current time from the timing system.  In our case records
processed with event '0' during a given machine cycle all have the time
stamp if the IOC has access to the timing system.  In Stephanie's case
the event time provider can always return an error if it does not have a
time for the event specified (in the record).

The event generator might be able to make calls to general time to get
the time for the event link but I had a conceptual problem with the idea
of a time provider possibly calling itself.  In addition, our GPS
receiver has a hardware trigger that is triggered by an event. Besides
being tightly coupled to the event generator itself the time thus
provided by GPS is one cycle too late.  My solution was to avoid the
question and not make the GPS a time provider.  I suppose a process
local variable would be one way guard the call.  Not saying I am right,
just don't know any other way to deal with it.

The iocTimeManager must provide a user handle to time provider
functions. I guess a C++ object is out of the question.

I agree that the startup API should provide the ability to set
priorities and names for multiple instances as well as an input
specification.  Remember it is otherwise an epics driver the same as any
other.

-----Original Message-----
From: Kay-Uwe Kasemir [mailto:[email protected]] 
Sent: Wednesday, May 02, 2007 11:07 AM
To: Kalantari Babak; Thompson, David H.
Cc: Andrew Johnson; Korhonen Timo; [email protected]
Subject: Re: generalTime & EventTime

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System