LabVIEW
Call By Reference Node + Call library function node
@Barkey wrote:
The DLL is only for communicating with the PCI card, so not graphical things.
I've added a screeny to make it more easy to see.
The third picture is the part that loads the DLL. Whenever the frontpanel of this VI is opened (or a VI where it is called directly), it works fine.
When i would close it it basically is out of memory because of the Call By Reference Node. At least until i want to use the DLL, which is what I intended. Now when it is closed, labview still runs the Called VI that opens the dll, but the result is an error.
As long as the VI which calls the DLL has its front panel open it will stay in memory and as long as it stays in memory it will keep a reference to the DLL. So if you call your VI dynamically LabVIEW will generate a VI reference to the VI in memory in Open VI Reference and will execute the VI and then Close that VI Reference but the VI and with it the DLL will not be unloaded. If you do not have a front panel open the VI is not in memory but will be loaded by the Open VI Reference. This will load the DLL into memory too then Call By Reference calls the VI that executes the DLL call and when closing the VI Reference the VI leaves memory and with that will close the DLL reference too. If no other VI in LabVIEW has a reference to that same DLL the DLL will be unloaded.
Possibly the DLLs DETACH_PROCESS handler contains code that will deallocate all currently open handles which would at least avoid memory leaks. But even if it doesn't, for the next load of the DLL the handle created from the previous invocation will be completely meaningless to the newly loaded instance of the DLL.
Trying to dynamically call individual functions that use resources like handles across calls is not a very good idea. You could make sure that the DLL stays loaded during the entire runtime of your application by adding a VI that references a function to said DLL in a part of your program that is not dynamically loaded and executed. You can make that function call even never called. The fact that it is there makes sure that the DLL stays loaded. However be aware that if you put that DLL node into a case structure that you wire the case selector to a front panel control and not just a boolean constant since LabVIEW since 8.0 will optimize constant wired case structures away when building an executable.
Why you try to make all calls to the DLL dynamic is rather unclear to me. It would seem to make those calls a lot slower for sure and memory savings will be minimal if at all.
Rolf Kalbermatter
Of course there is a way but you do need to make it smarter.
@Barkey wrote:
The reason why i wanted to do it this way was to make it work even if the dll would not be on the PC. If the card wasn't installed, the dll wouldn't be needed either.So I guess this isn't going to work the way i wanted it to. Is there any way of only opening the dll if the card is detected and then keep it open?Although I might as well just not use the Call by reference as it would only slow things down like you said. The VI being faster when the clock is less accurate wouldn't make much difference anyway.
Bascally you want to write a smart VI that can manage your DLL calls. I would do this as a LabVIEW 2 style global or as I like to call them intelligent action buffers. They are VIs with a loop with one or more unitialized shift registers and a case structure inside the loop. The case selector is wired to an operation enum with enum values like init, get ref, and close.
First you write the actual DLL wrapper with an enum as operation selector and a case structure wired to that enum and the according DLL calls inside the various cases. Obviously you also need to have some common parameters somehow.
Then write a wrapper VI with the same type of operator enum and also the same parameters. On init you try to dynamically load the subVI that access the DLL. If that fails the DLL is not there or could somehow not be loaded. Then you execute the intialization function. Now do NOT close the VI reference to the subVI if this succeeded so far but store that reference in an uninitilized shift register. Then on subsequent calls to the wrapper VI call the subVI dynamically with the same parameters and operation enum until you do not need it anymore at which time you call the close method which first dynamically calls the close method of the lower level VI and then closes the VI reference itself.
This makes sure that your DLL stays in memory for the entire time between your init and close call, so that resource identifiers that the DLL returns stay valid between calls. Obviously if the DLL is more complicated it may be hard to combine all methods into one single VI interface and you would have to devise a somewhat more involved variant of this but it will nevertheless work.
The poor mans method as I have already mentioned earlier would be to keep a reference to a VI calling that DLL somewhere as long as needed and just do the rest as you do know. Since that reference will keep the DLL in memory it won't matter if the actual calls come into memory and go again as they will simply attach to the already loaded DLL. Of course if loading that reference VI wouldn't succeed you would somehow have to make sure to not try to load the actual functions either each time as that would be useless.
Rolf Kalbermatter
