In studying the example PC6 file, "TimeServer", I noticed that the programmer set DATE[3] (day of month register) to a value of 0 to back up the RTC year, month, day registers.
The end result, is that the RTC DATE[1], DATE[2] and DATE[3] registers will be backed up to the last day of the previous month. The year register may also be affected.
The following TBASIC code:
???DATE[1] = 2012
???DATE[2] = 1
???DATE[3] = 0???
Will program the RTC to 12/31/2011. This effectively backs the RTC up one day. The TBASIC programmer doesn't have to worry about the number of days in each month. I haven't tested it for leap year behavior.
Programming the DATE[1] register with values less than 0 appear to advance the date way into the future. Negative numbers are not handled well by the PLC firmware. This is not a problem. Backing up by a single day is perfect.
I did a little work and discovered that If I program DATE[3] to a value greater than the maximum days possible for the current month and year will advance the RTC year, month and day registers.
The following TBASIC code:
???DATE[1] = 2011
???DATE[2] = 12
???DATE[3] = 32???' There are 31 days in December...
As there are only 31 days in December, this will advance the RTC to one day beyond the last day in December. The RTC will be programmed to 1/1/2012.
In the previous example, if DATE[3] is programed to 33, this will advance the RTC by 2 days. There is a bit of a pattern to
this...
OK. Also very cool.
This functionality is very useful, nearly indispensable when attempting to set the RTC for local time using an external time server such as NIST. The NIST server provides time but it is in UTC and there are many cases where the local date is either ahead of UTC or behind UTC by a single day.
It might be nice to formally document these behaviors. I suspect that the DATE[3] behavior exists in most of your PLCs. I only have access to a small sample of your products.
The simulator in TriLOGI V6.40 does not emulate these RTC behaviors.
In the spirit of full disclosure, are there any similar undocumented math capabilities in the TIME[] registers?
I ask this because there are a few places crazier than California. There are a lot of spots in the world that local time is not on hour boundaries. Adelaide Australia is +9:30 away form UTC... and they're only a little crazy!
Thanks for letting me rant.
Gary D.
