In our program it seems that NetworkTimeProtocol returns the difference after the clock adjustment (instead of prior to the clock adjustment).
Why it doesn't give the difference before adjustment (as CR Basic Editor Help explains)?
Testprogram that shows the same behaviour: (Tested on CR1000 OS Std_27)
BeginProg
Scan(1, sec, 10, 0)
panelTemp(panelTemp, _50Hz)
NextScan
SlowSequence
Scan(1, min, 10, 0)
If (TimeIntoInterval(0, 10, min)) Then
CallTable deltaNTP
EndIf
If (TimeIntoInterval(1, 10, min)) Then
deltaNTPtmp = - NetworkTimeProtocol(NTP_SERVER, 0, 2147483000)
EndIf
If (TimeIntoInterval(2, 10, min)) Then
deltaNTP = - NetworkTimeProtocol(NTP_SERVER, 0, 100)
EndIf
NextScan
EndProg
Typical result from 10 minutes table:
TIMESTAMP RECORD DeltaNTP DeltaNTPtmp
...
2014-05-12 20:40:00 39 92 92
2014-05-12 20:50:00 40 95 95
2014-05-12 21:00:00 41 97 97
2014-05-12 21:10:00 42 100 99
2014-05-12 21:20:00 43 -8 102 <- clock adjustment at 21:12:00
2014-05-12 21:30:00 44 -6 -6
2014-05-12 21:40:00 45 -4 -4
...
When there's no clock adjustment, the deltaNTP value seems correct, because deltaNTP and deltaNTPtmp are about the same.
Besides the deltaNTP values, I can see on missing records in another table when the clock must have been adjusted.
* Last updated by: PBX on 5/23/2014 @ 3:51 AM *
Can anybody tell me why the NetworkTimeProtocol function returns the time difference after the clock adjustment is done. Not the difference prior to the clock adjustment, as the CR Basic documentation says.
I would expect that my deltaNTP and deltaNTPtmp values stay about the same any time.
Thanks
(Sorry something went wrong, the post appeared double finally)
* Last updated by: PBX on 6/24/2014 @ 4:21 AM *
NetworkTimeProtocol returns the error before the time is set.
One can only assume, as it is the goal of the NTP protocol/process, that the error after the time is set is as close to 0 as possible (minus errors due to asymetrical or varying network latencies).
Maybe what you are asking is that the value returned is always (New_Time - Old_Time). I.e. if the datalogger clock is adjusted 1 minute forward to match the NTP server as closely as possible, the returned value will be 60000.
Yes, that's what I was asking.
Actually I was asking why it doesn't give the clocktime difference prior to adjustment, because this is what the CR Basic Editor Help is saying:
The NetworkTimeProtocol function returns the measured clock error in milliseconds, prior to the clock adjustment.
So indeed as in your example, when the clock is set 1 minute forward, it should return the value 60000.
But apparently it doesn't do that when the clock is adjusted, but when it's not adjusted, it seems to give the correct clocktime difference.
So, why?
I either do not understand your question or do not agree with your findings.
Using a CR1000 with OS27, I clearly see that when NetworkTimeProtocol() is executed and the clock is adjusted, it returns the the difference between the new time and the old time.
I guess you understand my question, so we must have something different in our test conditions. As you can see, I've posted the program (except declarations) and the results in my first post.
I will think about it for testing it in different situations and come back on this later.
Anyway, there must be something in my test-case to get these undesirable results.
I had a look at it today, and found some (stupid) error in my program.
In the past I always took care of skipping a rerun of the Scan routine, when the clock is set backwards. But I had the ridiculous fixed-idea that it won't rerun in this testprogram.
My real program solved my NTP issue already in a better way, but at least the problem is found.