C++ Call to DLL made in LabVIEW Fails the second time it is called

[Labviewguru]

I have an application where a C++ executive calls a LabVIEW DLL (a LabVIEW application built into a DLL).

The executive calls and operates the DLL fine the first time (NT, the applications task manager shows LabVIEW runtime runs, then stops when the DLL is done. However, when the executive calls the DLL a second time, it hangs, and the runtime engine never shows up in the applications task manager as running.

However, this only occurs when something like IMAQ, DAQ, or another custom DLL call is occurring. We tried it with a simple DLL that only uses a call to the sound VIs, and it seems to run fine, although as the program called is very short, and the task manager slow, we never see the runtime engin
e in the task manager. We are going to put a popup dialog in to ensure that the DLL is being called reliably, but we believe it is.

We are unable to answer why when we call something that uses IMAQ, that the DLL doesn't run right the second time. We are unsure of the reasons, but believe it to be related to thread creation and destruction in the executive.

If anyone out there has any insight into this, we would be happy to see it.

We will be putting in a formal request for support from NI, but wanted to poll the audience as well, as we know from first hand experience that LabVIEW users often times have more experience with this sort of thing than developers.

Thanks a bunch

[Lab Viewer]

Hi Labviewguru,
As 'Labvie 6.0.1 changes' doc states, it seems that at least NI knows about this kind of problems ('calling DLLs built with LabView when the calling application exists on NT 4.0 no longer causes a crash').
Assuming that you already have LV 6.0.2, it could be possible that the problem isn't completely fixed.
good luck

[Labviewguru]

Followup:

We put some code in the DLL that logs information to a file. When just that code is used, the DLL works repeatedly. However, we dropped in a sequence to capture an image from IMAQ, and it froze on the second instance, after running successfully on the first. On the second instance, the program actually ran, logged to the file, but froze after that. We are going to further isolate this to different parts of the IMAQ sequence.

If anyone is familiar with anything resembling this problem, please let me know.

Thanks

[Labviewguru]

Well, we figured this one out ourselves.

The problem was threading. LabVIEW does not currently have the capability to handle multithreaded DLLs properly. The calling application would create a thread, run the DLL, then destroy the thread. When it was run again, the thread creation process was not able to proceed as it should have.

If you need details, please contact me at mdulyea@ascendco.com

[GregMcKaskle]

DLLs created by LV need a number of resources to carry out execution. The problem here is that the first time LV is called, the thread it is called with will be adopted as its UI thread. The LV execution system will create windows in that thread, and if the thread is later destroyed, it will cripple the LV execution system since it cannot have anything execute in the UI thread. This is why some VIs will work fine while others will not.

I'm not sure how well this is documented, but the thread that first calls the DLL needs to stay alive as long as the DLL can be called or is still executing VIs, and it needs to process/pump messages.

If the rest of your app relies on this create/call/destroy architecture, just make sure that the first call or th
e LoadLib is in a different thread that satisfies these requirements. You can then make the DLL calls in any thread that you like and destroy them any way that you like.

Greg McKaskle

[Labviewguru]

Thanks for the information Greg. There is no documentation on this issue, except for the email that we got from NI Support. This is quite a new realm for us and NI alike. We would like to know what your experiences have been on this subject. If you have a bit of information, perhaps we should suggest a topic. As I said, this is a new frontier for LabVIEW, and there are a lot of things that NI doesn't know, and I'm sure a few of the programmers out there have figured out.

Thanks again

[Greg_McKaskle2]

> Thanks for the information Greg. There is no documentation on this
> issue, except for the email that we got from NI Support. This is
> quite a new realm for us and NI alike. We would like to know what
> your experiences have been on this subject. If you have a bit of
> information, perhaps we should suggest a topic. As I said, this is a
> new frontier for LabVIEW, and there are a lot of things that NI
> doesn't know, and I'm sure a few of the programmers out there have
> figured out.
>

I often answer emails from home, but I work for NI on the LV development
team. So anything I know about, NI knows about. The info I was
describing about the DLL execution system is not well documented since
we were hoping that it would work we
ll with the way Windows Apps are
typically written. I suspect that we will need to write a Tech Note
to cover the nitty gritty. This sort of info gets lost in manuals,
and it is subject to change as we learn how people are expecting to
use it.

Anyway, my post was to explain why your use of it didn't work.
In general, we believe that LV DLLs are thread savvy, reentrant
VIs can be called from multiple threads simultaneously, execution can
continue in the background after the DLL call has returned, and the UI
is live provided the calling app processes messages in that thread.

If you have other issues or questions, just ask.

Greg McKaskle

[Labviewguru]

Well, we figured this one out ourselves.

The problem was threading. LabVIEW does not currently have the capability to handle multithreaded DLLs properly. The calling application would create a thread, run the DLL, then destroy the thread. When it was run again, the thread creation process was not able to proceed as it should have.

If you need details, please contact me at mdulyea@ascendco.com

[jean-bat]

Five years later, I have exactly the same problem with LabVIEW v.6.1 :

It is impossible to call a function from a DLL which was loaded in a previous (ended) thread.

Do you know if something had been solutionned in newer releases ?

Thanks in advance.

Message Edité par jean-bat le 01-03-2007 08:55 AM

[Lycangeek]

Yes, this issue has been fixed in LabVIEW 8.0. Now, instead of using the first thread we spawn our own thread to handle the UI message pumping. I also wrote up an article on this with regards to getting the LabVIEW DLL to work in ASP.NET (where you have little control over threading). The same technique could be done by other applications. I'm not certain whether this works with LabVIEW 6.x as it is well before my time on the team...but it's something to try.

http://detritus.blogs.com/lycangeek/2005/05/labview_and_asp.html