We are trying to use a Bancomm bc635VME Time and Frequency
Processor as a Time Provider for epicsGeneralTime. It seems to work OK only under certain conditions.
We register the Bancomm as a time provider with this call:
generalTimeRegisterCurrentProvider("bc635",
bc635TimePvt.priority,
bc635TimeGetCurrent);
where bc635TimePvt.priority is some some priority (we set it to 20) and
bc635TimeGetCurrent is a function that fills in an epicsTimeStamp with the time read from the Bancomm board.
Our problem comes when the Bancomm board is not locked to it's reference signal and happens to have a time set that is in the past compared to NTP time.
EPICS timekeeping becomes erratic and eventually grinds to a halt, and records set to scan at periodic rates quit processing.
My understanding is that generalTime prevents "backwards time" transitions, and if the time read from the current time provider is in the past compared to the previous time read, then it will not update the time, but return the previous value.
It's not clear to me what happens after that. The next time generalTime tries to read the current time, does it attempt to use the highest priority time provider again, or does it then fall back to the time provider that last gave a good time?
If the former, how does the time ever get updated if the highest priority provider continues to give backwards time? If the latter, does generalTime ever check to see if the highest priority provider is giving good time yet, and to restart using it?
Why does time keeping become erratic when "backwards time" is prevented?
Thanks for any thoughts on this....
--
Mike Westfall
Control Systems Software Engineer
![]()
