Why DAQ in an executable collects fewer samples?

[cubz]

Hi,

I have LV2012 on Windows and PXIe-6341 card in PXI chassis.

I have a DAQ task on AI-1 on my monstrous application. Well, to get to the point, I have there a case where the DAQ task starts, waits for 20ms, reads all available samples and stops the task. For settings see attachment. Then the collected data is plotted on a Waveform Chart. Usually around 200 samples are collected from the DAQ case. Then the mentioned sequence loops, until certain conditions are met.

Unfortunatelly a problem occurs, when I deploy a built (exe) application on a production PC some 600 miles away from me. 🙂

This is example of what I get on my development PC (both LV and runtime give similar results):

This is example of what I get on the production PC from exe (13 iterations, bad luck ;)):

It totally looks like the mentioned DAQ task grabs only one sample at a loop iteration.

I'm attaching a noodle dragged out of the main program. I'm about to test the build of this noodle on the production PC in a few hours, but I'd like to hear any ideas that emerge.

Thanks in forward!

[Bob_Schor]

There are some curious things about your sampling loop.  It looks like you are setting up to sample continuously, taking 40,000 samples at a time clocked at 10KHz.  You are using the A/D clock to do your timing (good!), so your While loop should "loop" every 4 seconds, delivering 40,000 samples each loop.  So why are you starting and stopping the A/D within the loop?  And why do you have "Wait" functions inside the loop?  Move DAQmx Start and DAQmx Stop outside the loop, get rid of the Waits, and it should run much more smoothly.

Bob Schor

[crossrulz]

Instead of constantly starting and stopping your task, why not just let it run?  And instead of having a wait, just tell the DAQmx Read to read X samples (how ever many you would need for your 20ms).  The DAQmx Read does have a default timeout of 10 seconds.

[cubz]

Thanks for the observations!

In my experience the "Continuous Samples" mode does not stop when the buffer is filled. The 4 seconds loop (with 10k samples/s into 40k sample buffer) --that is how finite samples work IMO.

Regarding the Start&Stop task inside the (20ms wait inside) loop: Actually, the difference was not significant on my machine:

The reason for having the Start and Stop inside the Loop is a long story, so just a few points:

- it is initialized as Continuous Sampling

- there is a library function used all over the main program that does the reading (start, wait some time, read samples, stop)

- sometimes I want a channel measured quickly for reaction to logical level change (within 5 ms), sometimes it is required to collect thousands of analog samples for evaluation

- there are other tasks running concurrently

Thanks for reactions, but the problem here is why the build of the application behaves differently than the development VI? And this only on the production PC.

[Bob_Schor]

Instead of stating, "In My Opinion" (IMO), the difference between Continuous Sample and Finite Sample mode, you could "do the experiment" with MAX.

I've got a USB 6009 hooked up to my PC.  I tell MAX to sample 4 Analog channels, 1000 samples a 1KHz, and set it for Finite Samples.  When I push "Run", it waits 1 second and then gives me 4 traces.  If I change to Continuous, when I push Run, it waits 1 second, gives me 1000 samples, and continues giving me 1000 samples every second.

Thus if I have it set for Continuous Samples, and put the "DAQmx Read" inside a While loop, put DAQmx Start before the While loop, put DAQmx Stop after the While loop, and put a Stop button to stop the While loop, this code will sample continuously at 1KHz, delivering 1000 points at a time, until I push the Stop button.

This is not "my opinion", this is what I see when I try it, and what you should also see if you tried it.

Bob Schor

[Bob_Schor]

---

@cubz wrote:

In my experience the "Continuous Samples" mode does not stop when the buffer is filled. The 4 seconds loop (with 10k samples/s into 40k sample buffer) --that is how finite samples work IMO.

---

Hmm -- maybe I was too hasty and misunderstood your misunderstanding.  You are correct that Continuous Samples mode does not stop when the buffer is filled, but it does return.  So if you only want one buffer's worth, just don't put it in a loop.

Generally, most data acquisition involves regular sampling at precise intervals over long periods of time, with the data being collected "on the fly".  For this mode, Continuous Sampling inside a loop is the way to go -- when you want to stop sampling, you simply exit the loop and "fall into" a DAQ Stop function.

BS

[crossrulz · Accepted solution]

---

cubz wrote:  In my experience the "Continuous Samples" mode does not stop when the buffer is filled. The 4 seconds loop (with 10k samples/s into 40k sample buffer) --that is how finite samples work IMO.

---

If the buffer is filled in Continous Samples mode, you will get an error.  I'm sure that is something that you just do not want.  In this example you have provided, you really should have Finite Samples and just tell the DAQ to read the N samples.  That is the only way to ensure you get all of the data you want.

As far as your differences between development and  executable, the executable tends to not have nearly as much happening (debug stuff mostly), therefore it tends to run faster.  If you are depending on a software clock, anything can happen (have a ton of data or hardly any).  This is why we are telling you to use the hardware clock and get the number of samples you actually want.

[Bob_Schor]

I suspect the confusion (at least on my part!) arises from the Poster not clearly saying what he (or she) wants to accomplish, but rather focusses on how to accomplish it (such as getting into the details about waiting so many milliseconds, etc.).  This was the initial description of the task:  " Well, to get to the point, I have there a case where the DAQ task starts, waits for 20ms, reads all available samples and stops the task. For settings see attachment. Then the collected data is plotted on a Waveform Chart. Usually around 200 samples are collected from the DAQ case. Then the mentioned sequence loops, until certain conditions are met."

So here is my question (again) -- What do you want to do?  I'm guessing (but I could well be wrong) the answer is something like "I want to record from N (4?) Analog Channels at S (Sampling rate) Hz for (some time or other criterion for stopping -- possibly # points, possibly "Until I push the Stop button"), plotting the data (and optionally saving it to disk as text, an Excel Workbook, TDMS, etc.)".

The code we've been seeing certainly doesn't do this, but then the poster clearly isn't happy about what it is doing.  So maybe a restatement of the True Goal is warrantted.

If I'm reasonably close in my guess as to the "real Want", then it is pretty easy to post some suggestions that will accomplish (some of) these ends.  However, without a clearer idea of the task, I'm not sure I'm making useful contributions ...

Bob Schor

[cubz]

Hi Bob,

you provided me a better review already than my colleagues sitting next to me, so I owe you a better specification of what is the goal. 🙂

And I need clever opposition as salt.

I basically have two types of Devices Under Test (DUT). One with analog and second with switching (low or high) output. The outputs are measurable as voltage level. Among other properties, there is a measurement procedure of the DUT with a metallic cylinder approaching the DUT. The DUT changes the output accordingly:

- analog DUT's output is declining,

- switching DUT's output, well, swaps levels.

Now, if there is a switching DUT, a quick loop with only 1 ms of wait() between start&stop task VIs. If a switch is detected, the actuator with the metallic cylinder stops and values from encoders read the position of the cylinder.

If there is an analog DUT, the metallic cylinder moves in steps and waits for the measurement of the output to finish. That is where the 20 ms measurement happens. I'm blindly following something like good practice of obtaining several hundred samples to gain some accuracy.

The DAQ task has 6 initialized channels. Sample rate set to 10k/s as a safe value found by trial&error. There were problems with some peaks appearing on higher rates. Buffer to 40k as large enough for one other test case requiring 3 seconds of acquirement.

So in one case of the program there is responsivity (is that correct word?) of the measurement, in another case is certain degree of accuracy of the measurement an objective.

overview table:

Well, now in the main program in development environment I'm getting around 200 samples or so (with 20ms), while in runtime I get only one. Which is only visible on the waveform chart, in the measurement file (TDMS) there is just average of this one value.

To try things out, I took the VI that I posted,

changed the wait time (between Start task and DAQmx read VIs) to a control,

built,

and uploaded to production machine.

The problem with only one sample being read did not occur. So the problem was not isolated by this VI.