Timing in RT

[Snamprogetti]

I noticed some weird behavior about synchronism in a RT program of mine, so i did a test: i ran a simple VI with a 1 second timed loop, which just writes current time (including milliseconds) on a file. Everything's ok on PC, but on RT the written times don't match exactly with clock seconds, i got results like this:

14:00:37.124
14:00:38.120
14:00:39.118
14:00:40.113
14:00:41.111
14:00:42.107
...

Cycles are shorter by a few milliseconds, compared to system time. This was with a Timed Loop structure; by using a While loop with "Wait until next multiple" i get the opposite!

14:05:28.717
14:05:29.718
14:05:30.719
14:05:31.720
14:05:32.721
14:05:33.721
...

If i set the FP to use a Time Server, it's same thing but there are periodic "jumps", probably caused by the Time Server adjusting the clock:

...
13:42:31.979
13:42:32.974
13:42:33.971
13:42:34.968
13:42:36.112
13:42:37.109
13:42:38.106
13:42:39.102
...

Looks like, in RT, system timer and timers used by VIs are not aligned. Do you know any info about the matter, and how to align them?

[Greg G.]

What version of LabVIEW RT are you using?

[Snamprogetti]

7.1 (up to date on the remote target too)

[Greg G.]

This was a problem with 7.1 and earlier.  It was fixed in 8.0.  In 7.1 and earlier, there was no way to keep all sources of time in the system synchronized.  If this is a major problem for you, I'd suggest upgrading to 8.2. 

[Snamprogetti]

Thank you. When i've upgraded to 8.2 (it's gonna happen), is there anything to do to syncronize timed loops and system time, or will they be automatically aligned?

[Greg G.]

It will be automatic.  You don't have to do anything special. 

greg

[Matthew_Williams]

Hi Greg.  Could you elaborate some on the RT time problems with 7.1 and earlier?

We have noticed some of the problems and _think_ we have worked around everything
but a sense of what the problems are from the inside would be very much appreciated.

Thanks.

Matt

[Greg G.]

I'm not familiar with all the details, but the basic problem was that there were multiple sources of "time".  Different calls were getting their time from different base clocks.  I believe one was from the programmable timer, and one was based in software off of the CPU clock.  There was nothing holding these two clocks in sync, so they could drift from each other.

In 8.0 and beyond, there is only one source of time in the system, so this problem disappears.

[Matthew_Williams]

Thanks Greg.  We saw this problem as a divergence between the FP Read.vi timestamp (hardware referenced) and the various
'get timestamp' .vis (OS referenced).  Our solution was to write the FP Read.vi timestamp to an LV2 global and reference
the global for all other time queries.  Worked just fine.  RT 6.1 - 7.1.

Matt

[Jimmie_A.]

Hello,

Depending on the HW used they will obtain the system time differently where some might obtain it from the host, a time server or by the BIOS at startup. Then a target can have multiple time bases and in later versions of RT a user have more control as shown in the document below that refers to the cRIO 900x controllers.

http://digital.ni.com/public.nsf/allkb/5B1A53C9A9B46D48862570A00067C913?OpenDocument