PXI, RT get tick count skew.

[ashm01]

Hi there, here's a strange one again...

The application is running under labview RT and it executes a few set of instructions as mentioned below:

Behavior

There is a array of instructions which would contain which DAQ device, Channel, Value and time to execute in ms from T zero. This is one of the many tasks which include some disk IO and polling other communication buses.

Example :

SET DAQResource_1, value1, 100

SET DAQResource_1, value2, 400

SET DAQResource_1, value3, 500

SET DAQResource_2, value4, 500

SET DAQResource_1, value1, 600

We would parse out the array based of the cluster and write the values to the appropriate resource based on the time stamp from T0.

Now, the problem.

Below is the screenshot of the loop we use to wait in-between instructions. From the behavior we are observing that after a few mins of execution, the clock seems to be skewing and executing faster than it should.  We need to use the get tick count for a deterministic purpose due to the timestamp VI is not updated.

I displayed the delta time in-between the steps on screen and it varies +/- 1 ms and as much as 3 ms worst case on the plus side.

A while a go I ran into code being executed late due to the memory manager and inverse priority problems/starvation  in the early 7.1 days. Now, it is the opposite where it seems to loose approx 250 microseconds after every 60 secs of execution. If we run a long set of instructions, it simply does not correlate to the timings required.

Usually, people have problems running code which is late but the inverse seems to be true here.

I also tried using timed loops but this has not made a difference but for some strange reason, it would loose proper timing characteristics for the first 100-500 ms.

If I compensate the time by padding for every minute run then it seems ok but this is not a solution…

Any insight on reducing the jitter and ensuring it executes on time rather than early?

Regards,

Ashm01

Message Edited by ashm01 on 10-19-2007 11:20 AM

[Ben]

THe "wait for ms multiple" VI will only wiat unti lthe system tick is a multiple of whatever value you wired.

In your case, you have "1" wired. Since all numbers are ms multiples of "1" the wait never has to wait.

If your CPU is fast enough, you could get hundreds of iterations each millisecond.

Ben

[ashm01]

Hi Ben,

This is one of the issues also, I need to ensure that all instructions with the same execution time gets executed within the same time +/-1ms. I also have another version with a Wait delay with 1 ms also but its pretty much the same behavior...it also skews and  I cannot have anything more than a 1 ms wait.

Either way, no difference. Yes, I have fast controllers which need to handle many concurrent tasks.

Ash