Matlab Dll Initialize and Terminate

[jcop]

I am using a "C" wrapper dll around a Matlab Compiler-generated dll and am looking for suggestions on how to handle the required steps of initializing and terminating the application and dll using mclInitializeApplication, mclTerminateApplication, <lib name>Initialize and <lib name>Terminate.

I find that I can only do each of these once per launch of LabVIEW, otherwise LabVIEW will crash and exit (when init and term app are run again) or LabVIEW will hang indefinitely (when init and term lib are run again).  In order to execute any of these init and terminate calls again, I have to close and restart LabVIEW.

Generally, I develop code which starts running automatically, then the user has the option to go or quit.  When they select to quit, LabVIEW will stop running, but the user has the option to press the run arrow again, and have the options of go and quit again.  When I execute a test application of the dll generated in C from a command prompt, I can run the file init app, dll, function call, term dll, app sequence many times.  Unfortunately, LabVIEW seems to grab the dlls when it is launched and doesn't let go just because it is not running.

Has anyone come up with a way to handle these Matlab-required calls in LabVIEW short of restarting LabVIEW?

[JLS]

Hello,

Your last couple sentences imply that you are trying to get LabVIEW to unload the dll from memory.  Basically, the dll is loaded into memory when the VI containing the call library function node is loaded into memory, and the dll is unloaded when that VI is unloaded.  This means that if you have the call library node in your top level VI, or even in a subVI on your block digram, it is loaded into memory when your top level VI is loaded, and will not be unloaded until your top level VI is unloaded.  This is discussed in the following document:

When Does LabVIEW Load a DLL Called from a Call Library Function?

http://digital.ni.com/public.nsf/websearch/02E1DE2A53AC45708625690D006733BB?OpenDocument

You can get around this, however, by putting the call library function node in a subVI, and then CALLING THAT SUBVI BY REFERENCE.  I have attached an example which illustrates this - the top level VI in the attached zip is called ObserveDllLoadingAndUnloading.vi, and is commented for clarity.

I hope this helps!

Best Regards,

JLS

[jcop]

I tried calling the vi by reference, but either Matlab or LabVIEW must still be hanging onto some reference to the dll because I open the reference, call the vi by reference and then close the reference, just as your example shows, but I can only run the vi making these calls once.  The second time I run it the vi hangs forever.

[JLS]

Hello,

Can you set some breakpoints in your code to determine exactly where it is hanging?  This might give a clue as what's gonig on.  You can also try running an application which monitors dlls being called by applications (I think processExploreNT is a free download), to see which programs are hanging onto the dll.  Whether or not that is even the inherent issue I think is still unknown.

Ok, breakpoints and the 3rd party dll watcher should give us some more clues!

Looking forward to your repost!

Best Regards,

JLS

[jcop]

Using the process explorer, I can see that the underlying Matlab DLLs (under the ones I am calling by reference) are staying active using LabVIEW.  I can also see where the program is hanging when run a second time, it hangs on the initialize lib dll step.

[JLS]

Hello,

Have you made any progress?  Perhaps you can attach a simple example of your LabVIEW code so that I can see exactly what you are doing.

This may help me understand the problem better, and in the worst case start a dialog with R&D regarding the issue.

Thank you,

JLS

[jcop]

No progress.  I'm attaching a zip file of everything I think is needed to run the program.

[JLS]

Hello,

When LabVIEW attempts to load mclmcr.dll, I get an error message indicating: "The application has failed to start because mcr.dll was not found..."  Now, you included mclmcr.dll; does it call mcr.dll?  Can you post that one as well?  This causes the initAppMcl.vi not to be executable, which means it cannot be run or called by reference.  This doesn't sound like the error you get.  Actually, I read again from the beginning of the stream, and one detail came to mind that we haven't yet communicated.  When LabVIEW crashes after the first run of your VI, do you get an error message as it crashes, or perhaps an option to investigate when you start LabVIEW again after the crash?  In either case, please screenshot and attach any messages and attach any error log files as these can be used to investigate why LabVIEW crashed.  Also, have you considered using a scriptnode for your text-based code, instead of wrapping dll's and making those calls explicitly in LabVIEW?

Ok, we'll keep looking into this, and hopefully we'll get to the bottom of the problem soon!

Thanks again!

JLS

[gnilsson]

Hi

Have you considered doing the loading/unloading of the MathLab dll, in your wrapper DLL instead?

I have used this in C++ projects where the users can chose witch DLL to load.

You would have to use LoadLibrary, FreeLibrary, and also use GetProcAddress for all the used functions in the MathLab-dll.

If your interested I could look up som old example code.

[jcop]

The zip file attached should contain all the underlying dlls required to run this (I hope). 

If you are suggesting calling the Matlab script directly using a Matlab Script node in LabVIEW, that is where I started, but it requires that Matlab be installed on the PC and they are very proud of their software so that is an expensive test fixture.

The version of code I submitted which calls each dll by reference hangs at the init dll step when run the second time.  No error message is genated and LabVIEW doesn't crash with this version of code (it did crash when I had everything wrapped up inside one sub-vi).  I usually give up waiting for LabVIEW to return with 10 or 15 minutes.