Multiple Channel Express DAQ Assistant Multiple Sample Rates

[smoothdurban]

It a slightly modified version of what was posted earlier.

Also I was able to decimate the temperature data using Sample Compression which I am writing to file to compare what the file size savings would be. However this requires addional calculations and may slow down my program if implemented with extremely high number of channels and sample rates.

The other Write to Measurement File2 is the one which I implemented the changes as listed from your previous post.

[Ryan-C]

Thanks for the screenshot.  So does having two Write to Measurement File VI's, as in your screenshot, give you correct results?  If so, are you saying that it will not work for your purposes, because it ends up being too slow  for higher sample rates and tasks?  If you have several tasks, perhaps you could still group those ones with the same sampling rates together to minimize the number of Write To measurement File VI's.

Secondly, after looking at your task setup, I'm not convinced that you aren't actually just collecting both data lines at 500 Hz, since that is the last clock you set up.  You are getting the same total number of data samples for both data lines in the measurement file which you shared in your previous post, right?

Best,

[smoothdurban]

The  screen shot of the VI above is a modified version of the VI posted by Clarisa L.

Using two write to measurement files was for comparison purposes only.  The temperature data which is being collected at 500 Hz is being decimated to 10 Hz therefore creating a smaller data file the the data flow which is strictly being collected at 500 Hz.  I used the two write to file VI's to quantify how smaller the decimated file size would be.

Decimating data to lower file size would work for me.

My concern is if I have say 25 channels of data  and I am now collecting data at 1000 Hz then decimating 20 channels down to 10 Hz it will theoretically require more CPU time to decimate and essentially get rid of data I didn't want to acquire at such a high rate in the first place.

I would like to group the same types of tasks at different sample rates.  This would bring us full circle to my original post, of finding a way acquire different tasks at multiple sample rates.

[Ryan-C]

Thanks for the screenshot.  What seems to be happening is that the second Sample Clock is overwriting the first one.  I was going to suggest that maybe you create parallel tasks; however, I was checking some of the documentation for the hardware you are using.  Based on this spec sheet, it seems that you only have one system clock with this chassis.  Do you agree?

If this is the case, decimating the data is going to be your best option, if not ideal.

Best,

[Carisa_L · Accepted solution]

If you're using one controlling card then the two SCXI modules will have to run at the same rate. Alternatively, you can use 2 controlling cards (one for each SCXI module) and run them in parallel to acquire data from the SCXI modules at different rates. Hope this helps!

[smoothdurban]

@ Ryan

Yes this is what appears to be happening.  The last clock is overwriting the first.

@ Carisa

Using individual controlling cards for each type of SCXI module I need is not a viable solution as in some instances I need to use 5 or 6 SCXI cards for testing.

I was able to use the DAQ Configure Logging (TDMS) .VI which ended up logging all channels at 1000 Hz but the file size is 25% of the size when compared to the decimated data using the Write to measurement file VI.

My only problem no is I don't not know how to start and stop logging to the TDMS file as well as decimate data when using the DAmx Configure Logging .VI

Should I start another post?

[Ryan-C]

Hi again,

Glad to see that we're getting somewhere now!  For TDMS Logging, I think your situation may not be cut and dry enough to use the DAQmx Configure Data Logging (TDMS), since you would like to decimate the data instead of automatically just letting the DAQmx functions write the data to TDMS.

First, I wanted to figure out why you have DAQmx Read inside of a while loop?  If you are looking to capture only 200 samples per channel (and then stop), you do not need to run that DAQmx Read more than once.  You should check out the example called "Acq&Graph Voltage-Int Clk.vi" in the NI Example Finder (go to Help > Find Examples... and then Browse to: Hardware Input and Output > DAQmx > Analog Measurements > Voltage.  This is the most simple example of acquiring multiple samples on multiple channels, hope it helps.

Second, is it possible for you to just write all the data to the TDMS, and then parse it (decimate it)?  If this was an option, you could ceratinly use the DAQmx Configure Data Logging (TDMS).vi; in fact, I direct you to two examples in the same directory as above, "TDMS Logging - Log and Read Data.vi" and "TDMS Logging - Log Data Only.vi", which really are quite simple.

If decimation of the TDMS file during post-processing is not desired, you should be able to just use the Write to Measurement File as you appear to be doing.  I would encourage you to also check out the TDM Streaming Palette in LabVIEW (Under Programming > FIle I/O), which will give you more control to customize your TDMS file (compared to the Write to measurement File).  There are plenty of examples using this as well; search for "TDMS".

Best,

[smoothdurban]

Hello,

I have the DAQmx read inside a for loop because I am reading multiple samples sets.  My test takes nearly 32 hours to complete and I need to a few gigs of data for each test iteration.

For some reason when I use DAQmx Configure Logging VI I am able to log 1 minutes worth of data at about 950 kb of memory per minute and when I use the TDMS .VI's (Open, Write and Close) the same amount of data recording requires nearly 3.5 MB of memory per minute. 

Even when the data is parsed using the TDMS VI's it is well over 3 MB / min which creates a rather large file size when acquiring 32 hours worth of data.

I have verified that no data sets are lost between using  the two types of recording methods via DIAdem.

Using the TDMS configure logging seems to be more desirable as I am able to decrease the data set size by almost a factor of 4.  I would like to be able to write to the TDMS header information however the TDMS configure logging VI does not pass the open TDMS file value nor can I open it once I start my DAQmx tasks.

Ideally I would like to find a way to decimate the data being recorded as I still don't need such a high sample rate for 50% of my data, as well as adding TDMS header info using  the DAQmx Configure Logging VI. 

I have perused through the TDMS exampels and none seem to achieve what I am trying to accomplish..

[Ryan-C]

I don't see an obvious workaround because the Configure Data Logging is intended to be such an automatic hands-off type of function.You might consider creating a new thread for this one; I'd be interested to see if any workarounds come up.

Best,

[smoothdurban]

Thanks for your help Ryan!

Sometimes it helps just to bounce ideas off of each other and I appreciate your time.