Author Topic: Nano-10 DATE[3] Undocumented Behaviors  (Read 10851 times)

garysdickinson

  • Hero Member
  • Posts: 502
  • Old PLC Coder
    • View Profile
Nano-10 DATE[3] Undocumented Behaviors
« on: April 09, 2011, 10:00:59 PM »
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.
« Last Edit: April 09, 2011, 10:03:51 PM by garysdickinson »

support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3174
    • View Profile
    • Internet Programmable PLCs
Re:Nano-10 DATE[3] Undocumented Behaviors
« Reply #1 on: April 11, 2011, 09:29:22 AM »
Only the newest PLCs (FMD, Nano-10 and F-series) implement the date function you discovered. What happen is that these new PLCs employ hardware RTC residing on the MCU and the date[] data are converted into the number of days counter accepted by the internal RTC, which is then reformatted again into the proper DATE[1], DATE[2], DATE[3] again. That explains how it is able to convert the 0th day into the month before.  There is no plan to implement this into the simulator as its usefulness is limited in the simulator.
Email: support@triplc.com
Tel: 1-877-TRI-PLCS