LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Choosing the right Call Library Function data types

Hi

 

I have a dll that I am trying to call using the Labview Call Library Function. But I get the error code 1097, which I believe is indicating that I may have chosen the wrong Parameter data types for the dll.

 

The dll requires the following parameter data types:

 

JacobJCA_0-1694686950309.png

 

For the "char" types I am using the "Type = String" and "String format = C String Pointer", but for the "bool" parameters I am a bit confused of which to choose. I would expect it to be a boolean type value, but I am not able select a "Boolean" data type in the Call Library function.

 

Any suggestions?

 

Thanks in advance

 

- Jacob

 

 

0 Kudos
Message 1 of 8
(871 Views)

sizeof(bool) is implementation defined. Either find out how the library was compiled or try integers of different sizes until no exceptions occur.

0 Kudos
Message 2 of 8
(853 Views)

Trial and error with a call library node is not a good idea - maybe except you can debug the DLL.

What bool is, should be explained in the documentation. Most documentation do not include such informations. Search for the C header file and find out what bool is or ask the developer/vendor of the DLL.

0 Kudos
Message 3 of 8
(830 Views)

If it helps, this is the explanation on the different parameters

 

JacobJCA_0-1694693786396.png

0 Kudos
Message 4 of 8
(820 Views)

bool is originally a C++ datatype only but since C11 I believe, also standard C. However the C standard always refrained of mandating specific sizes for any of its datatypes and bool is not different. It only requires a datatype that is able to represent two states. Theoretically a bit is enough but most CPUs are unable to process single bits efficiently, so the C standard allows for any size the compiler builders finds most suitable. Most C compilers including MSC choose 1 byte but that is partly a feature of the generally used x86 CPU architecture which thanks to its legacy compatibility is still very efficient in byte access (at the cost of several million transistors in microcode programming). Other compilers for other CPUs can and likely will use different sizes such as 32-bit integers.

 

As long as you program on x86/x64 you should be safe assuming bool to be an uint8_t. However note that BOOL is a specific Windows API datatype and always occupies an uint32_t.

 

In this particular case using a bigger integer than 8-bit in LabVIEW should still work. Parameters are always passed as 32-bit aligned elements (64-bit in 64-bit application mode) and aligned to the LSB. So if you pass a 32-bit integer, LabVIEW will initialize all 32-bits on the stack and if the function then only evaluates the LSB it will still see the right thing. The opposite is of course not true. Passing an 8-bit integer to a function may or may not clear the upper 24-bit on the stack slot and if the function then tries to interpret it as more than 8-bits it may read garbage.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 8
(793 Views)

By using the uint8_t the dll call with parameters then look like this:

 

JacobJCA_0-1694754464489.png

 

But it still fail.

0 Kudos
Message 6 of 8
(768 Views)

At first: If such an exception occurred (error 1097), I always close labview completely. In my experience, there could be sometimes strange side effects which can result in additional erros.

As Rolf stated, bool is a byte in C++ but you don't really know, which compiler/compiler options used. Using a unsigned 32 bit interger for a 32 Bit system (or 64bit in 64 bit application mode) should be save.
Another possible issue is the calling convention. I have seen lot of DLL API documentations not describing the used calling convention. In this case you can also try to switch between stdcall (WINAPI) and C.

0 Kudos
Message 7 of 8
(753 Views)

Well, try to make it an uint32_t instead. It should not make it worse for sure.

 

Other things to consider:

 

- correct calling convention?

- that original function definition doesn’t quite look like valid C syntax. Neither can it be Python nor Pascal really so I wonder.

 

Unless something changed in the last C standard, you can’t omit the parameter datatype for subsequent parameters that have the same type.

Rolf Kalbermatter
My Blog
0 Kudos
Message 8 of 8
(741 Views)