Homemade Clocks
staticattic
Posts: 200
I have a TP that displays clocks from 5 different time zones. The problem is, due to the classification of the system, I am not allowed to connect it to the internet so I can't use an application like i!-TimeManager. No worries, I just pounded out the code myself to allow the user to set the local time and from there, it adds or subtracts hours depending. Probably not the most cost effective way to handle it, but this is what I did:
I can then take those integers and manipulate them however I need to. Afghanistan is weird because they are 9 and a half hours ahead. I created a timeline to query TIME every second. Is there a better way to do this?
nIraq = ATOI(LEFT_STRING(TIME,2)) nZulu = ATOI(LEFT_STRING(TIME,2)) nQatar = ATOI(LEFT_STRING(TIME,2)) nAfghanH = ATOI(LEFT_STRING(TIME,2)) nAfghanM = ATOI(MID_STRING(TIME,4,2))
I can then take those integers and manipulate them however I need to. Afghanistan is weird because they are 9 and a half hours ahead. I created a timeline to query TIME every second. Is there a better way to do this?
0
Comments
Having said that, I don't use the built-in clocks on the Touch panels. I also wrote my own time manager that looked at the NIST atomic clock for time sync. It was great since they had their own system of communicating when daylight savings time was on or off. I still don't like the network time protocol way of doing things.
However, NIST has discontinued their time service such as it is. It is now following the NTP and is hence forth not worth using.
I now use a Netlinx master here at my office that serves time to all my masters. The local clocks are set from the Mothership. I have a routine that sends the time to the touch panels in vari-text windows. It ticks off seconds. There is also a time set window that allows the client to set the clocks any way they want and it creates an offset from the master clock.
I realize with the current NI firmware the clocks are syncing to an NTS 'under the hood' I still have my routine running too. So, my internal clocks stay real synced up.
However, what gets displayed on the screen is not a TP time button but a text string created from the NI master.
Some here have expressed a concern that this would create too much network traffic. However, I have systems with 20-some moderos and 20-some G3's that work just fine. I don't usually send second ticks to G3s.
That's how I roll.
The problem is a little deeper then you think, when you start to think about daylight savings time, plus DST is different in other countries. See attachment, I think this covers almost all situations.
This code uses a slightly modified TimeDataLib.axi then we normally have. But the idea is simple. It allows you to set up each city, with different Daylight Savings Times with offset from Zulu Time.
Display on the TP with the Local Zulu Time offset.
IF (nZulu > 23) { nZulu = (nZulu - 24) }All that does is prevent the hours from going to 24 and above. The idea of daylight savings time had crossed my mind, but I was thinking of having a DST radio button to check when setting the clock. The only problem, now that you have mentioned it, some countries celebrate DST while others do not. In order for everything to work, I would have to hard code all of that info with a bunch of IF statements. My 42 lines was only for one time zone. Times that by 4 for each of the timezones where the TP could reside, then figure in the DST options, and I would be writing lots of code with hard coded variables. In my short experience, hard coded variables mostly work on a prayer. I have learned so much, but I still have much more to go. Thanks for the example and reply.
Yeah, that is what mine is doing too. When I was first toying with it, I displayed the time via the SetUp Port option in TPD4. After I really got into it, that quickly changed.
BTW, what stratum level is the internal clock on a NetLinx? How often can a user expect clock drift on a system that has no external source for checking the time?
Of course you will need to change the time on every DST change, other then that, the clock will drift a few seconds a year i would guess... Accurate enough for TPs....
Interesting, I have not found this to be the case. I have found that Master time can drift quite a bit. Maybe rebooting them more often makes for more drift I haven't tested for that.
Paul
As I understand the NTP driver on the Netlinx master, it does the typical checking of multiple NTS's and compares itself to them and averages them all out. If it's typical, it probably checks itself several times a day.
Some sophisticated time checking routines will even try to figure out what its own internal clock drift tends to be and will schedule accordingly.
My routine checks a couple times a day and that seems to keep it honest enough for most people. After all, we're not trying to align satellite communications or 200" reflector telescopes. We just want the landscape lighting to come on around the right time.
Back to the clock drift topic, if you guys remember that Binary Clock topic I started a couple of months ago, I have been running a binary clock as a screen saver on my TP every since then and I have not noticed any clock drift. I was wondering, is the hardiness of the clock at all related to the hardiness of the frequency of the power? If the power freq fluctuates, won't that affect the clock? Also, pinging the clock every second for a binary clock makes for a cool, geeky screen saver, but that is not going to wear anything out is it? I mean, I am not shortening the life of my little NI-700 by doing that am I?
Not long ago we had a system that needed extremely accurate time and date stamping for a security DVR file extraction process to a PC, so we looked at several methods of tightening this process up and ended up installing a AUD$200.00 GPS to the system and sucking the time and date out of that via serial.
I created a couple of calendar events based on our local DST rules, and adjusted the time on the inbound strings from the GPS.
Neat, sweet and very accurate.
Paul
We are nearly always creating closed AMX networks for purely this reason in these high profile environments, which doesn't cause an issue until you need accuracies as described above - thus the GPS solution!
When we do get to hop on their network, the NTP implementation is generally straightforward. Same with our VC solutions.
Attached is a binary clock/date module that can be fun, when trying to explain to non-code people how you read the time and date.
http://www.amxforums.com/showthread.php?t=3306&highlight=Binary+Clock