data collection skips every 0.5 second

[hhart]

Hi,

I am using an NI9205 to collect load values from four different outputs in addition to an NI9236 for several strain values using the attached VI. For some reason, while recording for a centain number of seconds, I have noticed that the loads on the 9205 skip a single data point every 0.5 seconds. I have a recording frequency of 100 or 200 points per second, but the issue arises when I try to plot this data. The subsequent values move into the place where the gaps should be, so by the end of even a 3 second run, the load values and strain values are off by 6 hundredths of a second. When I export the data to an excel file, the load values do not cascade upward, but the gaps are still an issue, since they are visible on the line graphs plotted. I know it is not an issue with the DAQ because I ran a simmilar program in DasyLab that had no data skipping issue, but it only happens with the 9205 (not the 9236), so I am considerably confused here. 

Any help would be appreciated!

---

Save the sass, we're all just here for help 

[crossrulz]

How many samples are you reading with each loop?  It is possible you are not reading enough or fast enough.

[hhart]

I am reading 500 samples per loop at 1000 hz. The resample waveform VI reduces the data points down, and it works fine with the other DAQ.

[James.M]

You need to include your subVIs for us to run your code.

I suggest you add some Array Size functions to your code in different places to pinpoint where your data goes from 500 samples to 499.

[Bob_Schor]

In a single While loop, you are doing three things in sequence -- sampling data from a device, doing filtering, and writing the data to a Measurement File.  Sampling the Data is "timed" -- it has to happen "on time", that is, once you get the first N Samples, you must come back for the second N before too much time elapses (to make it ridiculous, assume you add a 1-hour Wait into this While loop -- you would expect to miss a lot of samples).

The solution is to use two loops, running in parallel.  The first only acquires the data, and hence (since it does nothing else) is ready when the next set of data present themselves.  It "exports" the acquired data (using a Queue) and sends it to the second loop for processing.  This now can use all of the acquisition time to do filtering, file I/O, etc., and as long as, on average, it is faster than the loop producing the data (called the Producer loop), you'll never have problems.  Even if the loop that consumes the data (guess what this is called!) runs a little slower, the data will just back up in the Queue, so if you aren't running for hours or days, you may still be OK.

To learn more about the Producer/Consumer Design Pattern for Data, open LabVIEW, on the File menu choose "New ..." (the dots are important), under From Template find Frameworks, Design Patterns, Producer/Consumer Design Pattern (Data), and study it, including the documentation.

Bob Schor

[altenbach]

• We don't have any of your subVIs, so we cannot test.
• You probably should not do the analysis and file IO in the same loop. Use a queue.
• Why is there no event for the stop button? (event loop cannot be stopped during recording, while the other loop can)
• Why does the stop button not have a label, make the use of local variables even more confusing.
• Instead of "init to defaults", just write to a local variable.
• Do you really need to chart 500 points each with a chart history of 1k? (not sure, since we don't have the subVIs) Maybe you only want to chart one point per iteration per chart.

Please attach the VI and all required subVIs in a zip file instead.

[hhart]

@Bob_Schor, Thank youso much for your help. That got me on the right track, i think. 

I have split up my VI into two loops, but at this point am a bit stuck on where to go. Although the record boolean is functional, when I try to look for my saved TDMS file it is not there. I'm sure this is a simple fix, but I have zero experience with this type of structure, so even directing me to helpful documentation would be appreciated. 

Here is a .zip of the project. 

[James.M · Accepted solution]

hhart, your consumer loop is dependant directly on your producer loop via the error cluster and queue reference. This means they will not run in parallel since the consumer loop will wait for the producer loop to stop before handling the queue.

Here's how the Producer/Consumer with a queue should look:

LabVIEW programming is based entirely on dataflow and parallelism. This is incredibly powerful and has lead to its success over the years (coupled with the graphical programming), but is usually one of the first things that new developers stumble over. Here's a simple resource to become more familiar with how it works. The Highlight Execution feature is a great way to watch how your application utilizes dataflow.

[hhart]

Thanks. 

Can you tell me what this is, though?

Sorry for being dense.

[crossrulz]

---

@hhart wrote:

Can you tell me what this is, though?

Sorry for being dense.

---

It is an array of waveforms.  The waveform cluster was just collasped to save space.