Data Acquisition in LabView Real Time

[snappy987]

I am trying to get a better idea of what is happening when I am acquiring data using LabView RT in comparison to using the DAQ assistant (which cannot be used in LVRT).  In the DAQ assistant I could simply tell it to acquire 300 Samples at a rate of 3000 S/s.  The buffer would wait for 300 samples to fill, I could then take those samples and average them in statistics to get nice clean data every 100 ms.  I am having trouble figuring out how to do something similar in LVRT.

I am presently using a data collection loop separate from my time critical loop running at 100 ms.  I don't tell it how many samples to grab so I'm assuming it just grabs the real time data point every 100 ms.  A number of data (pressure, temperature, flow, etc) is written to a cluster which is sent to a network shared variable (which is sent to the host loop).  If I run the host loop at 1000 ms (where I actually save the data into a spreadsheet) am I simply grabbing the 10th data point that the network shared variable is trying to send to the host?  Is there anyway to use LVRT in a manner similar to the DAQ assistant so that I can get smoother data.

[Roryriffic]

In LVRT and LVFPGA, you typically won't have the sampling rate, per se, like you will with DAQmx code.  The rate at which your timed loop executes will determine the sampling rate for your measurements.  With Scan Mode (no FPGA directly involved), you can actually specify the rate at which the scan engine runs and use this time in your timed loop.  For example, if you right-click on the RIO target in your project and select Properties, you'll see the Scan Engine category on the left hand side where you will be able to configure the speed at which it runs (up to 1kHz).  You could then configure your timed loop to run based off the clock source "Synchronize to Scan Engine".  This might not be so useful in your application if you've already got the loop configured for 100ms (10Hz), but it's a handy little tidbit for your future reference.

It also sounds like you might need to enable the RT FIFO on the network shared variable so that you don't lose any data when you read the variable from the Rio controller.  If you right-click on the variable in your Project and select Properties, you will find the RT FIFO category where you can enable and configure the FIFO.  By doing this, you will read the data points in a "first in, first out" manner on the PC side at the 1000ms rate you have specified.  For example, if you acquired the number 1-100 on your RT side, then it would take 10 seconds total (100ms*100samples).  If you then read from the variable on the PC side at a rate of 1Hz (1000ms) for a total of 10 seconds, then you would only display numbers 1-10. You would NOT display number 1, 11, 21, 31, ...

I hope that helps!

[Bob_Schor]

I'm a little confused about what you really want to do.  As I understand it, with the DAQ Assistance, you are using over-sampling and averaging to get "clean" data points every 100 msec by taking 300 points at 3KHz and averaging them.  You then talk about LVRT, but make it sound like you want to take single points every 100 msec and pass it to a PC -- this is a very different problem, one that doesn't really tax being time-critical.

So I'll assume you want to Have Your Cake and Eat It, Too -- you want to sample at, say, 3KHz, yet send "averaged" data at, say, 10 Hz (every 100 msec).  Here's, in principle, how you might do this.  Set up your data acquisition loop to run at 3KHz, and output the data to an RT FIFO that is, say, 100 points long (that's probably much too big ...).  In a parallel loop on the RT system, have a loop that pulls values off the RT FIFO, accumulating them until you get 300 of them.  When you have them all, pass them to your "Average-and-send-to-the-PC-via-a-Shared-Variable" VI (if you haven't written this as a sub-VI, now's a good time to do so!).  You'll be calling this "Send" VI at 10 Hz, and can expect to receive new data points on the Host PC at 10 Hz, as well.  Note that you can pull a similar "trick" on the PC, having a Receive loop that runs at 10 Hz (or faster), decides if there is new data (which is sometimes tricky with Shared Variables), then puts new data on a Queue that is to be "consumed" by the main loop running at 1 Hz.

BS 

[snappy987]

Thank you very much for your help.  I am new to LVRT so I am learning as I go.  I understand that my data acquisition is not time critical (I have a separate loop right now taking care of my time critical tasks).  

Bob, I am working on creating a solution similar to what you describe, it sounds like what I am looking to do, but I am having some trouble understanding everything.  If I am running my data acquisition loop at 3KHz this will be generating a new data point every 1/3000=0.0003333 seconds, and the RT FIFO (100 points long) will be filling up every 0.03333 seconds.  I would need to run the parallel loop at least this fast to make sure the RT FIFO doesn't fill up completely.  This parallel loop would be running and waiting until it received 300 values (this should happen every 0.1 seconds) so that it could pass data onto my averaging VI.  I hope I am understanding this correctly.  

My question now is how exactly do I pull the values off the RT FIFO until I obtain the desired amount, and then send this to my averaging sub VI?

[Roryriffic]

Quick question: how are you reading in the data into LabVIEW?  Let's say you're using a cRIO in Scan Mode, for example, then you'd probably have your modules configured in your Project underneath the chassis level of the cRIO.  On your block diagram on the RT vi, you'd have the I/O variables (channels on the modules) reading data in a deterministic loop.  If you created a shared variable with RT FIFO enabled (right-click variable from Project » select Properties » RT FIFO), then you could write the data from this I/O variable to the shared variable.  Then, in a non-deterministic loop on the block diagram, read from the shared variable and pass the values into the sub-VI.  The FIFO will ensure you don't lose any data points communicating between the two loops, but will help by keeping one loop deterministic and the other to do post-processing.

[snappy987]

At present I have my RT target VI which calls 2 separate VIs.  One is my control VI (deterministic loop) and the other is my data aquisition loop.  I have all of my measurements set up in the data acquisition loop using the channel from the chassis (30 or so different measurements), perform some math (converting voltage to pressure, etc), bundle all these values into a bundle by name cluster, than I pass this the cluster to my host computer.  The data from the target is then read and saved to a spreadsheet.  

I suppose that my biggest concern I am having right now is the fact that I am only pulling one value for each reading and measurement and my data is really ugly, not like I could get from using daqmx as I described earlier.  I have spent a good amount of time trying to find a solution to "average" data points but I am having terrible luck.  I just feel like there must be an easy way to do this.

[Roryriffic]

Hey snappy987,

Maybe you could post some of your code or screen shots that show how you're implementing this functionality?  In addition, a screen shot or two of what "ugly" data and good data is could also be helpful.  It really shouldn't be too difficult to do these readings, but I can definitely see how it could be confusing. Hopefully, there's some simple fix I can recommend.

[Bob_Schor]

Sorry I didn't respond earlier.  Here is a very simple example (simulating data) that illustrates one approach to averaging data.  The top loop is the "producer" loop where data are generated at a high rate (here 1 KHz, since I'm using the PC's clock).  The lower loop is the "consumer" loop that averages

the data.  Every 100 points, I plot a single (noisy) data point and an average of the previous 100 points -- the plots show the effect of the averaging.

The basic code pattern comes from the Consumer-Producer Template in LabVIEW 2010.

Bob Schor

[Bob_Schor · Accepted solution]

Oops -- don't know what happened to the snippet (maybe it was too big?) that I posted.  I'll attach the VI itself here ...

BS

[snappy987]

Guys, I have gotten caught up at work with another project the past couple of days.  I am hoping to get back to this sometime early next week and take a closer look at your comments.  Once again, I really appreciate the help thus far.