05-31-2018 12:53 PM - edited 05-31-2018 12:54 PM
I want to record large amount of data in continuous mode, using a PCI 6110 and DAQ-assistant VI. At this point, At this point, I'm willing to dynamically change the buffer size, but I'm not sure if this is possible or if it will affect how data will differ between different sizes of the buffer.
At a high rate and high number of samples, after I start the VI, sometimes it returns a buffer overflow error, other times a not enough memory error. I'd want to know if dynamically changing the buffer size is achievable and how this could be done, or at least to determine a method to find a buffer size that is stable and won't overflow or throw errors during data acquisition.
And also it takes about 12 seconds to display the elapsed time and update graphs, meaning that it takes 12 seconds to run one iteration of the while loop. Is this delay due to low performances of the PC or writing time required to write data on to the hard drive? If neither of the cases is true, I wonder why it takes so long?
I can't tell to much about the PC because I don't have access to it right now but it pretty old and it has only 2GB RAM.
Data is collected from 1 channel with acquisition mode to "Continuous Samples".
I am grateful for any help I receive.
Thanks in advance!
06-16-2018 09:45 AM
Hi
No need to change buffer size instantly. Do not perform all operations within single loop.
Use Producer / Consumer Method
Producer loop : Implement Data acquisition
Consumer loop: Analysis and Data-logging.
06-16-2018 09:54 AM
Attach an actual VI instead of a picture and we can see how all of those DAQ Assistants are set. How many samples do you have set in that control and what is your acquisition rate?
06-16-2018 10:16 AM
I don't think telling a value for number of samples and a value for rate would be of any help because I can adjust those values such that program runs fine without any errors, but that was not the idea. Anyway, so far I was thinking to use a RAID system to increase the acq. rate and also take a look at what ram301090 suggested
06-16-2018 10:47 AM
But you came here looking for help. If you already knew what information would help or wouldn't help, you wouldn't be having problems and wouldn't be asking questions.
Knowing how much data was being collected in a DAQ Assistant on each iteration and how long it would take goes a long way to figuring out why there are memory or timing issues. You talk about "high data rates" and "high number of samples", but without actual numbers, it is hard to know if you have a problem or not. What you consider "high" may not be that high at all.
The advice of looking at producer/consumer is a good one. I'd also advise getting rid of the Express VI's and using real DAQmx VI's. I wouldn't go chasing after fancy RAID systems until you've established the scope of your problem and applied all of the easy solutions.
06-16-2018 10:53 AM
Follow RavenFan's advice.
Using real DAQmx VIs, not express ones, along with a few advanced ones, I am able to continuously record 8 channels at 2MSa/s to an internal disk of a laptop, along with displaying the data. Note that I decimate the data before displaying it. You do not need a raid system.
For streaming data directly to disk I recommend using the built in DAQmx logging functions, most efficient and fastest.
mcduff
06-19-2018 05:25 PM
I try to record acoustic emission signals, and continuously recording them demands a large amount of space to be stored on, and I also need about 2Msamples/sec, otherwise it will be of no use. I most likely don't have a correct intuition about how that VI(posted as image) works and that's why I doubted the help that would bring some concrete values for sample rate and number of samples.
I took the raid system idea from a paper that also intended to record large amounts of data at a high sample rate, and that's why it came into discussion, but if you say it no need for that then it fine for me.
I don't have a clear view about how to use real DAQmx VI's instead of express one, but I'll take a look and try to implement.
Again, I don't always have right away access to the equipment and what is even more unfortunate, I am not in country so I'll be able to provide feedback only when I get back.