LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Error 50410 No More Space in the Buffer

While running my VI I keep getting an error message saying Error 50410 occurred at DAQmx Stop Task.  Possible Reasons: There was no more space in the buffer when new data was written.  The oldest unread data in the buffer was lost as a result.
 
Occasionally, the error message comes on frequently, like once a minute, and then sometimes it doesn't come on at all.  Usually I just hit continue and the VI continues to run.
 
Attached is my VI.  The top Timed Loop is the main part of the program and inside this loop is when the error message occurs.
 
 
 
 
Download All
0 Kudos
Message 1 of 9
(4,524 Views)
You seem to be trying to run the same task simultaneously in three different loops, if that doesn't throw an error immediately it will definitely result in some bizarre behavior due to race conditions.

And how do you stop the loops? None of them seem to have the stop terminal wired?

As another forum member  (Ed Dickens) says "Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences."


 


Message Edited by Troy K on 03-07-2008 02:46 PM
Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
0 Kudos
Message 2 of 9
(4,509 Views)
Another problem is you are creating and configuring tasks in the loop and also stopping and clearing them.  So as the program loops, you are doing the same things over and over again.  Start and configure before the loop, stop and clear after the loop.
0 Kudos
Message 3 of 9
(4,504 Views)
I included a stop button to stop all four timed loops.  So that problem is fixed.
 
I tried moving all the DAQmx Timing, DAQmx Start Task, and the DAQmx Stop Task all outside the timed loop.  I only left the DAQmx Read insided the timed loop.  I got strange behavior like it would run once and then stop.  I then tried all possible combinations of inside and outside the timed loop and it would fail to run, or it would run but display NAN for all entries.
 
As the VI gets more and more complicated it seems like the error message is increasing in frequency.
 
Ultimately the program has four functions:  1) Display on the front panel values at 0.5 Hz.  2) Perform an appended data save by recording 1 value at 1 Hz or maybe as high as 50 Hz.  3) Perform a buffered acquisition and save the data.  4) Open a file and plot some data.
 
With the exception of 3) I want the values to continuously display on the Front Panel at the requested 0.5 Hz.  I have chosen to use 4 Timed Loops to accomplish this.  Is there a better way?  How should all the DAQmx VIs be arranged with multiple Timed Loops?
 
Attached is my latest version.
 
 
0 Kudos
Message 4 of 9
(4,474 Views)
What you posted still shows the configure, stop and clear DAQtasks still inside the loop.??????Smiley Surprised
0 Kudos
Message 5 of 9
(4,471 Views)
I agree with RavenFan, you need to program your hardware appropriately before you can optimize your code to run at the desired rate. I've attached a screen shot of an example of good DAQ programming with a loop. It's a simple example but the functionality of each VI is where it needs to be. For example, the Clear Task ALWAYS needs to be the last VI ran and only once because it clears all alocations to the device and you have to reconfigure the task to be able to use the device again (which is inefficiant and in your case could have race conditions).



Message Edited by Patrick_Ba on 03-11-2008 03:24 PM
PBear
NI RF
0 Kudos
Message 6 of 9
(4,455 Views)
Sorry for the long delay, I have been working on other programs.  The attached program seems to be error free.  The only problem I see now is that I'm limited to about a 40 Hz acquisition rate when I append data to a file.  This is the second timed loop in the program.  I can make minor modifications like increasing the board sampling rate, or reducing the dt on other non-important timed loops, but the gains by doing this are minimal, like 1 or 2 more Hz out of it.  I would like to get at least 100 Hz acquisition rate.
 
What is limiting me to such a slow acquisition rate?
 
Thanks
 
 
0 Kudos
Message 7 of 9
(4,359 Views)
The last two loops both try to write to files after acquiring data. This will limit how fast you can loop around and acquire the next set of data.
Writing to files takes time, these operations should be in a separate loop using a producer consumer architecture.

There will be gaps in the data of the last loop because its task is starting and stopping all the time (previous posts in this thread discussed how this should be handled).

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
0 Kudos
Message 8 of 9
(4,352 Views)
I'll read up on producer/consumer architecture.
 
The last loop is a buffered acquisition which freezes the Front Panel until it completes.  I only use it when it's appropriate to freeze the Front Panel and do a high speed acquisition.
 
Thanks
0 Kudos
Message 9 of 9
(4,339 Views)