12-18-2012 07:53 AM
I'm using a lot of cFP hardware in a LV 2011 project. The program has started to crash, indicating that all memory is taken. After using the Desktop Execution Trace Toolkit, I see that it is the FP Read (Float -IO).vi that eats 4 kbytes? of data each time it is used. The problem is not present when I run the source code from LabVIEW, it is only when I make an executable, that the problem is present. Since I use a lot of cFP-modules, and read each signal individually, it doesn't take many days to eat all memory, even though each Read operation just eats a little. Anybody else seen this, or got any clue about how to solve it ? The problem has popped up last months, earlier on no problem. And I believe I have other projects without this problem, so I'm a bit confused...(PS; this is not a real-time application, the program is running on a computer).
Martin
12-18-2012 08:05 AM
I have seen something like this with an analog cFP write where the channel was empty. I don't remember if the VI returned an error (although it probably did and I only displayed it), but it leaked memory as long as the channel was empty (I was dynamically building the list of channels and some of the devices weren't assigned channels yet).
What I did to resolve it was use the Empty String? function on the channel and put the read VI in the False case of a case structure.
12-19-2012 03:39 AM
No, in my case the input FP IO Point is not empty, so thats not it.
12-20-2012 07:51 AM
Found out today that the problem is gone if I replace FPLVMgr.dll version 6.0.11 with version 4.1.0.15 from 2004.
Then suddenly the memory leak is not present anymore.