DAQ MX waveform timestamps seem to be a function of timed loop rate

[Wes_Ramm1]

I have configured (what I think is ) a buffered DAQ application using the DaqMX tools, including the 'DAQ Timing (Sample Clock).vi.  I am telling the Timing vi to use the 'internal clock' as I want hardware Timing.  I am using simulated data, so I don't actually have a hardware clock, BUT, I am getting strange results, and I want to know whether it is due to the simulated data or whether it is due to me not understanding how to do buffered DAQ with DaqMX.

My DaqMX Read is being done inside of a timed loop.  My waveform timestamps seem to be a function of the period that I configure my timed loop for.  So, if I am acquiring 100 samples per loop iteration, with a daq rate of 1000 Hz and set my loop rate to 100 ms, I get spot on time stamps with a second in the waveform timestamp equallng a second on my stop watch.  If, however, I decrease the loop period to 50 msec, my time stamp 'seconds' are equal to one-half of a second.  If I go down to 25 msec, my timestamp 'seconds' are equal to 1/4 of a real second, and so on.

This indicates that the time stamps are generated in my loop somehow.

Like I said, I think that this is an artifact of using NI MAX to simulate data, but can someone confirm or deny this?

I have attached a scaled-down version of my vi for your purusal.

Thanks,

Wes

[devchander]

Hi Wes,

From the first glance what i suggest is, do not use 'timed while  loop' for continous DAQmx Read.

use normal while loop

regards

Dev

[Wes_Ramm1]

Dev, thanks for your response, but why do you recommend against the timed loop? 

Wes

[devchander]

Wes, Its out of my personal experience i recomment this  😉

Its like this, Your DAQ mx read, retrives data from the buffer on each iteration .

If your sampling rate is 1000, number of samples to read is 100 and you have set your timed loop to execute for 100 millisec.

DAq mx read operation should ideally take 0.1 sec. but some times this operation may take 0.09 sec, some times 1.1 sec( to be more precise, i observerd this with higher sampling rates and while retrieving larger chunks of data from buffer)

Now your timed loop forces your  DAq mx to read again after 100 m sec, and if your DAQ mx has not been able to retrieve all data from its previous loop, it give an error.

Whereas if you use a normal while loop, the loop control is with the DAQmx read and the next iteration happens only after DAQmx read finishes its current read operation.

[Wes_Ramm1]

Surely, however, the DaqMX Read call will do everything it has to do before it returns and the loop executes again.  The Loop cannot tell it's calling vi's how quickly to execute.  Therefore, if it were to take 5 seconds for the DAQ MX read to finish, the timed loop would simply 'finish late' by 5900 milliseconds.   For each call to the hardware (DAQ MX Read), that vi will try to read the points out as they become available. Whether it takes 0.9 ms or 1.1 ms, this vi will execute until all the points it is meant to retreive are retrieved or time out.  Is this not the case in your experience?

Wes

[Otis]

Wes,

You should be fine using a Timed Loop with your VI, but ultimately it shouldn't harm your application to have a timed loop around it.  As you said Timed Loop essentially helps you confirm exactly how long it took a loop to iterate, increasing the determinism of the system.

I tested an example (Cont Acq&Graph Voltage-Int Clk.vi) by changing the While Loop into a Timed Loop and ran it without any issue.  Additionally, when doing this the timestamps seemed correct too.  Evidently you might just be noticing behavior caused by the Simulated Device.  It looks like things should work in your overall application as expected.

Carry on,

[devchander]

Hi Otis,

Let me explain the reason why i suggested against the use of while loop.

Kindly suggest me if there is way to to get over  this error i encountered.

"My application had all acq ranging from single card acq to a multi card sync acq with  5 E series DAQ cards on seperate  windows as well as  RT system.

They were working fine, but once i chaged it to timed loops, te application would run for something like 2 minutes and then give buffer errors.(both in windows as well as RT)

I tried all the possible settings for buffer size and retrival from buffer, but once i chaged back to normal while loop, all fell back to normal state."

This discussion may not be answering Wes's problem, but it might serve as a pointer nevertheless. 😉

So, Otis, plz do give your suggestion.

Regards

Dev

[Otis]

Hi Dev,

I think what may be going on there is that you may have set the wrong time for the period of the Timed Loop.  You need to make sure that the time for the Timed Loop is equivalent to the period for the measurement (Sampling Rate/Samples to Read).  If the period of the Timed Loop doesn't match the measurement period, then you will definitely get buffer overflows (or underflows if doing some Analog Output operations), which sounds like what may be the case for what you were seeing.

Hopefully that will help you to be able to use the Timed Loop too.

[devchander]

Hi Otis,

I have done all this checks/settings and only then, did i decide against using Timed While loops for acq.

And as i told you if this is the case, this period of the Timed Loop and period for the measurement   mismatch should start reporting errors right after few iterations.

But as i explained, this error starts showing up only after an interval of say like 2-3 minutes or more.

Any thing else u suspect?

regards

Dev

[Otis]

Hi Dev,

One thing that you could do to try and see what is going on is use a DAQmx Read Property Node.vi (Measurement I/O > DAQmx) to look at how many available channels per sample are still available after you do your read operation.  If that number slowly grows, then it should indicate a possible buffer overflow.  When I ran this I didn't notice a problem, but it could also be system dependent.  If you are still having problems, maybe you could share a snippet of code that still shows the same behavior.