Dynamic data time lag

[Tomaz79]

Hi,

I have a time lag problem in my .vi. I have a producer loop which acquires data through the DAQ Assistant (16 analog channels, continuous acquisition, 100 samples, 1000 Hz). I have a Wait 100ms function in the loop.

I'm using a queue to transfer data to the consumer loop which does some calculations on the data. I noticed that when I run the .vi for a long time, the timestamp of the dynamic data (in the producer loop) starts lagging behind the system clock. The consumer loop is not to blame (as it shouldn't), since the queue size is always zero. If I overload the processor with other tasks, the queue fills up, but it clears steadily back to zero when I free up the processor. But when looking at the data on a chart, the effect of this lag is the same as it is when the queue is not cleared. The data doesn't catch up to "real time".

Any ideas what could be causing this? I don't know if this is relevant, but I initialize the queue with a scalar array, converted to dynamic data. 

Thanks for all your help.

Tomaž

[Tomaz79]

I tested my .vi on a different system and I get the same lag.

Anyone have a clue what's going on?

Thanks,

Tomaž

[DFGray]

There could be many things going wrong, but we would need your code to determine which of them it is.  Given the symptoms, my best guess is that your code is generating an initial timestamp and them simply adding to this as the data comes in.  Mismatches in the timing circuits of the data acquisition card and your computer then result in the drift.  Things which could contribute to this problem:

1. You have an older data acquistion board which has not been calibrated in awhile and the timing circuits are out of specification (please tell us what acquisition board you are using).
2. You are using a desktop operating system (e.g. Windows Vista or Linux) and are seeing the inevitable drifts between a real-time device and the desktop (i.e. you are not getting what you think you are getting).
3. You are using single-point acquisition and assuming constant timing between each of the data points while using a desktop operating system.

Without your code, it is not possible to really tell, but guess number three best fits what you have told us.  Post your code (or a snippet) and we can help you better.  Don't forget to post any subVIs we may need.

[Tomaz79 · Accepted solution]

I seem to have found the problem. There was a Wait(ms) function left over in the producer loop. Removing that seems to have solved it. The DAQ Assistant was continuously acquiring data. I thought that even with the Wait(ms) function the loop would get the data packet with the timestamp of the query, but it seems that data is buffering and it just sends the next packet in the queue. Am I making sense?

[DFGray]

Depending on how things were constructed, that could certainly do it.  I am glad you found your problem.

[Tomaz79]

Strange, now when I run the .vi for a long time, the Dynamic data timestamp is *overtaking* the system clock. It ran for about two hours and the dynamic data is ahead of the system time by about 30 sec. I'm really puzzled.

[DFGray]

Please post your code (or at least the acquisition part of it) so we can help you.

[Tomaz79]

Here's the code of the acquisition loop. In the second image, you can see that the dynamic data coming from the DAQ Asistant is "from the future".

[DFGray]

Given the information I have, you are probably seeing a drift between the data acquisition clock (on the DAQ board) and the system clock (on the motherboard).  However, the drift is a bit large (~0.4%/unit time).  Older, uncalibrated hardware in either place could cause the issue.  Do you sync the system time with an internet time server?  If so, do you see similar drifts when you resync?  If not, what DAQ board are you using?  Has it been calibrated recently?  Finally, as a long shot, what versions of the drivers are you using?  I vaguely remember an issue several years ago where one of our drivers was doing something to the system clock.  If your drivers are recent, this should not be an issue.