Intermittent Data Acquisition Error in a Simple VI

[curiositas]

I have what I believe is a pretty simple VI designed to acquire data from some cDAQ inputs, and performs some simple arithmetic operations every 1 second. I'd like to run the experiment for long durations on the order of 7 to 12 hours. However, I'm constantly getting a 200279: Unable to Keep Up with Acquisition in DAQmx error. Sometimes my VI will run for hours and hours without a problem, but other times it'll throw an error within the first hour, or even less.

Strangely, I've been able to run this VI before for over 24 hours without any error, so I'm a little confused about what's causing PC buffer to fill. From all of my searching online, I've gathered that the DAQmx Read VI in my loop cannot read from the PC buffer fast enough and the DAQmx is filling it up so fast that eventually it attempts to overwrite the data. I've started experimenting with learning the producer/consumer architecture in the meantime, but my colleagues assure me that it shouldn't be needed for such a simple VI.

What could cause my PC buffer to be filling up faster than the read function in the while loop can read it?

I've attached the VI (and a previous version save) that I actually run for my experiment (hopefully the default values are kept with the save). It's messy, but when I try to clean it up, somehow I always implement a bug so I wanted to provide what I'm actually working with as an example.

The VI's intention is that it reads in 2 DAQmx analog voltage inputs, a digital input (from a 1 Hz square wave), and a serial input from a weight scale. For every iteration of the while loop, it reads the inputs from the DAQmx and places them an array. At the beginning of every new cycle of the square wave, it calculates the RMS values of each array, sends a request to the weight scale and reads the response, updates the indicators, and writes the values to a file. Once the STOP button is pressed, the loop exists, and it closes the write file.

[johntrich1971 · Accepted solution]

First of all you really need to clean up this code. Subvis work nicely to handle bits of code which perform a single task. 

Next, your problem is likely with your file writing. If you drill down into the Write Delimited Spreadsheet File you will see that it is opening and closing the file each time. Your opening the file and getting the path doesn't prevent this.  The larger the file gets the longer it takes to do the write. Eventually it gets so that your write can't keep up. This would be the same even if you went with Producer/Consumer (I highly recommend learning that architecture) though it might manifest itself differently depending on your queue settings. I recommend formatting your data and writing it using Write Text File if you want to keep a text format, and then starting another file before the file gets too large. Another option would be to use TDMS. This has the advantage that you can set it up to do the file increments, and it's a faster write since everything is binary. There is an Excel add-in that allows you to view the data in Excel. If necessary you could always post-process the data from the TDMS file to create a text file.

[crossrulz · Accepted solution]

There are SOOOO many places here that could be slowing down your loop.

1. File IO is generally slow.  That definitely should be in its own loop.  To make it worse, the Write Delimited File is constantly opening and closing the file, making it even slower.  You could just format the data yourself (Array To Spreadsheet String) and then Write Text File to save the data using your file reference.

2. VISA communications is kind of an unknown in how long that will take.  You have the communication write buffer, the transmission, the instrument reacting to the command, the transmission of the data coming back, the communication read buffer, and then finally you reading it.  All of those can add latency.  So I would recommend moving the VISA communications into its own loop.

3. I see property nodes for a graph being used.  Those calls will cause the UI thread to be run, causing a thread swap.  This can also slow things down.  Why are you switching between the plots being displayed?  Why not just constantly show both plots?  I would even go so far as to have both plots in a single graph.  This would eliminate 2 property nodes being called every iteration.

[curiositas]

---

@johntrich1971 wrote:

First of all you really need to clean up this code. Subvis work nicely to handle bits of code which perform a single task. 

---

Understood, thank you! If I make subVIs and then save the main VI and post that here in the forums, can others download that VI and open those subVIs, as well? I wasn't sure that would possible, so I uploaded an older version without subVIs.

So, from @johntrich1971's and @crossrulz's responses, I feel like I have some good suspects to chase down. I've suspected that the file IO and serial communications may be the problem. I have done some testing with the file IO out of the loop, but I was still getting errors. Maybe, the serial communication was causing a problem. I'll try some more testing and try to report back what I find.

Thank you very much!

[johntrich1971]

---

@curiositas wrote:

---

@johntrich1971 wrote:

First of all you really need to clean up this code. Subvis work nicely to handle bits of code which perform a single task. 

---

Understood, thank you! If I make subVIs and then save the main VI and post that here in the forums, can others download that VI and open those subVIs, as well? I wasn't sure that would possible, so I uploaded an older version without subVIs.

---

Put all of the files in a project file and save the entire project, zip up the entire project folder, and upload it here.