Please see the PPT slideshow also.
We created a .NET DLL being called by LabVIEW 2010.
*1 I created a C# application to call DLL wrapper functions (hence an instrument). No errors. The call was successful. C# returned the device version.
*2 Then I created a LabVIEW application to call wrapper functions (hence our PSD instrument). No errors. The call was successful. But LabVIEW did not return the device version.
We are suspecting the problem is with "passing the string reference".
Attached is all code and screenshots.
We have tried different combinations to pass the string. No response to LAbVIEW version query.
Also attached the log of errors inside the remote DLL.
(Please note: The LabVIEW program is successfully communicating to DLL. I know that the DLL makes some actions based upon LabVIEW .NET command Wrapper.Discover)
Are you making sure that you are inputting the correct commands into the invoke nodes that comply with the dll file?
I am confused are you using labview to build the dll and exe? If so, the exe works but the dll doesn't correct?
DLL is C#.NET DLL.
In both cases described, I call C#.NET DLL from LabVIEW program.
Case 1: Run a LabVIEW VI from the LabVIEW environment
Case2: Create an EXE (out of labVIEW same LV program that wraps around the same C#.DLL) and run as a stand alone.
I''ll be glad to provide further clarification.
Are you running the executable first or the LV development? Have you tried running the VI on startup?
Usually, the problem we encounter is opposite, where the executable can't run the dll.
Try to create the 'response' string reference within your .net wrapper to ged rid of the 'out' parameter in LV.
Put additional debug information in your wrapper code.
Thanks both for inputs.
I run LabVIEW VI first. Then EXE.
Swapping the sequence ...same result.
rebooting computer...........same result.
The "response" IS a string reference within the .NET DLL.
Having a reference inside the DLL does not mean that you get rid of output parameter from the inovolke node. Does it?
This is Paul, another applications engineer here at National Instruments that will be helping you. So I'm still discussing with my colleagues about what the root cause of the problem could be. However, I did want to ask you whether or not this is the same DLL issue that you had discussed with Joel K, another applications engineer here at National Instruments? If so, I'll be able to sit down with him and get the root cause of this issue a bit faster. Thanks for your patience.