VI server concept for calling dlls

[HCL Tech]

Hi,
I have developed a test software using ASP.NET application.
My test software is used to test the controller using Automatic Test
Equipment

The Automatic test equipment employs the following hardware,

PXI Chassis 1006

PXI Embedded Real-Time Controller PXI-8176/RT

Analog Output PXI-6711 - 4 No's

Analog Output PDXI-AO-16/16 - 2 No's

DMM PXI-4060

Multifunction DAQ PXI-6052E

Isolated Digital I/O PXI-6527 - 2 No's

Since ATE (automatic test equipment) uses LabVIEW 7.0 real time RT,
I had created a windows based LabVIEW 7.1 dll to interact with the ATE
hardware modules.

1. The dll's residing in the ASP.NET back-end code are developed using
LabVIEW 7.1 and are called from ASP.NET (VB.NET) environment. The dll's
function is to invoke a pointed library and pass the captured GUI
parameters
as arguments to this pointed library. The dll would then wait for the
execution of the library before returning to the .NET program.

2. The library file residing in RT controller is developed using LabVIEW.
The library's function is to supply or read data from the PXI and GPIB
resources using the dll supplied arguments. The library would be invoked
from the Windows dll as mentioned in Point 1.

Problem Description :
My ASP.NET test software should work in Master_Slave concept. That is the
first person who logs in to the test software becomes MASTER (Complete GUI
will be enabled and user can conduct the test) , and the remaining person
who log in to the test software will be working in SLAVE mode (Complete GUI
will be disabled, and they can't conduct any test, but should be able to
view the test results of the test performed by the Master)

In my .NET code I have clearly demarked the code that should be executed
for
the Master and Slave mode user. Only when the user is in Master mode, the
LabVIEW DLLs will be called

Only one when person is logged in to the software, my software works find,
but as soon as another person log in, .NET code hangs at the LabVIEW DLL
call.
I talked to Microsoft people regarding this for a month, I generated the
dump files and sent it across to them. They clearly told .NET code is not
hanged, but waiting for the LabVIEW dll to return the output.
I cross checked that and that is true.
When there is a call to LabVIEW DLL from .NET code (aspx page), it will
enter the DLL call, but never returns and .NET code will be waiting for the
LabVIEW DLL to return the output.
I face this problem only when two aspx pages are opened.
So I changed the .NET code for the SLAVE mode user. Before I was displaying
the test results taking it from database, but now just I am refreshing the
page.
Even then it is not working.
So I got the doubt in VI server concept.

SECOND TRY:-
I created a simple add.vi to add two numbers and made that vi as add.lib
and placed it in say PC B.
Then I wrote a wrapper fucntion to access the add.lib present in PC B and
made this vi as add.dll.
Now I accessed this dll in .NET code, it was working fine. Then I opened
two
aspx pages, it was working fine.
Since my DLL used to interact with hardware was taking some 2-3 seconds, I
thought the problem may be due to that.
So I inserted a dealy of 5 seconds inside the vi used to create add.dll.
Now I accessed the add.dll (with delay) from ASP.NET code. Now if I open
two
aspx pages, it is getting hanged at DLL call.

Can anyone please help me to solve this problem
Thanks,
Poornima

[Lycangeek]

I believe you are running into a known issue with ASP.NET, which is that LV's UI thread is either destroyed, not pumping messages or the like.

When LV's runtime engine is brought up, the thread that calls into the runtime can end up creating items that require messages from the OS message queue. This means that if that thread (in this case an ASP.NET thread) is terminated by the worker processes, LV will hang.

A workaround that you can use is to put the following type of code into your global.aspx code-behind file. This is C#, but it should be easy to translate to VB.NET if that is the language you are using...

...

[DllImport(@"C:\Inetpub\wwwroot\mywebapp\bin\mylv.dll", CharSet=CharSet.Ansi, ExactSpelling=true, CallingConvention=CallingConvention.Cdecl)]
public static extern int LVDLLStatus(IntPtr errStr, int errStrLen, IntPtr module);

static protected System.Threading.Thread t;

public static void ThreadProc()
{
LVDLLStatus(IntPtr.Zero, 0, IntPtr.Zero);
while(true)
{
System.Windows.Forms.Application.DoEvents();
}
}

public Global()
{
InitializeComponent();
}

static Global()
{
t = new System.Threading.Thread(new System.Threading.ThreadStart(ThreadProc));
t.Start();
}

...

[HCL Tech]

Hi Brain Tyler,
We have tried the code whatever you send for C#.
Whatever you told is true. As you said we called
LabVIEW DLLs in global.aspx page and our application
in infinite loop. Everything was working fine. But we
have noticed that it is taking a huge resources,
infact(100%) cpu usage is registered. Is there any
workaround to solve this problem, please let me know.
Thanks for your prompt reply,
Poornima

[Lycangeek]

Ah, I believe that DoEvents() returns if there are no events on the queue - so calling it as I showed means that you are going to have that problems. Bad on me!

Unfortunately I don't believe that .NET has the kind of function we need. Basically we need to recreate the loop from Win32 (copied from MSDN docs).

BOOL bRet;

while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}

You could create PInvoke calls for each of these and do it all from inside ASP.NET but that is likely to be more expensive than it needs (all that jumping in and out of .NET). Probably the easiest thing is to create a little C DLL that does this for you and then you just have one call. Something like

extern "C"
{
__declspec( dllexport ) void PumpMessages()
{
BOOL bRet;
MSG msg;

while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}

return;
}
}

I haven't had a chance to try it, but here is a little DLL of the above code. Let me know if that works for you.

[HCL Tech]

Hi,
I am sorry for replying so late and again I am sorry to tell that I was not able to understand the implementation way what you have told. I did not understand where to use the DLL. SO, can you please explain me how to implement it.
Sorry for troubling you
Thanks,
Poornima

[Lycangeek]

Since this has come up a few times, I wrote it up on my blog. Check out "LV and ASP.NET" (link in signature).

[HCL Tech]

Hi Brain Tyler,
I chnaged the .NET code in the way you have mentioned. I am very happy to say that code is working fine now.
It is really amazing.
Thanks a lot for your kind co-operation.
Thanks,
Poornima

[HCL Tech]

Hi,
You had given me the solution on LabVIEW DLL hanging probelm in ASP.NET software.

After implementing a simple labview add.dll in global.asax page, the hanging at labVIEW Dll call was resolved.
But in my ASP.NET code, I am using 'C' DLLs. Now the aspx page hangs at c dll call, but inconsistently. I am using both LabVIEW based DLL and 'C' DLLs.
Please help me in this hanging issue at DLL call from ASPX pages.
Thanks,
Poornima

[Lycangeek]

I'm afraid that is a pretty vague issue...

If I understand you correctly you are saying that you have some DLLs written in LV and some written in C. The ASP.NET web pages call the C DLLs and sometimes hang. Is that right?

The first issue is to try to simply the system down. I have no idea what your application does or what the C DLLs are for, but can you recreate the problem with just a simple web page and the C DLLs?

There are lots of reasons why you might be having this problem, not the least of which is something not quite right in the PInvoke signature for your C DLLs. They are very tricky to get right and if you don't, almost anything can happen - including occational hangs.

[HCL Tech]

Hi,
The ASP.NET software I have developed is used to test some LRU (Line Replaceable unit) using ATE (Automatic Test Equipment). LRU is provided by my clients along with 'C' DLLs used to talk to LRU. ATE is developed by us based on PXI chassis. I have created few LabVIEW DLLS to interact with ATE hardware modules like Analog input, discrete input etc.
Initially I was facing problem with LabVIEW based DLLs. In my ASP.NET software I have two aspx pages, one is used to conduct the test and another is the trace file shows the commands executed. If two aspx pages are opened and if the LabVIEW DLLS takes more that 2 seconds to complete its execution, the .NET code was hanging.
You gave solution for this by calling some simple LabVIEW dll in global.asax page. (The sample u provided me was 'C' DLL). I modified global.asax page as u mentioned.
Below is the part of code of global.asax page

SetLastError:=True, _
ExactSpelling:=True, _
CallingConvention:=CallingConvention.StdCall)> _
Public Shared Sub ADD(ByVal num1 As Double, ByVal num2 As Double, ByRef num3 As Double)
' Leave function empty - DLLImport attribute
' forces calls to ADD to
' be forwarded to ADD in Add.dll
End Sub
_
Public Shared Sub PumpMessages()
End Sub
Protected Shared t As System.Threading.Thread
Public Shared Sub ThreadProc()
Try
Call ADD(10, 20, Numeric3)
Call PumpMessages()
Catch ex As Exception
End Try
End Sub
Shared Sub New()
t = New System.Threading.Thread(AddressOf ThreadProc)
t.Start()
End Sub

Then the ASP.NET code was not hanging at LabVIEW DLL calls, even if two aspx pages are opened. But now I am facing problem with 'C' DLL calls provided by my client. That too inconsistently. It will go to 'C' DLL call and will not return back (The Same problem I was facing with LabVIEW DLL call before).
Please help me to come out of this hanging problem
Thanks,
Poornima