LabVIEW
LabVIEW memory full error
Hi Sara,
@SaraAl wrote:
The sampling rate is 1 Msps. However, halfway through the VI stops and labview gives: memory full error. I have attached the VI used.
Well, your sample rate is 200kHz - atleast that's the way you configured the DAQAssistent…
Generic advice: while the DAQAssistent is "nice" for quick&dirty VIs it should not be used for production system (or "high-speed applications" like yours). Use plain DAQmx functions as explained here or in all those example VIs coming with LabVIEW! (You already use DAQmx functions to read that DI channel: why not use the same for your AI data?
Also hiding a "Continuous samples" DAQ acquisition inside a case structure is calling for trouble as DAQmx will try to buffer new samples even when the case is not executed!
How fast is your consumer writing the data to the file? When it is slower than the producer loop then the queue will need to buffer data - which might blow up the memory consumption over time. Please check the queue status to detect growing memory consumption when running the next test!
Hi Sara,
so you deleted the only "senseful" part from your previous VI (those plain DAQmx functions) just to add one more DAQAssistent and a (senseless) TRUE constant before the case structure? Throwing in a sequence structure to enforce dataflow also shows lack of LabVIEW knowledge: why don't you use the error wire to ensure dataflow?
(Well, now you are reading 300k samples at 1MHz.)
Still the very same problem: how fast is your consumer loop? Does the queue grow over time?
Please check this using the QueueStatus function!
(I also recommend to replace all ExpressVIs by "plain" functions in your VI.)
One more recommendation: by using plain DAQmx functions you can also have the DAQmx task save all data directly to a TDMS file - without the need for a producer-consumer structure on your side!
If you write to a binary file instead of a text based one you'll write less data and the loop should keep up easier.
@Yamaeda wrote:
If you write to a binary file instead of a text based one you'll write less data and the loop should keep up easier.
The real problem with the current logger the OP is showing is the use of the Write Data Express VI. That VI is constantly opening and closing the file, which is SLOW. By opening/creating the file before the loop, writing inside the loop, and closing after the loop, you can GREATLY increase the write speed.
But I would go with GerdW's last suggestion, use the DAQmx Logging to stream the data straight to a TDMS file. That is by far faster than using a Producer/Consumer setup. But a caveat I recently ran into with that is the TDMS data is a little more complicated (highly optimized for write speed) and may not work with all TDMS tools.
@crossrulz wrote:
@Yamaeda wrote:
If you write to a binary file instead of a text based one you'll write less data and the loop should keep up easier.
The real problem with the current logger the OP is showing is the use of the Write Data Express VI. That VI is constantly opening and closing the file, which is SLOW. By opening/creating the file before the loop, writing inside the loop, and closing after the loop, you can GREATLY increase the write speed.
But I would go with GerdW's last suggestion, use the DAQmx Logging to stream the data straight to a TDMS file. That is by far faster than using a Producer/Consumer setup. But a caveat I recently ran into with that is the TDMS data is a little more complicated (highly optimized for write speed) and may not work with all TDMS tools.
Oh really? I assumed it was clever enough to keep the reference internally. Yes, constantly opening a file is slow.
