Free memory an external dll reserved

[CeeZero]

Hi everybody. I currently have a problem regarding memory used by a DLL.

I got a DLL from an external company wich i use to controll a Device. The DLL contains a function to initialise the connection to the device wich reserves about 3MB of memory space. But it reserves new 3MB Memory every time i call it again and has no function to free up this memory again. So i currently have a script wich calls this fuction and checks the return function to know if the device is connected to the PC. If it is, it gose on with its functions. But if it´s not i waits 50ms and repead so long, unit it the device is connected. So my VI reserves new 3MB of memory every 50ms if the device is not connected and crashes after a minute.

My question is: is there any way to free the memory reserved by the DLL again without changing the DLL? (as i said, it´s an external DLL and i don´t have any idear about modifying a DLL)

i tried to free the memory by wireing a empty path to the Call libary regarding this link of the knowledge base without success. http://digital.ni.com/public.nsf/allkb/77594203D78D12278625729100758BE5

Thanks for you help and greatings from Germany.

[CeeZero]

Anyone got any idear? Is there a way to allocate a specific space of memory for the DLL and clear this specific space afterwards?

[nathand]

The DLL would need to provide a way to release that memory. Otherwise, the operating system will hold on to it until your application exits, at which point it should clean up any resources such as memory that your program uses. Is there some other function provided in the DLL that will let you reuse the existing resources?

[CeeZero]

Hello nathand,

Thanks for your reply. There is currently no function to clean the memory and i´m most likely not able to script one. But when labview is able to clear the memory on exit, why isn´t it able to clean the memory on command?

[Yamaeda]

LV has no control over the DLLso the only way for the system to know it's safe to release the memory is at program end. On the other hand, why do you need to initialize several times? Isn't it enough at program start, then release it at end(automatically)?

[tmf171]

Does the program need to be running during this query? I found that to release LabVIEW and the DLL was to create an external EXE that would load up the program (EXE) that you are using. So Program X(X) acting like a splash loads Program Y(Y) and Program Y is the one you would make the DLL call in. Usually once the DLL is unregistered (not being used anymore) windows will free up that memory space. Instead of making Y query the DLL until crash have  X continue to reload Y until your criteria is met. Its not a very good workaround, but it may work in your case. I do it because I have DLLs that conflict with each other and I use X to allow me to unload Y and free up the hardware DLL so that I don't crash the computer. Then on startup Y will load the different DLL I need, in my situation, corresponding to the slightly different piece of hardware installed.

[nathand]

---

@CeeZero wrote:

Thanks for your reply. There is currently no function to clean the memory and i´m most likely not able to script one. But when labview is able to clear the memory on exit, why isn´t it able to clean the memory on command?

---

I'm not sure that LabVIEW releases memory used by external resources when a VI stops running. Rather, the operating system releases all memory used by a program when the program stops running. The operating system can do this because each program is assigned its own memory space, isolated from other programs. This is a function of the operating system, not of LabVIEW. Until a program exits, the operating system has no way to know which resources (such as memory) are still in use by the application, so there cannot be an operating system command to clean up a program that's still running.

You could try setting up your Call Library Function Node with the path passed as a parameter. Passing an empty path to CLFN will unload the DLL, so if the DLL is written such that it cleans up its memory when it is unloaded, it could solve your problem. It will slow down your code to repeatedly load and unload the DLL, and it may not help.

As tmf171 suggests, you can also create a separate LabVIEW progam which you call through VI Server that handles all the calls to the DLL. I once did something similar. I had to use an external component that crashed frequently so I wrote a separate small application exclusively for that component. My main program launched it and connected to it through VI Server. If the application crashed, the VI Server connection failed and the main program restarted the external program. However, this approach runs more slowly and there's more development time required than simply calling a DLL in your main program.

[CeeZero]

Thanks for all your replys.

@Yamaeda: the Call Labary part is only a small part of a VI controlling several devices. I currently initialize it several times because the program checks all the time wich devices are connected and which are not. I hoped the enduser of the VI could inatialize the device by only plugging it in the system and dose not have to call the function manually. But currently this dosn´t seems to be possible. However, even if the device will only be initialized on demand the number of calls are still limited. In worst case the final VI will be on a 1GB RAM laptop running for several month with alot of unplugging and replugging the device. So at some point the programm has to be restarted to free the memory.

@tmf171: the idear of calling the DLL on a different exe should be a workaround. Not the smoothes but once that at least work. I think i´ll try this. Thanks.

@nathand: as i said, passing an empty path to my Call Libary Function dose not work. AFAIK the CLFN only loads the DLL itself in memory. So i can free up this part of memory but DLL is then reserving memory on its own wich can´t be released.

So looks like the "Call libary via diffrent EXE" solution seems to be the only workearound unitll the company which created this DLL provides my with a better solution. However thanks for all your help.

[tmf171]

you need to setup the call library function node to specify path on diagram. Once the path is on diagram you wire the path into the call library function node. That is what nathand was trying to describe.

[CeeZero]

Thanks again. I did this allready like descriped in the link of my first post.