I think that you are running into a issue with how the PLC's firmware updates the TIME[] and DATE[] registers.
If you think just about the time registers what happens when the time just gets to 23:59:59 and one second later the PLC system firmware needs to update the time to 00:00:00. I'll get you a hint the time will not go cleanly form 23:59:59 to 00:00:00. It is possible to observe all of the possible values :
23:59:59
23:59:00
23:00:00
00:00:00
And only the first and the last values are "right".
And by the way the roll from 23:59:59 to 00:00:00 will cause the a ripple in the DATE[] registers as the day number will be changed and if this is the last day of the month, the month number will change and if this is the last day or the last month of the year, then the year will change.
Another way of thinking about this is to think about an old car that has a mechanical odometer and you it is reading 69999 km. If you watch it as you are driving you will see that the least significant digit will get to 0 and you might think that your car has 69990 km but just wait and eventually all of the the digits will roll and the correct reading of 70000 km will be displayed. Each digit is mechanically coupled to the next one and there is a ripple from digit to digit. The exact same thing happens with the PLC system firmware.
There is another possible issue with the PLC's RTC mechanism. If you have battery backed RTC (all Fx models and FMD and Nano-10 if you installed the RTC module) you may see a "wrinkle in time". The issue is that even with the hardware RTC installed, TBASIC is not reading from the RTC hardware but from registers maintained by the PLC system firmware. Periodically the PLC registers are updated to match the values in the hardware RTC. If this happens once a day, there could be a either a gap in time for a duplication in time based on how far the PLC's CPU clock has drifted between updates. I have not been able to catch the this wrinkle with TBASIC code, but I been able to verify the issues with the TIME[] and DATE[] registers.
OK how do you get around the ripple issue? I would suggest that you take one of 2 approaches:
1. Avoid reading the time/date registers when the register values are changing.
2. Detect that the values are changing and wait until they quit rippling (changing).
The Avoidance approach can be achieved by polling until the seconds register reads 1. Now you have about 58 seconds to read all of the other time/date registers before you get into problem with the values changing again.
This is an example of the avoidance approach. The following code is called every 0.5 seconds and sets a RELAY that is used to invoke a custom function to perform your data logging:
if (Status(18) = 080001)
' Time is 8:00:01 and this is a time to log data
Setio Time2Log
elif (Status(18) = 200001)
' Time is 20:00:01 and this is a time to log data
Setio Time2Log
else
ClrIO Time2Log ' this is not the time to log data
endif
[/color][/font]
The Detection approach has you read all of the registers twice in a row and if any of the registers changed from the first to the second read, then you detected a ripple. You need to do this until you can read the registers 2x with no change from the first to the second reading.
This is an code example of the detection approach:
'Read RTC - code to access time of day registers and return CORRECT values
' in the following variables:
' DM[301] TIME[1], RTC Hours
' DM[302] TIME[2], RTC Minutes
' DM[303] TIME[3], RTC Seconds
' DM[304] DATE[1], RTC Year
' DM[305] DATE[2], RTC Month
' DM[306] DATE[3], RTC Day
while 1
' read all TIME[] and DATE[] registers, one time
'
DM[301] = TIME[1]
DM[302] = TIME[2]
DM[303] = TIME[3]
DM[304] = DATE[1]
DM[305] = DATE[2]
DM[306] = DATE[3]
' re-read the TIME[] register and verify that they did not change
' from the previous set. The whole point of this exercise is to
' detect and discard erroneous readings that can occur because the PLC
' firmware is constantly updating these register. It is possible to
' observe the following transitions:
'
' 23:59:59 -> 23:59:00 -> 23:00:00 -> 00:00:00
'
if ((DM[301]=TIME[1]) AND (DM[302]=TIME[2]) AND (DM[303]=TIME[3])
AND (DM[304] = DATE[1]) AND (DM[305] = DATE[2]) AND (DM[306] = DATE[3]))
' time and date registers are all valid
' log data with the saved values
'
return ' job is done
endif
' If we are here then there was a roll over between the reads of the
' TIME[] registers...so try it again
'
endwhile
[/color][/font]
Best regards,
Gary D*ckinson
