Is FPRead Timestamp clock not real-time?

[Kenrick]

Comparing FPRead Timestamp to get DateTime value is showing differnces in the rate. The code is runing on FP-2010 controller with LVRT7.1. Can some confirm this?
Here are my measurements:

>>
FPRead TStamp "Get D/T Sec" "Wait until O/P"
At Start
"3169448703.372" "3169441719.539" "18698915.000"

After 500 Cycles at 20mSec Wait, with some jitter
3169448713.597" "3169441728.156" "18709145.000"

Differences are:
"10.225" "8.617" "10.230"
<<

[Aaron_G]

Kenrick,

There are some reasons for the timestamps to vary slightly. If I recally correctly, The Get Date/Time in Seconds VI will directly query the on-board real-time clock (which is a fairly time intensive VI as it is requiring access to a chip that is external to the processor). By contrast, the FP Read TimeStamp and Wait Until Next Ms Multiple VIs are based upon a millisecond timer that is built into the processor iteself and takes much less time to execute. The initial time stamp for the FP Read Timestamp is determed by reading the external clock and and the current millisecond count, and future timestamps look at the difference in millisecond count values. Complicating the above is the fact that the FieldPoint module has built-in time synchronization wh
ich acts similar to a PID control in synchronizing the module to an external time server. This synchronization will periodically cause changes in all of the timestamp values and the external clock chip.

Over longer periods of time, I believe the differences in time values should be on a similar order of magnitude to the ones you list.

Regards,
Aaron

[Kenrick]

Thanks Aaron for your explanation. It helps my understanding of some of my observations.

There are many issues that I am trying to resolve.
The main issue is that from the simple results I posted, the Realtime Clock D/T value was 1.608s slower after 8.617seconds than the Timestamp from the FP Read.
Or, the Timestamp 1.608s ahead of the Real-time D/T value.

You believed this manitude is possible.

N.B The Time Sync function was dissabled.

What time source would you use when data logging (eg sine wave from a signal generator to check the time stamps) for long periods at 5 to 20mSec intervals.

I am hoping someone has a quantitave description of timestamps, relating to the FP Controller hardware and FPLVMgr.dll which contains the FPRead c
ore function.

Do you know of any NI documentation explaning operation of the millisecond counter.


This problem was discussed a while ago but wasn't resolved. See: http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000FBB60000&UCATEGORY_0=_18_%24_17_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=chris+farmer&USEARCHCONTEXT_QUESTION_S=0

I have attached the graph of my results which shows another issue. You can see the D/T increasing at a slower rate. The timestamp value jumped way ahead of the clock D/T value. But not the count O/P millisecond value.

... I feel like a Mad Timekeeper ...

Any ideas why the timestamp would jump ahead by 15seconds.

[Aaron_G]

"Any ideas as why th timestamp would jump ahead?"

From my previous post: "Complicating the above is the fact that the FieldPoint module has built-in time synchronization which acts similar to a PID control in synchronizing the module to an external time server. This synchronization will periodically cause changes in all of the timestamp values and the external clock chip."

More specifically, the time synchronization on the module, re-synchronizes to the host time server at 10 second intervals. If the differences in time between the machines is small, the rate of time in the module is adjusted (e.g. 1000 ticks = .998 seconds instead of 1.00 second (made up number)), if the differences are larger than some set value (I do not know what it i
s), then the real-time clock on the board will be adjusted and you will see a discrete 'jump' in the timestamps.

Regards,
Aaron

[Ben]

Hi Aaron and Kenrick,

When last I checked the FP time stamps were bad.

I resorted to using the "Get time..." instead.

Make sure the time server is shutdown. As of LV 7.0 the time server would behave badly if the server got to busy.

When last I checked, Chris Farmer (NI FP product support) was able to confirm this behaviour.

Just trying to help,

Ben

[Kenrick]

The timeserver fields in NI-MAX \ FP Controller are OFF.

Can the timeserver settings and state be monitored from RTLV on the controller to indicate if the timeserver is still active?

[Aaron_G]

Even with the Time Server off, the timestamps from the different functions are still coming from two different clocks (processor and off-board real time clock chip) that are both clocked using different crystals/oscillators. It is normal for them not to perfectly agree, which is why they are periodically re-synchronized. I do not know which is more accurate over differing time periods.

Off the top of my head, I am not sure if it is possible or not to retrieve the time server settings. I also do not have any [c]FP hardware at the current time to try to find out. Sorry.

Aaron

[Ben]

THe settings to use a time server, its IP etc is in the INI file on the RT system.

If 0.0.0.0 then it is off.

I first started to question the FP timestamps when I started getting reding from before I devloped the application. The customer thought ther amybe something wrong (:-)).

Please keep us updated on what you find and what works out!

This is how Aaron and I can stay up on the issue.

Ben