cFP clock loose synchronization

[Graziano]

Hi!
   It seems to me there's a great problem in my 2 cFP-2020.  They run an embedded application, in which I manually can set system time.  In a timed loop I get cFP system date-time, and I notice that, in comparison to windows system clock, cFP clock looses about 2-3 seconds each 10 minutes: it's really too much!

   In my application I have to log events with timestamps, and I need an accurate clock! Moreover, my final application won't have an ethernet connection, so that I can't provide a time-server! So onboard clock must be accurate! I can only send packets via RS232 to update time, but I whish I could do it once per day, not once per minute!

   Last thing I noticed, is that this lost of synch happens mainly when I cyclically get system time, but it seems absurd to me that system clock looses cycles when "asked" for time!

   Thank so much!

graziano

  

[Matthew_Williams]

Some suggestions for time on embedded FP:

http://forums.ni.com/ni/board/message?board.id=110&message.id=4051#M4051

We have had good results using these techniques although I haven't quantified our
time accuracy when disconnected from the network.  Our systems are only disconnected
during a network failure and time accuracy is not critical in that condition.

I'll take a look at your .vi in a little bit to see if there is anything further I can offer.

Matt

[Graziano]

Hi Mattew!

   I don't think that in Windows, clock drifts under hard system load... OS clock should refer to HW clock, and this problem should not occur!

   Now, I can I get HW clock? In the post you reported, are you suggesting to implement a clock with a timed loop? That's crazy, because timing in timed loops is few reqalistic....

   Let me know....

graziano

[Matthew_Williams]

On the PC, windows 98 and earlier (I don't know about later), the OS
clock was set from the hardware clock when windows was started.
Subsequent 'reads' of the clock came from the OS, thus the OS clock
and hardware clock would gradually diverge.  This would be exacerbated
under high CPU load, resulting in the OS clock lagging the hardware.

My understanding of the Fieldpoint clocks is that they are similar; the OS
clock is set at boot from the hardware and is not re-synced at any point.
Thus they will diverge, especially when the CPU is heavily loaded.

I wasn't trying to recommend that a date/time clock be implemented in
a timed loop; but rather that in instances where timing is not related to
calendar time then the mS counter is a more reliable time source than
the OS clock.

The easiest way to read the HW clock in FP is the timestamp associated
with the reading of an input.  From my discussions with NI folk the fastest
input to read is one of the dip switches on the controller itself.  Just read
the dipswitch, grab the timestamp as your reading of the HW clock
and discard the dipswitch data.

Hope this helps.

Matt

[Graziano]

Hi!

   It seemed absurd to me, but I've verified that get system time/date is dependant from CPU load, on cFP (not in PCs, anyway!), while get tick count doesn't drift, but... should I implement my own clock with get tick count?????

   The problem is that I need timestamps with year-month-day-hour-min-sec!!!!!!!  It can be good to use get tick count to get a timeout of 5 seconds, or to evaluate elapsed time in short periods, but... it's really tiring to implement a date/time clock from it!!!!

   Hope somebody can give details...

graziano

[Graziano]

Hi Mattew! That's 5 stars, now!

   This topic begins to show interesting developements....

    That's really nice what you say about reading cFP switches!!!! Do you have a programming example of this (for LabVIEW 7.1)?

    Anyway, I'll try to come out of this, and if I can access system time this way... ok, I'll do it! Really thanks!

    For NI people: is this problem due to PharLap ETS??????? Wen are you switching to WX Workx???????

graziano

[Graziano]

COPY!
   I've it, but it still seems strange to me!!!  Thanks again, Mattew!

graziano

[Matthew_Williams]

These two .vis are one way to get and distribute the HW clock.
A 'read' of time_global.vi will return the most recently set time.
We read our I/O about 1/second so the time is plenty accurate
for our applications.

Matt

Message Edited by Matthew Williams on 04-20-2006 10:32 AM

[Graziano]

Thanks again, Matthews!!!

In the attached file, there's NI answer, I think it can help other people...

graziano

[cs42]

Very interesting answer from NI. Depending on what you do this is a real must to know!

I'd just like to know now, what's synchronised over time and if there's something synchronized. If I define a time server, does synchronisation to this only happen on boot?

Thanks for posting this.

Cheers,
    Carsten