LabVIEW RealTime gives AI Buffer Config -10444 error

[rhumphries]

Running LabVIEW 6.1 in PXI crate using 8146RT with 128MB memory. Scanning 4 channels @65,000Hz for 20 seconds using 6071E card. Using Acquire N Scans VI. System runs fine for several days, then get AI Buffer Config error -10444. LabVIEW RealTime Tutorial says to allocate all buffers before starting WHILE loops to reduce use of Memory Manager, so how can I stop this continual allocation/deallocation that Acquire N Scans does. 4x65000x20x2 (I16) is ~10MB by my reckoning, does PharLap OS require contiguous memory?

[Bob_Preis]

The example Acquire N Scans.vi calls AI Read.vi (from the intermediate palette), which allocates memory to store the new data. You'll notice that AI Read.vi calls AI Buffer Read.vi (from the advanced palette). AI Buffer Read.vi has an input called "waveform data in", which allows you to reuse memory from previous acquisitions.

So with a few simple modifications to the connector panes in your call chain, you should be able to pass your array from iteration n-1 to the "waveform data in" parameter on AI Buffer Read.vi, thereby reusing the same chunk of memory.

[rhumphries]

Hi Bob,
I'm worried about the call to AI Config before we get to the AI Read, as this seems to be where LabVIEW allocates the internal buffer for the data transfer, and this is where the error comes from. If I'm going to pass a data array into AI Read, do I need to tell AI Config not to allocate memory at this point?

[Bob_Preis]

AI Config's allocation is negated by AI Clear, which cleans up the buffer. As long as you're calling both VIs every time, you should be fine.

What might be happening is LabVIEW could slowly be running out of memory for the reason I mentioned earlier or possibly for another reason not yet known. And when enough memory has been exhausted, the very next AI Config tries to allocate a buffer too large given the available memory in Pharlap.

I recommend making the modification to AI Read anyway, but also check your target memory periodically to see if there's a memory leak while running that example continuo
usly.

[rhumphries]

Thanks Bob, your link to target memory doesn't work on my browser, so could you expand on that please? Sounds a reasonable line of enquiry.

[Bob_Preis]

Sorry, try this link.

The knowledgebase article just explains how to view available memory on your RT target. Add the following line to the labview.ini file on your host computer and restart LabVIEW:

targetmeminfo=true

Target LabVIEW to your RT controller. Now, when you select Operate>>RT Engine Info, the memory usage of the RT Engine will be displayed. You can check the available memory when you begin running your VI and maybe once per day to determine if there's a memory leak.

[rhumphries]

Thanks a lot Bob. Things will probably go quiet while I try and digest all this information!

[rhumphries]

OK..... monitoring the RT memory shows that the Heap memory value is slowly decreasing, but it occassionally jumps back up to a larger value, then resumes its slow decrease from the previous value e.g. 15827, 15797, 15672, 23446, 15457K. Does this indicate a VI slowly grabbing memory, but occasionally being 'swapped out' (does Pharlap do this?) and then resuming? How do I track this VI down?

[Bob_Preis]

This appears to be a memory leak, but let's try one more thing.

Before downloading your VI, take note of the memory on the target. Download (but do not run) the VI, take another note of the memory.

Now run the VI. Once you've noticed a significant decline in memory like the sequence you listed above, stop the VI. Note the memory again to see if it remains constant while the VI is idle. Wait a while and check again just to be sure. It should not change while the VI is idle. Now close the VI and check the memory again.

The available memory before you downloaded your VI should match the available memory after you closed your VI. If these numbers do not match, there could be a memory leak
in LabVIEW, especially if the mismatch is very large. If they do match, we'll need to take a closer look at your app.

For this test, the larger the decline in memory (i.e the longer you run the app) the better; we don't want to concern ourselves with relatively small mismatches < 1 kB.

[rhumphries]

SUCCESS!! We have a VI that monitors other VIs to see if they have stopped (detected a fault) and restarts them if they have. Within its run-forever while loop, it was opening up a VI reference, checking the execution state, but not closing the VI reference. I have changed it to get all the VI references into an array and pass this array into the while loop, and it's all working with a stable heap memory and about 10 times the free memory that it had before (22332K vs 1332K).
Thanks very much for your help. I've learnt a lot about memory allocation and will be much more careful in future about what goes on inside loops and what should be set up before entering the loop.