LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Buffer Overload Issue -200279

Solved!
Go to solution

Hello,

 

I've been having issues with this -200279 error for over a week. It relates to a buffer overload. I have read everything available and have tried to apply it with no success.

 

I'm attaching the VI with the error called "Debugging" along with two sub-VIs to run the code. I notice the error when I walk through the code using Highlight Execution, but I haven't been able to find what is causing the error. 

 

I'm using a simulated cDAQ 9174 and two NI-9214. In my application they appear as cDAQ3Mod1/ai0..etc, but feel free to change the name for use with physical channel name. 

 

I would be grateful for any help or advice on the VI. Thanks in Advance. 

0 Kudos
Message 1 of 18
(1,941 Views)

Does this error come up right away, or does it take some time to develop?

 

A couple tips to start.

 

Don't use local variables in your loop.  Use the actual terminal.  Local variables can be a bit slower to work with than the terminal.  Where you initialize a control, use the local variable there.  Slight slowness won't matter.  Where it does matter is in the loop. Let's say it takes a 10 milliseconds longer to write to a local variable than to the terminal.  Will that time savings be better spent on a one time operation (initialization) or something you do repeatedly in a loop?

 

Second,  why do you have a 1000 millisecond delay in your loop?  This may be the cause of the problem.  You are already controlling the loop rate by reading 1000 samples at a time with a 1000 Hz clock rate on the DAQ loop.  If you have some delays in  processing the data, but you are still forcing a 1 second loop rate, you aren't giving your loop any time to catch up in processing the growing data in your DAQ buffer.

 

Due some bench marking to see if any code is taking a long time.  Not much is going on in that loop, but the two spots that might be taking longer than you would want could be the For Loop processing the mean and also the green Data Location subVI.

 

Check to see if you are processing that 2-D array the way you want.  Are you trying to take the mean of 1000 samples for every channel, or the mean of your channels for every 1000 samples?  Off hand, I don't know what way that 2-D array is laid out when it comes out of the DAQmx read, but you might be auto-index off the wrong part of the array.  Put an indicator on that inner For Loop's N terminal and see if it is executing 1000 times or 32 times.

 

I would consider moving that Get Date/Time String out of the For Loop.  You are only using the last value anyway no point have the PC create those strings every iteration when you are going to throw away all but the last one.  I'm assuming the Date/Time function can stay in the loop because you want to grab the time for when the data was captured, not while you are waiting for the data to be captured.  (Though which way is more accurate could be debated.)  Actually, if you acquired an array of waveforms rather than a 2-D array, you could just extract the date/time from the waveform which is certainly more accurate than the method you have in the situation where the buffer is slowing filling up.  That time will be wrong if you are working with data that was captured many seconds ago.

 

Also, it is a bad idea to be auto-indexing arrays on the output of the While Loop.  How long is this running before you stop the VI or you run into an error?  Those arrays at the tunnels are constantly growing until you stop the while loop.  If this runs long enough, LabVIEW must fine ever larger sections of free memory to put the arrays, and will need to shuffle the array data around to do so.  That can cause tremendous slowdown in the loop, your buffer will fill up.  And I like said earlier with the 1 second wait inside, it won't have a chance to catch up because you are only pulling the data out of the buffer as fast as it goes in.

0 Kudos
Message 2 of 18
(1,927 Views)

Hi RavensFan,

 

Thanks a lot for checking this out.

 

The error appears after the first iteration of the while loop. Although, when running without highlight execution it doesn't come up but freezes the code.

 

I tried each item you suggested one at a time. Then, adding them together too. 

i. I replaced the local variables with the actual control

ii. I removed the 1000ms delay.

iii. Verified that it's 32 samples in the For Loop

iv. I removed the Green subVI.

v. Move the date out of the For Loop.

vi. Tried removing the auto-index 

 

The error is still there. I attached the updated version of the code with the changes suggested. I put back in the indexes just because I think I will need them.

 

Any more thoughts? 

 

 

0 Kudos
Message 3 of 18
(1,796 Views)

I would expect a buffer overload in highlight execution mode. You are slowing down the execution of the code and it cannot keep up with the DAQ. 

 

I don't have LabVIEW 2020 so I cannot open your code (it is always a good idea to back save at least two versions when posting to the forum). Do you get any error when not in highlight execution? Are you perhaps getting an error that you are not handling?

Message 4 of 18
(1,906 Views)

@johntrich1971 wrote:

I would expect a buffer overload in highlight execution mode. You are slowing down the execution of the code and it cannot keep up with the DAQ. 

 


I completely missed that comment.  That will definitely cause that error.

Message 5 of 18
(1,901 Views)

Yes, you are right. The errors do not appear when I run normally. 

 

Originally, I started de-bugging the -200279 from a different VI called "Select Channel and Record Data_v005 Folder (saved to 2018)" That's where my initial issue occurred.

In this code, even without highlight execution I am getting error -200279 and everything is freezing right away. So, I tried to break it down and that's where this new "Debugging" code came from.

 

So, I guess the "debugging" errors aren't that relevant because they do not appear when I run normally. But, the errors in "Select Channel and Record Data_v005 Folder (saved to 2018)" still appear in normal run mode. 

 

If you want to run "Select Channel and Record Data_v005 Folder (saved to 2018)"

Once you open the code and start the run. You will have to open up the calibration coefficient file, then click "connect, "import coefficients" and "write config", then go to the record tab and select a file location  "Sample Code" and press "record".  You will also need "calibration coefficients" text file and "sample code" text file, which should be attached. 

 

My real issue is happening in this code. I thought by fixing it in "debugging" it would resolve the issue, but the issue only seems to be in "Select Channel and Record Data_v005"

 

If you have any more suggestions I would be greatful!

 

If I hope this still falls under the same " Forum Subject". 

0 Kudos
Message 6 of 18
(1,896 Views)

There are quite a few things wrong with this code. First, you need to get out of the text based code mindset. Next, you should use wires instead of local variables where practical. The use of local variables and value property nodes will often lead to race conditions, and both of these are less efficient than a wire. Remember, in LabVIEW the wire is the variable.

 

You also do not need an outer loop and an inner loop. Your DAQ loop could easily be converted to a state machine. I would also take it outside of the loop with the Event structure. Finally, remove the 1000 ms wait. As Ravensfan noted previously you are controlling the rate with the DAQ. By further limiting the loop rate you aren't giving the system time to catch up if there are some long iterations.

 

Given your current architecture I would recommend that you learn about a queued message handler architecture. It is not recommended that you have significant amounts of code inside the event structure.

 

 

 

 

Message 7 of 18
(1,836 Views)

Hi johntrich1971,

 

Thanks for the direction. I do feel you are correct and that it's the architect causing the problems. I'll look into switching over to a queued message handler or a state machine. Plus, sticking to wires and removing the delay.

 

Thank you. 

0 Kudos
Message 8 of 18
(1,829 Views)

@jescameron wrote:

Hi johntrich1971,

 

Thanks for the direction. I do feel you are correct and that it's the architect causing the problems. I'll look into switching over to a queued message handler or a state machine. Plus, sticking to wires and removing the delay.

 

Thank you. 


Do the state machine first. The queued message handler will then just be an extension of the state machine architecture.

0 Kudos
Message 9 of 18
(1,823 Views)

Ok, do I need the while loop around the message handler loop if I only call one message that has a while loop already inside of it?

 

I'm just worried if I put "Record Data" into the normal message handling configuration, which looks like a while loop with an event case inside of it, that it will lead to issues when I put another while loop inside of it.

0 Kudos
Message 10 of 18
(1,816 Views)