Data Acquisition and Processing

[loneflyer18]

Hi everyone,

I am trying to collect Analog (Voltage) data from a DAQ continuously at sampling rate of 1kHz and 100 samples per acquisition. This limits my data collection while loop to run at 10Hz. I would also like to process the data (do some differential and averaging operations), however I would like to do so at a faster rate (100Hz). The differential has to be with respect to run time.

If I use two loops and a queue, the second loop's runtime depends on the first. How can I calculate the time differential of the data? Attached is the VI. I apologize if my problem isn't clear as I am relatively new to LABVIEW.

Thanks for any help!

[LocalDSP · Accepted solution]

There are several issues with the way you are trying to implement your applications and also it seems unnecessarely complicated.

While your first loop is timed by the DAQ acquisition and has as you say a loop iteration time of 100 ms, your second loop process as fast as it can and your 100 samples are likely "processed" very fast (way less than 100 ms). So there is probably no reasons to even use a queue approach and you should be able to run everything in the same loop. If not DAQ will complain. But of course the queue will work too if correctly implemented

So without the queue, if you add a For loop inside your acquisition loop and perform your processing point-by-point you should achieve the same functionality.

Next; Why are you using all those timers in your processing loop? They are not affecting the speed of the loop. Are you trying to show a point-by-point result in pseudo real time on your front panel? If you want a true correlation between your data sample and time us the timestamp information (to and dt) that comes with your data wire. You should see dt = 0.001 if you've sampled at 1 kS/s.

Some additional comments

In your lower loop you are indexing the acquired queued data array with the loop iteration counter. That will work the very first time but when you receive samples 100-199 your array will still be indexed 0-99 while your index input will require elements 100-199 ... no good

Why have you hidden all the terminal labels on your diagram? tough to debug and understand the code

[Kevin_Price]

It's not totally clear to me what you're looking to do, but there appears to be an awful lot of effort of spent on Tick Count time differences for data that is already hardware-timed by a sample clock.

Each time your acquisition loop reads a chunk of data, some of it is sent over to your analysis loop via queue.  As structured, you analysis loop is *necessarily* paced by the rate at which you feed that queue.  And I don't understand the desire to run it faster than the rate that it's being fed with data.  What else can you usefully do besides process what you've been fed and then wait for more?

-Kevin P

[loneflyer18]

Thank you so much for your reply and for looking into my VI. Apologies for being ambiguous with the question. I typed the question in a hurry, and I will try to explain now, in a detailed way.

The first loop is collecting data from a DAQ. The sampling rate and the number of samples limits the loop to run at 10Hz. Hence, after every 100ms, I get a 1-D array of 100 samples. This array is that of encoder values (Analog Voltages) of a DC motor spinning at a speed in the range of 20-100Hz. I want to generate a signal whose frequency is equal to that of the instantaneous angular velocity. 

The angular velocity must be calculated at 200Hz or more. If I use a global variable array, there is an increasing time lag between the data acquisition and the data arriving at the other loop for calculating the velocity. I did some reading, and found out that using a global array for sending data from one loop to the other is anyways a bad idea. Hence, I am trying to use a queue. Like you said, using a queue would limit the calculation loop to run at 10Hz as well. 

What do you suggest is a better way of carrying this acquisition and time differential operation? I hope my question is clear now. I'd appreciate any help! Thanks again.

[loneflyer18]

@LocalDSP - Thanks for that detailed reply. I am sorry for presenting the problem with a poor piece of code. I do not have much experience with Labview and just trying to get by to get this experiment working.

I had thought about the For loop inside the Data Acquisition loop itself, but somehow I was adamant on using another loop for the calculations and generating high resolution values with the SineCurvePtByPt.vi.

I was using the timers to simply test the iteration time of each loop. But thanks for letting me know about timestamping the data wires, I should seriously change that in my code. Before using a queue, I was using a global variable array adding all individual 100*1 arrays to it, with each iteration. So that resulted in a array that increased in size with each loop iteration, so using the iteration value to index search in the second loop worked. This obviously made my code inefficient and the data lagged increasingly over time. I OVERLOOKED THAT FACT WHEN I CHANGED IT TO A QUEUE IMPLEMENTATION.

Also, thanks for your other inputs. I feel very stupid on having missed out such details, but there wouldn't have been a better way to learn so much. I shall update this thread once the new implementation works. 

Thanks a lot!

[LocalDSP]

Still trying to understand what you mean with "The angular velocity must be calculated at 200Hz or more". Your data is acquired at 1kS/s and nothing prevents you to calculate the velocity for every sample so also at a rate of 1 kS/s. However you cannot avoid having a delay of at least 10 ms, since you have to wait for an entire record of 100 samples to be ready before starting processing (independently on in which loop you perform your processing).

 Do you just need at least 200 Hz (5 ms resolution) on your results (or graph) or do you also want to show a live display of approx 200 Hz, thus simulating real time processing?

 Your display will not update fast enough (not talking about your brain 🙂 )

So unless you acquire and process your data point by point, you cannot have a true real time behavior, but if you want to try a "true" 200 Hz update you could try to acquire records of only 5 samples (instead of 100). LabVIEW should be able to keep up a loop rate of 200 Hz, then process each 5 samples data set and return a single velocity result.

[loneflyer18]

---

@LocalDSP wrote:

Still trying to understand what you mean with "The angular velocity must be calculated at 200Hz or more". Your data is acquired at 1kS/s and nothing prevents you to calculate the velocity for every sample so also at a rate of 1 kS/s. However you cannot avoid having a delay of at least 10 ms, since you have to wait for an entire record of 100 samples to be ready before starting processing (independently on in which loop you perform your processing).

 Do you just need at least 200 Hz (5 ms resolution) on your results (or graph) or do you also want to show a live display of approx 200 Hz, thus simulating real time processing?

 Your display will not update fast enough (not talking about your brain 🙂 )

So unless you acquire and process your data point by point, you cannot have a true real time behavior, but if you want to try a "true" 200 Hz update you could try to acquire records of only 5 samples (instead of 100). LabVIEW should be able to keep up a loop rate of 200 Hz, then process each 5 samples data set and return a single velocity result.

---

By "calculating at atleast 200Hz", I meant to get at least 200 values of angular velocity in a second (5ms) resolution. By usiung a for loop inside the while loop, I am able to do so now at 1000Hz, which is EVEN better. The delay of 100ms is acceptible and unavoidable. 

The display has nothing to do with the problem, I guess I just made it appear more complicated. I could make this new implementation work, far easier than trying to use two loops. Thanks!