LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling LV created DLL from LV

Howdy-

I'm trying to call a LV DLL from within LV (seperate project).  Once the DLL has been comppiled I'm using the Import Shared Library to create the node.

However when I try this I get an error message with the import that appears to have trouble with LVBoolean and int32_t.

 

I've created a simple DLL (adds a DBL to an INT 32 and creates a Bool when the sum is > 0). 

Compiling this DLL and trying to import it has the same issue.

 

Any clues?

Download All
0 Kudos
Message 1 of 6
(1,355 Views)

Hello Jeff_A,

 

I think the first step is to provide the exact error message you are getting.

 

Best wishes!

Amanda B.
Applications Engineer
National Instruments
0 Kudos
Message 2 of 6
(1,296 Views)
Also understand that I have seen some situations where a LV-generated DLL works fine -- except for when it is called from within LV. I never looked into the exact reasons because in the end user application it was going to be called from C++, and that worked fine.

Unfortunately, I also don't remember the exact problem -- except that it had something to do with memory allocation.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 3 of 6
(1,292 Views)

First question is, why are you trying to call a LabVIEW-built DLL from within a VI? There are much better ways to load external LabVIEW code. If you need to call this DLL from other languages as well, then you should get rid of the LabVIEW-specific datatypes (the error clusters).

 

The main cause of the error you're seeing is buried towards the bottom - it can't find the "extcode.h" header that defines the missing types LVBoolean and int32_t. You can add the path to the folder containing that file (it's in cintools, in your LabVIEW install folder) but you may still get errors, which you could probably resolve with an appropriate combination of preprocessor definitions. However, an easier solution is to modify the header file for your DLL. Remove the line that includes extcode.h, replace LVBoolean with "char", and replace int32_t with "int". Those are the same definitions that the header file would define. This does mean LabVIEW will create the datatypes with U8 instead of booleans, which you can replace yourself with a boolean after importing.

0 Kudos
Message 4 of 6
(1,280 Views)

@nathand wrote:
This does mean LabVIEW will create the datatypes with U8 instead of booleans, which you can replace yourself with a boolean after importing.

Except that the Call Library Node doesn't allow for configuration of an explicit boolean type (for obvious reasons as there is no standardized boolean datatype in C before C11 and even then the standard says nothing about if it should be a byte or the prefered integer size for the current platform or anything else). LabVIEW then uses Adapt to Type instead, which forces the skalar parameter to be always passed by pointer!

 

Most simple solution is to still use an explicit integer that is properly sized and convert between the LV Boolean and the integer on the diagram.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 5 of 6
(1,263 Views)

@rolfk wrote:
LabVIEW then uses Adapt to Type instead, which forces the skalar parameter to be always passed by pointer!

Coincidentally that would be the correct behavior here since the boolean parameter acts as an output and so needs to be passed by pointer... but of course you're correct that I oversimplified, and that forcing the use of a integer consistently would be better.

0 Kudos
Message 6 of 6
(1,235 Views)