How do I avoid starving the interrupt which keeps OS time?

[JoeSecurity]

I have a RT application running on a PXI8175 controller. My TCL appears to be starving the interrupt which keeps OS time. I need accurate time in order to date/time-stamp LVM files. Is there a way to keep accurate OS time while running a TCL?

[Stephan_A]

The RTOS updates time by servicing an interrupt that occurs about every millisecond due to a timer tick. When running a VI with Time Critical Priority, the RT Engine does not update the system time when the timer tick interrupts occur, because this would cause jitter. This results in the RT Engine's system clock falling behind or even stopping. The time returned by subsequent functions (such as T0 in a waveform data type, or the number returned by "Get Date/Time In Seconds") will be incorrect. There are several other options for reckoning time besides using the system time. Two will be discussed below.

Hardware Counter
Before running any Time Critical VIs, start a hardware counter, which counts an internal time base. Then obtain a reading from both the counter and the system time. After that, use only the counter to reckon time, and mathematically compute the elapsed time based on the counter reading, and add that elapsed time to the time first read from the system time. Remember that the counters roll over, and that you must account for that. For instance, when using a 24 bit counter with a 100 kHz internal time base, the counter will roll over in about (2^24/100,000) seconds (about 167 seconds).

Tick Count
Even though the RT Engine loses time, the timer tick count does not loose ticks. Every tick count is not exactly a millisecond, but actually 1.000686 milliseconds. Before running any Time Critical VIs, obtain a reading from both the tick count VI and the system time. After that, use only the tick count to reckon time, and mathematically compute the elapsed time based on the counter reading, and add that elapsed time to the time first read from the system time. Remember that the tick count rolls over after about 49 days, and that you must account for that.

Note: System time can skew from actual time as much as 5 to 30 seconds each day depending on how accurately the crystals, which generate system time, are tuned. Some systems, such as PXI Controllers, maintain the time while the power is off with a Real Time Clock that is more accurate than the system clock, but which can still skew up to 2 seconds per day. The BIOS obtains its time from the Real Time Clock on boot up.

[JoeSecurity]

Thanks for the quick reply. Great answer, sounds a little complicated. Is there an example VI anywhere that I can examine?

[Stephan_A]

Unfortunately, not that I know of. Sorry.

Regards

[JoeSecurity]

Would the use of an occurence within the DAQ section cause a delay long enough for the clock interrupt to be serviced? Or do occurences not allow other system interrupts to be serviced.

[RobCole]

So this begs the question: is there a way that we can read the Real Time Clock instead of the system clock?

We have tests that run for days (on PXIs) and end up with the time being hours out. A VI that would read the Real Time Clock would be a lot easier to drop in than changing how we work with time and doing a bunch of calculations.

Rob

[AlexDubya]

Yes you can call two functions that will let you compute the time. If you have LV8.2  (maybe lower but thats what I have) and LVRealtime navigate to

C:\Program Files\National Instruments\LabVIEW 8.2\Targets\NI\RT\vi.lib

In there open rtutility.lib

Using several of these VIs you can construct several useful features like benchmarking code and timers.

At the core of these VIs are two functions:
void GetHighResTimestamp(unsigned long *tsH, unsigned long *tsL);
void GetHighResTimestampFreq(unsigned long *tsF);

These are both located in ni_emb.dll which is in the above directory. Unforunately, a .lib file is not provided so in order to call these functions from C (like I am trying to do) you must use LoadLibraryA() and GetProcAddress(). These can become complicated fairly quickly so if anyone has a working example of this I'd love to see it. I'm still debugging mine.

[Allan1]

Stephan A. wrote "Tick Count     Even though the RT Engine loses time, the timer tick count does not loose ticks. Every tick count is not exactly a millisecond, but actually 1.000686 milliseconds." 

Hi Stephan, this is the first time I have seen the accuracy of the Tick Count (ms).vi defined.  I have two questions:  Where does LabVIEW get this tick count?  My guess would be from counting the the motherboard's PIT 0 count, which is updated via the 1.931316666... MHz clock.  Is this true? 

I am also wondering if there is a similar thing in the Windows OS or in C++ running under windows.   I found if I call the GetTickCount function in kernel32.dll in Windows XP, it does not update every millisecond, but instead updates every 15 or 16 milliseconds. 

Thanks in advance,

Allan1

[tst]

---

Allan1 wrote:

Hi Stephan, this is the first time I have seen the accuracy of the Tick Count (ms).vi defined. 

---

You should note that this probably only applies to the PXI device mentioned earlier. I assume the numbers change depending on the machine.

As for the Windows thing, as you noted, its time resolution is about 16 ms (you can see this in LabVIEW by getting a timestamp), but as Stephan mentioned, you can compensate for this somewhat by using the tick counter and adding to a base time. I posted a simplistic example of this here. That thread also refers to using the performance counter in Windows to get microsecond resolution, but in any case, you should note that getting high accuracy in a desktop OS is a game doomed to failure.

[tst]

I see that the link I gave opens the LAVA forums with the threaded view, so here's the link again.