The application is not able to keep up with the hardware acquisition

[nikhilthoppil]

I have made a VI program for data acquisition for 2 accelerometers using the NI9234 module (Program is attached herewith). Initially, the program was working perfectly and it was saving the vibration data once every 60 seconds at the given sampling rate. But now the program is crashing into an error "The application is not able to keep up with the hardware acquisition" (the error message is attached). This error occurs after every 10 minutes or 20 minutes I run the program.

I have checked the NI community for the error message I had encountered. NI help is suggesting to use a "producer-consumer" design pattern. But I am unable to do this. Please help me out.

My requirement is to record one segment of vibration data (at a sampling rate above 20kHz) once in every 60 seconds. Preferably the program should also display the continuous vibration data in time series and power spectrum showing all frequencies. The LabVIEW file attached clearly defines my requirements. 

Please help me solve this issue.

Thanks and Regards

[dsb@NI]

Before anything else, take the wait out of your While Loop. Hardware will time your acquisition, and we don't need any extra waiting.

Are you intending to write all data for 60 s, or just the last 1 s block every 60 s (the way the code works now)?

How many files have you generated when the VI stops? Is it always the same? How much space do you have remaining on disk? If your computer is having to write files across hard drive because there is not enough contiguous space, that can lead to poor file write performance. What are your computer specs? Could this application be taxing your computer given all the other processes your computer is running in parallel?

Suggested producer-consumer architecture would help with intermittent file operations causing DAQmx error -200279. Refer to sample project for Continuous Measurement and Logging. Producer-consumer architecture by itself won't help if computer is unable to keep up with processing, out of disk space, etc.

FYI: I am able to generate hundreds of files using your code (taking out the Wait 😉). This leads me to infer that writes are getting slower on your machine after 10-20 writes (and/or that our computers have different specs), but I don't see anything inherently wrong with one-loop implementation.

[nikhilthoppil]

Doug,

Thank you for your reply. I will definitely try it without the 'wait', but I have already tried with a wait value of '1' and still, the program crashed into the same error. Initially, the program was running perfectly, when I used to run the program continuously for at least 2 hours, and similarly 6 to 8 times a day making around 1000 files. It worked well for the first 3 days, since when it started crashing into the error message mentioned before.

For the questions you have mentioned:

I need to write only the last 1 s block every 60 s.

The program is generating exactly one file for every one minute. Usually, I run the code for around 2 hours for vibration monitoring purposes. 

All the files are being saved to the c: drive of my system. It is having a disk space of more than 500GB.

I am using a system with an intel i5 processor, 4 GB RAM, 2 GB Graphic Card, and a total hard drive of 1TB.

I never ran any other applications during data acquisition using LABVIEW.

Thanks & Regards

[dsb@NI]

Initially, the program was running perfectly, when I used to run the program continuously for at least 2 hours, and similarly 6 to 8 times a day making around 1000 files. It worked well for the first 3 days, since when it started crashing into the error message mentioned before.

---

Even though it doesn't seem like you have created enough data to fill your drive, I wonder if the disk is now fragmented. Could you diagnose and/or defragment the drive?

Or I will push the question back to you: what all could have changed since those first days of working 'perfectly' to now when you observe buffer overflow errors (-200279) after 10 min run time?

If you want to remove disk questions from the equation, change your code so that it never writes to disk; just acquires and computes FFTs. If you want to stress test writes to disk, change your code so that it writes every (or every other) block; if the problem is write/drive related, the error should happen much quicker.

As an alternative, you can also reconfigure your data acquisition to use Finite acquisitions to avoid error -200279.