DAQ Assistant Acquisition mode N sample

[Iman87]

Hi

I have created a LabVIEW program to collect and save data from the 11 sensors using NI DAQ. I have also synchronized LabVIEW with another software. I actually wanted to calibrated my sensors with another device. So I synchronized the LabVIEW program with its software. 

I mistakenly adjusted the acquisition mode to "N Samples" instead of "Continuous Samples". Now, I have finished my data collection and found that the number of samples is less than the expected amount. For example, I have collected data for 113 seconds and it was supposed to have 113000 samples but I have around 104000 samples. I may not be able to repeated data collection. Therefore, I need to find a way to recover missed data. 

I set the Samples to Read: 100 and Rate (Hz): 1k.

I have the duration time for my collected data. I can use interpolation method to recover the missed data but I do not know where I lost data. 

How can I find where and how many of samples that I lost?  

Thank you for your help.

Iman

[Bob_Schor]

There are a great many "mistakes" in your code (if the goal is to record continuously until you say "stop").  For any serious data acquisition project (where you care about the data), you should learn how to use DAQmx, and not use the Dreaded DAQ Assistant and its evil twin, the Dynamic Data Wire.  Look up and read "Learn 10 Functions in NI-DAQmx ...".

Remember the principle of Data Flow.  You record 100 points, then you stop, write some data, plot some data (which takes time), and when it is all done, the loop finishes and you can take the next 100 points.  There is an obligate "pause" (of unknown duration) every 100 points.  It will depend on a lot of factors that you might be able to estimate, but it sounds like a very difficult problem to me.

LabVIEW allows you to have parallel loops that operate asynchronously.  Thus you could have one loop that only samples (even "incorrectly", N Samples) but does no processing, instead sending the Arrays (no Dynamic Data!!) to a Processing Loop via a Queue or Channel Wire.  The two loops will run at their own schedule -- in particular, the Acquisition (a.k.a. the Producer) Loop will run basically every 100 msec, while the Processing (a.k.a. the Consumer) Loop will run as long as it has Data to Process, using "spare cycles" to allow you to run both the Producer and Consumer loops at optimum speeds, largely with no loss of data.

Bob Schor

[Iman87]

Thank you so much for your reply.

However, I need to figure out how I may solve the current problem because I have collected data for one month.

Do you think that the gap is the constant? Can I assume that the gaps between every 100 points are constant?

Thank you

Iman

[Bob_Schor]

---

@Iman87 wrote:

Thank you so much for your reply.

However, I need to figure out how I may solve the current problem because I have collected data for one month.

Do you think that the gap is the constant? Can I assume that the gaps between every 100 points are constant?

Thank you

Iman

---

You can assume anything you want (that's the beauty of an assumption).  However, without a really compelling argument, backed by some data-that-I-can't-imagine-how-you-would-produce, I would believe the "alternative hypothesis" that you know nothing about the gaps other than their sum is nine seconds.

You have learned a very valuable, but painful, lesson -- don't wait until the end of a Project to check on the integrity of your data.  Your best bet would be to do the following (which you should be able to accomplish in a few days):

1. Fix your code.  At a minimum, you want Continuous Sampling and a restructuring of the code to ensure Continuous Data Saving.
2. Given your experience with "known bad data", you might consider simulating your Data Acquisition system to prove you aren't missing data.  I'll append a snippet of a routine that every 100 msec generates 3 channels of 1KHz "random" data and 3 channels of "Clock" data that simply "counts ticks" -- if you aren't "missing data points", the Clock channel will show no "breaks" (i.e. it will go 98, 99, 100, 101, 102 instead of 98, 99, 100, 106, 107).  Put this in place of whatever DAQ code you use, but keep the rest of the structure you adopt.
3. Get rid of the DAQ Assistant.  Do not use Dynamic Data Wires.  Your outputs should either be arrays of Waveforms (which will, now that I think about it, also let you estimate "gaps") or 2D arrays.
4. Along with using better DAQ code, use Consumer/Producer.  Demonstrate some mastery of LabVIEW if this is an important part of your work.
5. Take one data set.  Immediately examine it, make sure that it seems to be OK.  Try to make one channel a slowly-but-smoothly-changing waveform (like a slow sinusoid) so you can see (and verify) that you have no more "gaps".  Do whatever else you need to do to convince people (and yourself) that the data are valid.

Bob Schor