sampling/writing data not working properly

[MEMEPANE]

I am having trouble understanding why my LabVIEW VI is not sampling/writing data at the interval I expect.

            

I am using a DAQ setup to measure force from a load cell. The force measurement task is currently set to 1 Hz. In my VI, I have a parameter called “Number of Samples,” which I use to decide how many samples are averaged before writing one data point to file. I also have a “Sample Window” parameter that I intended to use as the writing interval.

For example, when I set:

• Force measurement rate: 1 Hz
• Number of Samples: 2
• Sample Window: 3 seconds

I expected the VI to average 2 samples and write data approximately every 3 seconds. However, the actual writing interval becomes about 6 seconds instead of 3 seconds.

Increasing the force measurement rate does not seem to solve the issue.

I am wondering if there is a conceptual mistake in how I am combining “Number of Samples” and “Sample Window.” Is it possible that the DAQ read is waiting for the requested number of samples first, and then my sample window/wait time is adding another delay on top of that?

I am also concerned that my current data writing method may be inefficient. If the VI opens, writes, and closes the file every loop iteration, could that slow down the loop timing significantly? Would it be better to use a producer-consumer structure, buffer the data, and write to TDMS or CSV in a separate loop?

I attached my VI. I would appreciate any advice on:

1. Whether my DAQmx/DAQ Assistant timing settings are causing the longer-than-expected write interval
2. Whether “Number of Samples” and “Sample Window” are being used redundantly
3. Whether my file-writing structure is inefficient
4. What the recommended architecture would be for reading force data continuously, averaging a fixed number of samples, and writing at a controlled interval

Thank you!

[Bob_Schor · Accepted solution]

Welcome to the LabVIEW Forums.  Thanks for attaching your code.  Unfortunately, your code uses LabVIEW 2025, which means only those users of the Forum who have installed the latest two versions of LabVIEW (I'm running 2024, myself) can open your code.  Fortunately, my "work" computer has LabVIEW 2025, which has allowed me to explore your code a little, and make what I hope are useful comments. 

Here are some questions I'd like to ask:

• Am I correct that you are making two kinds of measurements for 8 sets of hardware?  If so, I strongly recommend that you begin by writing a much simpler, smaller routine for one piece of hardware that measures force (the Y axis reads "Pounds") and another piece that records temperature.  That will be much easier to lay out (many fewer wires!) and easier to troubleshoot.
• Have you used MAX to "play" with your hardware?  Can you plug in one Force transducer and one Temperature transducer?  Do you know how to open MAX and set up a Test Panel where you can test, say, the Force transducer by setting up the input parameters to measure Force in whatever units you need and sample at whatever speed you want to sample?  And the same with Temperature?
• It is not clear to me the nature of the data you are trying to acquire and the hoops through which you have to jump in order to get your data.  I'll explain in a bit ...

Tell us something about the phenomena you are trying to measure.  What is the nature of the Force, particularly how does it vary with time?  You seem to be measuring things that change slowly (over seconds, as opposed to many times per second).  Are both Force and Temperature varying at similar rates, and do you want to measure them at the same time?

Let's talk about "time".  LabVIEW is interesting because "Time" is part of the language.  Can you tell us a bit about the signals (Force and Temperature) you are measuring and how they very with time?  I presume you know that when you take multiple measurements of a signal and average them, you are (in effect) creating a temporal "filter" that distinguishes slowly-varying "signal" from high-frequency "noise" (sometimes called a "low-pass filter".

Looking at your code, I can't figure what you consider the "signal", and how you are extracting the signal from the measurements you are taking.  Your DAQ Assistant parameters suggest you are gathering 150 samples 1 second apart, which means a "measurement" takes 150 seconds = 2.5 minutes.  That doesn't make sense to me.  You are also using the DAQ Assistant, rather than using DAQmx itself, which once someone explains how easy it is to understand (it helps to have someone show you, once) is much more straight-forward.  

Most National Instrument hardware are designed to take samples at periodic times (say 10 times/second, 10 Hz) for some number of samples (say 10 samples).  If you put a DAQmx Read inside a While Loop and start the loop running, (almost) exactly once each second, you will get exactly 10 samples, usually output as an array of 10 floats, that will appear once/second until you stop the While loop.  No timing loop needed, the NI hardware does it for you.  Much simpler code!

But there's more!  Think about this While loop -- once/second, it spits out 10 points, which maybe takes 10 micro-seconds.  What does it do with the remaining 0.999999 seconds?  Anything you tell it to do, as long as it finishes in time.  This can include averaging the data and placing them on a Chart to display (of course, you need to do this inside the While loop, as I'm sure you know why).  This is called "See your Cake, Plot it, Save it, and Eat it, too".

Start with the Test Panels in Max.

Bob Schor

[MEMEPANE]

Hello Bob,

I appreciate your valuable comments! Ever since I got a comment from you, I have "played around" with the file from scratch. I eventually succeeded in lowering the sampling time to 2 seconds stably.

However, I still have not gotten the 1-second sampling. Even if I input a 1-second sampling window, the data interval is around 1.2 seconds.

Do you have any suggestions for this to get it more efficient? Please refer to the attached file.

[Bob_Schor]

---

@MEMEPANE wrote:

Do you have any suggestions for this to get it more efficient? Please refer to the attached file.

---

When my children were quite young, their mother would play on the piano and sing a Muppet song called "And the Word is No".  Well, I'm going to sing (in response to your question) "And the Word is Yes".

You have one While loop that does the following:

• Acquire 50 force measurements from 8 channels at 1 kHz
• Acquire 50 temperature readings from 6 channel at 1 kHz
• For each of the 14 channels, convert the data from Dynamic Data to a 1D Array of Dbl and take its mean.
• Plot these means on Charts and Indicators (wires are everywhere, difficult to see/understand what data goes on what Chart).
• Optionally write the data to a Measurement File.
• Wait at least 1 second before repeating the While Loop unless "Stop" is true when the loop starts.

The Third Law of Data Flow says that a Structure cannot finish until everything inside it has finished.  You have 14 A/D samples to take (each takes 50/1000 = 50 ms, but they can probably run in parallel if the DAQmx hardware permits this).  Now you have the packing/unpacking of the weird Dynamic Data Wire (present because you are using the Dreaded DAQ Assistant (DDA), instead of simple DAQmx, though it is a little more complicated because you are saving the data in "units" (like temperature in degrees C, force in pounds).

What you should do is to make a copy of your current VI, and call it "Test" or something.  If I were mentoring you, I'd immediately say "Get rid of the DDA, and use DAQmx (have you read "Learn 10 Functions in NI-DAQmx and Handle 80% of your Data Acquisition Applications"?  Ask Google to find it for you).  But never mind, in Test, create one DDA and one temperature or force sensor.  Why sample at 1 kHz and average 50 points?  Simply take 1 sample at 20 Hz.

Note that when you are continuously sampling (as you seem to be doing), you set the Timing to "Continuous" (not N Samples).  With Continuous at 1 kHz and 50 samples, you will get an "array of 50" 20 times /second, and all you have to do is take the mean of this array to "down-sample" it to 20 Hz.  Best of all, the A/D "Read" can (all at once!) read N Channels N Samples, so with a single A/D Read, you get your 50 samples from (say) 8 Channels and you can do all of the means at once.  Note you may need to transpose your 2D Array -- you want to average 50 samples over 8 channels (and get 8 means), so if you get 50 means instead, transpose the 2D array before taking the mean.  

Now for the biggest trick -- have you heard of the Producer/Consumer Design Pattern?  You have two loops running in parallel.  One "Produces" data at some rate, and hands the data off to another loop that "Consumes" it (say, it plots it and saves it to disk).  The Producer runs at a fixed rate, but the Consumer may, on occasion (say, while opening a bunch of files,) need a "little more time".  The "trick" is that the data are sent in a Queue, or a Channel Wire, that have some "flexibility" -- they can grow or shrink as needed.

This may be more than you need, right now.  I suspect that you'll get a lot more "mileage" out of redoing the DAQmx part of your code.  As I mentioned, I don't know your hardware, but one way to teach yourself about the hardware is to open NI-MAX, plug in your hardware, and run some Test Panels.

I hope this is a little helpful. 

Bob Schor