.NET Interop assembly Hangs when dll contains some math / analysis functions (e.g. FFT).

[sketel]

I'm creating a .NET interop assembly with LabVIEW 9.  When I add a method containing the FFT function to my dll, the dll no longer functions properly.  Before adding this dll, the other methods in the dll work fine.  All VIs work properly in the LabVIEW environment.  It seems this behavior appears only when there is a VI in the dll containing certain mathematical analysis VIs such as FFT, Mean, and Bessel function.  Here is what happens: when a method in the dll is called, the front panel of one of the problem VIs partially appears and hangs.  It doesn't matter what method is called and no code in any VI is executed (as determined by writing to a log file). 

I created an example to illustrate this.  There are two methods in the dll: "squareX" and "hangLabVIEW".  "squareX" just squares the input.  "hangLabVIEW" takes the FFT of an empty array.  It doesn't matter what is in "hangLabVIEW", just that there is at least one of the VIs that causes problems (FFT, Mean, etc.).  Start the windows application and click the button to square the value of X.  The front panel of "hangLabVIEW.vi" will partially pop up and hang.  Now here is a clue that makes me think there is a race condition.  When I call any VI in Main() prior to hitting the button on the windows app, the methods in the dll function properly.  Does this force the dll to load into memory in the correct way?  So my current workaround is to create a do-nothing "initialize.vi" that I call from Main().  

Make sure to comment out "squareX" in Main() to see the problem.

Summary of clues:

Problem does not present in a console application, only in windows app.

Problem occurs when a VI in the dll contains certain lvanlys.dll VIs.

Problem does not present when any VI is called in Main().

No labview code is executed when the problem presents.

No VI's front panel should appear at any time.

[sketel]

Possible explanation:

After careful observation of working programs, I've determined that it's not the front panel of the problem VI that partially appears.  It's the window that shows the loading of subVIs.  Sometimes when loading a VI, LabVIEW asks for help finding a VI or alerts the user that a dependency has changed.  Perhaps this is happening and LabVIEW is getting stuck because it's asking for user intput that it can't get.  If this is true, I wonder why I never see this when I run the same VIs in the LabVIEW environment. I will try to see if this problem presents when the C# code is compiled to an EXE.

[simon76]

Hi Sketel,

How're you going to solve this as i facing the same problem (my dll contains some analysis functions)??

Regards,

Simon

[sketel]

Simon,

My current "solution" is to create an empty do-nothing VI; I called mine "initialize.vi".  Add it to the dll and call initialize.vi early in the main() of your code.  If the theory is correct, this will load all VIs in the dll without incident.  When you need to call the important analysis VIs later on, they will already be loaded.  I hope that helps.

Regards

Steve

[simon76]

Hi,

"Add it to the dll and call initialize.vi early in the main() of your code"

Do you mean that add a subvi - initialize.vi to my main vi code before go for using analysis functions??

Or in my .net program call the initialize.vi dll then follow by the analysis functions dll??

I'm abit confused here....

BTW, i doing the loopback frequency & amplitude measurement for the pc soundcard.

Thanks and Regards,

Simon

[IanBarnes]

---

sketel wrote:

Simon,

My current "solution" is to create an empty do-nothing VI; I called mine "initialize.vi".  Add it to the dll and call initialize.vi early in the main() of your code.  If the theory is correct, this will load all VIs in the dll without incident.  When you need to call the important analysis VIs later on, they will already be loaded.  I hope that helps.

Regards

Steve

---

Hi Steve, I tried doing just that - add a init VI. It did not work for me, the init VI froze in the same way the analysis VI did. Removing the analysis VI causes the init VI to run correctly. Any other ideas?

Cheers,

Ian.

[JÞB]

(appname).exe.config

(yes, it has to be in the same folder as the executable). In it place this text:

<configuration>
<startup>
<requiredRuntime version="v2.0.50727" />
</startup>
</configuration>

[IanBarnes]

---

Jeff Bohrer wrote:

(appname).exe.config

(yes, it has to be in the same folder as the executable). In it place this text:

<configuration>
<startup>
<requiredRuntime version="v2.0.50727" />
</startup>
</configuration>

---

Strange but this text was already in an app.config directory along with the executable.

I did start another thread with my problem, that has my example code here:

http://forums.ni.com/ni/board/message?board.id=170&message.id=499598#M499598

[salimweeky]

It is so great to track this post. Though it is a trade-off solution, it does solve the problem and could call the fuction in dll built in Labview.