Labview memory is full

[Virginia_Solomon]

I have to control two DAQ  6115 boards analog in as well analog out channels. 

My program must provide different signal shapes for filling the AO  buffer fixing about 5 points the most as it can see in the input of the AO_BufferGraphsTable.vi. One example is when I have to write into the AO buffer a signal similar as the picture in the AO_BufferGraphsTable.vi:

Channel #1 - provide a level of 0.4A for about 4000ms, then ramp another 4000ms up to 2A then keep it at 2A during the last 2000ms. So in total the buffer is 10000ms for channel 1.

Channel #2 - signal is simple one pulse starting at in the 4-th ms then keep it at 2A during 3mas in total 7ms buffer for second channel.

In my application when I set sampling rate at 0.2 the buffer signal generator is ok, but when I change to 0.5 and upper then I have memory full message. I tried to optimize the routine as mush as possible for avoiding the memory problem but I still have it.

Any suggestion from this perspective?

Thank you,

Virginia

[AuZn]

You are having a 50000009 element array, it is too long. 

[AuZn]

A more detailed answer: You are probably using 32bit LabVIEW, and it can only access 4GB memory space (no matter how large your memory is, see How Much Memory can LabVIEW 32-bit or 64-bit Use?). 50000000 element array of double takes 5*10e8 * 8 byte = 4*10e9 ~ 400MB. And LabVIEW requires continous memory space for that, which is likely to be the direct reason what it says is it out of memory. 

One obvious solution would be reducing the size of that array. Or you can stream all those data to a file. Or instead of a big array, use multiple smaller ones to store all the data.

[A.Thomas]

I don’t mean to be offensive, but this VI is written against LabVIEW style and documentation guidelines and as a result is not readable. Therefore, I can't really tell what's happening. However, I noticed you have multiple copies of the same loop in your code and you have enabled parallelism on it. I created a subVI for you that will replace each of those loops and run a bit slower, but save memory. I also used auto clean up to clean up the block diagram a little bit, that’s why it looks a bit different, but it will do the same thing as before.

[Virginia_Solomon]

Even the posted example encounters memory issue. My computer is W7 32B. I noticed Labview does not exceed AO_BuildGraphsTable.vi does not exceed 1.3G in Task Manager.

The program is complex because for each step up of the amplitude I have to soften the step for preventing the power supply controlled with this signal to overshoot but in the mean time I hve to keep the same amount of time correctly so for this reason I have so complex program, also the signal must produce any shape with 5 points.

I would like to know a correct method for preventing the memory full message. What is very important is this routine I attached earlier is only a part of a big complex program with generating and  measurement of the generated signal, so for AI as well for AO I have big amount of data because my customer asked for high precision.

Should I find myself the limitation of the correct execution of the routine and to programmatic prevent higher sampling rate? Or is there any other way to do it?

I will try splitting the array into small arrays but at one moment I have yo load this 2D array into AO so I have to have hole array.

I already increase the computer memory to 3G.

Best regards,

Virginia

[AuZn]

Hi Virginia,

Like I mentioned above, the issue is very likely to that your computer is running out of CONTINOUS memory. When LabVIEW create an array, it will put all data of that array continously in the memory. Suppose there are 2GB of memory, and LabVIEW itself (the run time engine, the interface etc) is using 0.5GB, then there are 1.5GB free memory left. However, the 0.5GB of used memory might be spread out in the 2GB total memory, and LabVIEW couldn't find a continous chunk of memory of 400MB to store the array. 

Since you are using 32bit Windows, you can extend your available memory to 3GB according to NI. This will alliviate the issue, but not likely to solve it. Or you might try 64bit windows + 64bit LabVIEW.

Displaying data to the front panel takes a lot of extra memory, especially that waveform graph, not displaying the whole data and simply wire it write your buffer should help, or you can consider instead of writing the buffer at once by a huge array, write it multiple times with smaller array.

I also took a look at the spec of PXI6115. Its AO buffer hold a maximum of 3.2 million samples, with a resolution of 12bit. I am not sure how your plan to use the 50 million element array, but it certainly cannot be written to the buffer at once. Also instead of using double which take 8byte for each element, you can use a 12bit fixed point number which should take 3byte each element, and will not affect the presicon of the AO.

[mikeporter]

Why do you have 50 million (and 9) samples? You don't need anywhere near that much data. For example, channel A starts off at one level and stays there for 4 seconds, then after a ramp stays at a different level for 2 seconds -- that's 6 seconds of output time that can be handled quite nicely by exactly 2 data points.

Now about the ramp, if you pick the values for your reconstruction filter correctly you can likely get by with a rather sparse set of output values and a rather leisurely update rate. After all you are only going from 0.4 to 2 -- and you are taking 4 seconds to get there!

Say you sample at a 1khz rate, that's 4000 samples to cover your output range of 1.6, resulting in an output level change of 0.0004 per step.

On another point you mention a sample rate of 0.2, so that is 0.2 of what exactly? Seconds? Hours? Nanoseconds? Fortnights?

Mike...

PS: You are using a reconstruction filter, right?

[A.Thomas]

Hi Virginia,

I'm sorry to hear that my suggestion wasn't enough to resolve your issue. It looks like you got two other helpful answers to your questions already. So, you are in good hands on this post, but I would like to point out a few general suggestions:

1- If you are dealing with performance issues, NI Desktop Execution Trace Toolit can help you detect exactly which subVI is causing the memory problem. It's not a free toolkit, but it's included in the Professional Develeopr Suite License

: https://www.ni.com/en/support/downloads/software-products/download.labview-desktop-execution-trace-t...

2- If you anticipate a lot of work on Vis that deal with memory and need to meet certain performance criteria (speed), you will greatly benefit from taking the LabVIEW performance class. 

3- If you are working on a bigger more complex program, you will greatly benefit from improving your LabVIEW coding style and documentation. You can litteraly launch a spaceship into orbit using LabVIEW, but your VIs don't need to become complex and unreadable if you do it right. It will also save you time in terms of being able to debug code, make changes and maintain it in future. I recommend taking LabVIEW Core 3 and "Advanced Architectures in LabVIEW" or at least getting in the habit of using the "VI Analyzer" frequently so that it will point out areas that need imrovement in your code. It is not a free toolkit either, but it's included in the Developer Suite too. 

Regards,

Avedeen

[Virginia_Solomon]

Thank you Avdeen,

I made little pause to my code for a while. I was never involved in managing so big amount of data but with your recommendations I was able to face this problem. I learned about the tools I actually had it like Trace Execution and most of all I learned  about Labview managing data. 

One thing I did not like was the offended recommendations where people offered to code for me forgetting that if you did not touch an area of the problem and being under time pressure you might not start with the proper solution and you cry for help and no help came back other than offended remarks.

Best regards,

Virginia

[mikeporter]

Offending remarks? I just looked back and frankly didn't see anything in the least bit offensive. Perhaps you need to lighten up a bit and remember that people who offer you advice are all volunteers and we are doing it on our own time.

Mike...