Use a VI (with interface) in another program by DLL

[gautierdufourcq]

I thank you for your answer. I activated the front panel but there is a deadlock like in the paper. I call the function in DM. The VI starts. But, when there is a pop up window, it blocks the execution. When I manage for no popup, that I press a button (it changes an internal state), the VI crashes also. I think it comes from the settings. Do you have an idea of what is happening and how to remove it ? It must have a link woth the threading. Could you explain me these lines : 

To work around the deadlock, you must make sure that the DLL is called from a thread other than the user interface thread. To do so, first configure the shared library node to be Reentrant rather thanRun in UI Thread. Then make sure that the VI is not running in the UI thread by looking in VI Properties»Execution»Preferred Execution System, and make sure that user interface is not selected.

Thanks by advance

[nathand]

The deadlock described in the linked document applies ONLY when calling a LabVIEW-built DLL from another LabVIEW application. The directions to fix it don't make sense because that's not what you're doing.

Why are you trying to run a LabVIEW VI in parallel with some other code? What is the purpose of the LabVIEW VI, and of the program that's calling it? Can you build the LabVIEW VI as an application and run it at the same time as the DM software, instead of calling the VI through a DLL? What values do you need to communicate between the DM and LabVIEW code? Does data go in both directions, or is one always sending and the other always receiving? How frequently does that data change?

As others have suggested, what you are doing now is probably a poor way to accomplish your goal.

[gautierdufourcq]

My VI controls a system of temperature regulation. So, I must change the temperature when I want and I want to receveive data all the time. 

With the dll Labview, I build a dll. I wrap this dll into another dll with VS 2003 C++. In DM, I call this dll. I do not understand why DM crashes at the execution although I can now control it with the frontpanel. Can it come from DM ? But with dll, it should be ok no ? Unless VI properties are bad ??? 

[Dennis_Knutson]

Your wrapper could be poorly written, the VI could be poorly written, the LabVIEW dll could be incorrectly built, there could be problems with this dm program.

You have not provided any code at all - only somewhat vague descriptions. No one here has used dm. I'm not sure how anyone can help.

[gautierdufourcq]

For the VI, it is somebody who has written it. It is sold with a system by a company. Can I legally show it to you  ? 

[nathand]

Why do you need the extra layer of wrapper between the LabVIEW DLL, and DM? Can you not call the LabVIEW DLL directly?

It's possible that the DM software doesn't expect any call to the DLL to tie up a thread for so long. Does it crash immediately on the call to the DLL, or does it work for a while and then crash? Are you trying to pass data between DM and the DLL? If so, how are you passing that data? If you're trying to share data through a pointer, it's very easy to write data to the wrong address and cause a crash.

There's almost no way to help you here. There are three components to your system - the LabVIEW VI, the intermediate wrapper VI, and DM - that we can't see, and "crash" doesn't provide much information about what exactly happens.

[gautierdufourcq]

The VI uses Labview. It is interesting because the VI uses NI DAQ tasks. I launch it in DM, it arrives in the state 0, then everything is Ok. When I want to change the value (by the frontpanel) and that I start (change the state), it crashes. But first, when there is a pop up Labview Yes/No, the display is not correct. I succeded in doing simple tasks like checking if the device is connected or not. Maybe DM cannot handle something from Labview. 

[gautierdufourcq]

Thank you for everything, I ticked the answers