Error 200279 Continuous DAQ Assistant

[trekRAM17]

I am getting Error 200279 while running my VI.  I am using a DAQ assistant with four channels set to Continuous Samples with a rate of 1K and Samples to Read at 100.  The error comes up at different times.  It can happen right after starting the vi or it has happened as late as 2 1/2 hours of running the vi.  I added the DAQmx property node to observe the number of available samples per channel.  The number of available samples is stays at 0 but then will spike in a few seconds until it goes over 10,000 available samples and the error pops up.

I'm at a loss as to what might be causing the sudden spike of samples because the program does the same calculations each iteration of the loops.  Therefore, I don't believe the program is running to slow to read the samples.

Thanks for the help,

Tony

[RavensFan]

Post your VI so we can see what you are doing.

There is something happening that is causing the VI to periodically slow down.  Are you writing data to a file?  Could Windows be kicking in and doing something like running a virus scanner?  Windows is notorious for doing things when you don't want it to.

[trekRAM17]

I am writing to a file called datalog.csv.  At first I thought it might have been the cause.  When I got the vi, the data is recorded to datalog.csv at a period determined by an input, Sample Rate.  The fastest I have written to the file was 20 ms (50 times a second) which meant the program was opening, writing to, and closing datalog.csv 50 times a second.  So I did change how the data was saved by moving data writing to a separate loop and by only opening the closing the file once. but I still got the error, so I changed the program back to the way it was.

a little bit of input on the vi.  it is for controlling a tesile strength tester.  it controls the amount of tension is being pulled on a powerline cable.  the controller in the vi is the bottom loop.  writing to datalog and the data acquisition are located in the top loop.

Thanks

[RavensFan]

Ouch.  Way too busy and cluttered of a block diagram.  Way too many property nodes and local variables.  Some (most, all?) of those property nodes execute in the UI thread, so if Windows slows down the update of the user interface for some reason, those property nodes will slow down also.

I don't see where you are passing data from one loop to another.  I don't see any queues.  I see at least two loops that are very busy and both of those have file reading going on in the (Read from PNG file.)  Nothing changes, so is it really necessary to read the same files each an every time in the loop? Do the files themselves ever change?  You read from the same spreadsheet file.  Also, you have a case where you write data to a spreadsheet file and then read it right back in.  Why?  Just continue using the data you wrote out to the file, it doesn't make sense to read the same data back in.

File access and property nodes are two of the frequent culprits for slow running code.

You could probably replace some Express VI's (such as select signals) with lower level functions.  Express VI's make it easy to program things, but they don't perform as well as more native LabVIEW code.

And please consider creating some subVI's to consolidate some code into smaller well-defined modules.