Application works as executable but not as DLL

[Allen_W.]

I wish to convert an instrument driver written entirely in LabVIEW to a DLL so the instrument's functionality can be accessed with other programming environments such as Visual C++.  If I build an executable, the application works as expected.  I built a DLL which I tried to test by accessing it in LabVIEW with Call Library Function Nodes.  The LVDLLStatus function returns the value 1003, which is an error code for "The VI is not executable." 

The instrument communicates via RS-232 serial and the driver uses VISA.  I checked the "Serial Port Support" box in the Installer section of the Application Builder, and this apparently works because the executable runs OK.  Would it be possible that the executable can find the VISA support files, but the DLL cannot?

[MichaelChaney]

Hi CAW,

All LabVIEW built DLLs export the function called LVDLLStatus() in addition to the actual function(s) created. This function gets the module handle for the LabVIEW Run-Time Engine being used to run the DLL. The function has not been documented mainly because it is meant for our own internal use (R&D).  If your executable works properly, then your DLL should work properly as well.  Make sure you are selecting the correct function (usually the VI name) in the Call Lifrary Function Node.  The LVDLLStatus() function should not be used.

[Allen_W.]

Michael,

Thanks for the reply. The LVDLLStatus function is documented to a certain extent, in the LabVIEW Help under Shared Libnraries -> Exported Functions:

"The calling program uses this routine to verify that the LabVIEW DLL loaded correctly. If an error occurs while loading the DLL, the function returns that error. Pass a string buffer to the errStr input to receive additional information about the error. Set the errStrLen input to the number of bytes in the string buffer passed as errStr. You can use the module parameter to retrieve the handle to the LabVIEW Run-Time Engine being used by the DLL. Typically, you can leave this parameter as NULL."

If this function is not to be used by LabVIEW programmers, it should be so stated in the Help file.

So, this function is telling me the DLL is not loading correcty, but you are saying the 1003 code has no meaning and I should ignore it? The program does work fine as an executable, so do you have any suggestions as to how I debug the problem that is causing it not to work as a DLL? This is the function prototype:

short int _5020TVS(unsigned char Port, unsigned short int Action, double *Data, long len)

and the controls on the LabVIEW VI are:

Port (U8)

Action (Enum U16)

and the indicators are:

Data (Array of Double)

and this is the header file for the DLL:

#include "extcode.h"
#pragma pack(push)
#pragma pack(1)

#ifdef __cplusplus
extern "C" {
#endif

short __cdecl _5020TVS(unsigned char Port, unsigned short Action,
double Data[], long len);

long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module);

#ifdef __cplusplus
} // extern "C"
#endif

#pragma pack(pop)

Allen

[MichaelChaney]

Hi Allen,

I have attached a couple of simple VIs.  One just generates a random number and displays it, and the other adds a VISA resource open and close to the program.  I have built a shared library out of both, and one that uses the C calling convention (like your DLL) instead of the Standard calling convention.  If you are performing this test on your development machine, you don't need to create an installer.  When you deploy the application to a clean machine, checking the box to include serial support is the only extra step that is necessary.  The 1003 error you are getting should not be related to the serial support.  Try testing the Test.dll by calling the function in LabVIEW.  If the issue is related to your machine, then this dll should fail too.  If you open the Build Application or Shared Library wizard while your top-level VI is open, then it will automatically add the VI to your source files.  When it adds the VI, it uses the Standard calling convention.  I noticed that your header file shows you used the C calling convention.  I included a test dll that uses both, and I was able to get LabVIEW to call both correctly.  You could try using the standard calling convention with your application to see if this makes any difference.

If the Test dll without the VISA code fails as well, please let me know.  If you could post a small VI that demonstrates this behavior, I could try to build the DLL here.  This would let us know if the issue is related to your machine.

[Allen_W.]

Michael,

Thanks for the additional information and the VI's.  I was able to get the DLL working shortly before I saw your post.  I am able to access the DLL from LabVIEW.  The next step is to test it from a C program, then to test it on a machine with a clean installation.

Thanks again for your help.

Allen