Labview: Memory Full error

TMDATA · ‎09-12-2005

Everytime I try to save data in this vi I get an error saying....... Labview : Memory Full " freqsweep.vi was stopped at AbuildDCO 0X51A28 at sub vi freqsweep.vi" The scan rate is set at 10000 with a input buffer of 40000 samples and a 2000 samples to read at a time. I tried changing these values around and I still get the same error everytime I try to save the data. Any suggestions???

Dynamik · ‎09-12-2005

Hi TMDATA,

When that happens to me it's (almost always) becasue I've a parameter is wrong. If possible, please create a simple example that exhibits the problem, and post/attach it.

Cheers

When they give imbeciles handicap-parking, I won't have so far to walk!

TMDATA · ‎09-13-2005

I think I have found part of the problem, but I am not quite sure why it is doing it. I have attached a pair of screen shots of the vi. If you look at the bottom of the second screen shot the time is calculated from 1/x of the scan rate then multiplied my the number of elements in the array. Then the time and data are built in to an array then formated to a spreadsheet. If I remove the section where the time is being built into the array the file is saved fine, I do not get the Labview Memory Full error and the data is good, just missing the time data. Anyone have any ideas? Also the card i am using is a PCI-MIO-16E-4.

Dynamik · ‎09-13-2005

Hi TMDATA,

While it's difficult to know what's happening based on the pictures, I do have a comment and suggestion(s),

Comment: The loop to the left of 1/x has the potential to demand lots of memory for buffered result array. (How many times does it loop? What are the dimensions of the input array?)

Maybe not here, but sometimes it's useful to use Highlight Execution (the light-bulb) to identify where code gets "stuck". This way, right before the error, you may see execution dissappear into a sub-vi, or notice a loop that iterates too may times. Please don't be offended if I suggest that using sub-vis to compartmentalize logic, would help in debug (as well as makes diagram more readable!)

Cheers!

When they give imbeciles handicap-parking, I won't have so far to walk!

TMDATA · ‎09-13-2005

The vi is suppose to do a analog out frequency sweep from say 100-500hz in 20 hz steps and capture analog in data. In another window it plots FFT data from the analog in with gain and phase data plotted on screen. Then in another window you have the option to save the data to disk. I am pretty sure all the data is buffered in memory until you hit the save data button. I am not sure how many times the loop to the left needs to irrirate. It is running at a 10,000 scan rate. Subvi's would have been great but I didnt write the code I am the end user trying to use it, trying to figure it out myself. I did run highlight execution mode and found that sometimes it points to the build array, just in front of the format array to string function.

Dynamik · ‎09-13-2005

... I did run highlight execution mode and found that sometimes it points to the build array, just in front of the format array to string function.

That is interesting. At that build-array, LabVIEW will have to allocate memory to accommodate a table wide enough for the single-array and with as many rows as the existing table +1. The single-array is data-samples wide (I think), but, correct me if I'm wrong the table is only Channel-count wide? Like I said, it's hard to _know_ what's happening, but

... perhaps the single-array should be appended to the table _before_ the Transpose?

Cheers.

When they give imbeciles handicap-parking, I won't have so far to walk!

TMDATA · ‎09-13-2005

If I appended the single-array _before_ the Transpose the data would get up into rows, instead of columns correct? Here is a sample of the file that it outputs when I leave the 1/x multiply by the element output from the index array out of the build array before it gets to format array to a string. There is the header, and then the data below. The first column is raw data from ch0, the 2nd column is scaled units data of ch0. The 3 column is ch1 raw data and the 4th column is scaled units data of ch1. Which all looks fine. But when you connect up the whole 1/x multiply by the element ........... it bombs with the memory error. It should just make the 1st column in the spreadsheet of time (ms), then the 2nd column ch0 raw, 3rd column ch0 scaled units....etc. And it worked as of last friday, but now I get this error for some reason.

Dynamik · ‎09-13-2005

Hi TMDATA,

Per pic, the affect of THE build array, will be to add a [top] ROW (think "left to right") not a column. If the same build is put before the Transpose, the added-row will become the first (left-most) column (see example - attached).

@TMDATA wrote:

...Which all looks fine. But when you connect up the whole 1/x multiply by the element ........... it bombs with the memory error. It should just make the 1st column in the spreadsheet of time (ms), then the 2nd column ch0 raw, 3rd column ch0 scaled units....etc. And it worked as of last friday, but now I get this error for some reason.

This problem is consistent with my diagnoses - adding a very wide row would force LabVIEW to allocate memory for samples-squared cells..
But if it was working (per pic) and nothing has changed (except maybe number of samples acquired) then I give up!

Message Edited by Dynamik on 09-13-2005 08:12 PM

Message Edited by Dynamik on 09-13-2005 08:15 PM

Message Edited by Dynamik on 09-13-2005 08:16 PM

Message Edited by Dynamik on 09-13-2005 08:17 PM

LabVIEW