EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Understanding the time support on Epics.
From: [email protected] (John R. Winans)
Date: Thu, 23 Mar 1995 21:17:09 -0600
>It is interesting to hear you might want to do it. If you do, use a
>Bancomm 635/637 since that is what we all have.

I think the choice has been made for me already.  And from what I can tell,
it has IRIG-B (what I call to myself irate-B) commin' into it.  So I think
I am SOL on the year thing.

>>       The device ONLY provided the number of milliseconds into the current
>>       calander year.  Therefore I could not figure out what year it is.  A 
>>       rather nasty problem for an IOC that should otherwise be self contained.>       I figure that I could always ask a Unix box for the time and assume it is
>>       close ehough to get the year right.
>
>This is a problem which is very common and arises because the standard
>way for ditributing time is IRIG B, which is a serial BCD format which
>doesn't understand years. However, most GPS boards have an on board
>RTC, (most IOC's do too) which can give a guess at the year. I am
>trying to ensure that Bancomm uses this clock to provide the year.

*SIGH*  I had hope that someone would tell me I am nuts and that I missed 
something obvious.

>What I am going to do is run the whole network on GPS time and provide
>the 10 second time error as an interesting conversation piece. Anyone
>who really needs UTC can convert easily - GPS->UTC is easy, it is only
>the other way round that is hard.

Recently, someone told me that my frustrations in life come from the fact that 
I am a perfectionist.  I laughed and then thought about it for a minuite (one
of those 61 second jobbers at that) and then realized that perhaps I have been
a tad hard on defining the success point of my work.  Perhaps the temporary
inaccuracy in time stamps is simply something that I should not care about.  
I mean, the IOCs of the APS will only be out of sync with eachother for a few 
seconds (between the leap and the next resync rondezvous... a 15 second tunable 
default) anyway.  

*SIGH* I just don't know.  What does everyone else think?


--John

Navigate by Date:
Prev: Re: Understanding the time support on Epics. Nick Rees
Next: Re: Understanding the time support on Epics. Philip Taylor
Index: 1994  <19951996  1997  1998  1999  2000  2001  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: Re: Understanding the time support on Epics. Nick Rees
Next: Re: Understanding the time support on Epics. Philip Taylor
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·