LabVIEW
struct input to DLL function call (LibFT260.dll, FT260_GPIO_Set) -- getting error 1097
Solved!
Hello,
I'm working on labview code to utilize the LibFT260.dll from FTDI. When I attempt to call the FT260_GPIO_Set DLL function I get error 1097. I suspect this may be related to the "report" input parameter which is a struct not being configured correctly. I read elsewhere that a struct input parameter should be a cluster in Labivew of matching layout and the Type should be "Adapt to Type" and data format "Pointers to Handles". I have not done this previously, so I'm suspicious I have something configured incorrectly or my input does not match... I just can't find it.
Can anyone find what I'm doing wrong or give suggestions on what to try to troubleshoot further. Thank you.
My VI for FT260_GPIO_Set call is attached. The .h file for the dll is also attached.
Here is documentation for the GPIO_Set function from the DLL application note:
There are two problems with what you try to do.
The first is minor unless you ever move to 64-bit LabVIEW (and according DLL). And don't say that is a long way away. The demise of LabVIEW 32-bit on Windows is not that far in the future.
FT260_HANDLE is a HANDLE. That means it is a pointer sized variable and should be configured as such in the Call Library Node. The according parameter in the LabVIEW front panel should be a 64-bit integer. However this is only a problem if you ever (have to) move to 64-bit.
The other problem is that there is a significant difference in the prototype for the SetGPIO and GetGPIO call!
LIBFT260_API FT260_STATUS WINAPI FT260_GPIO_Set(FT260_HANDLE ft260Handle, FT260_GPIO_Report report);
LIBFT260_API FT260_STATUS WINAPI FT260_GPIO_Get(FT260_HANDLE ft260Handle, FT260_GPIO_Report* report);
Do you see that little star after the RT260_GPIO_Report in the function prototype for the Get function? It means that that structure is passed by pointer. This is what LabVIEW does when you pass a cluster with Adapt to Type. However in the Set function this star is NOT present. It means that all the values in that struct are pushed directly on the stack. And there is no simple trick to tell LabVIEW to push a cluster like that on the stack. Instead you have to pass the elements in the cluster as individual parameters in the Call Library Node. But!!! The stack is 32-bit aligned in 32-bit mode and 64-bit aligned in 64-bit. So for a 32-bit call you have to create two 32-bit parameters, and you have to combine the two first 16-bit values in that cluster into a 32-bit value and the next 2 16-bit values into the second 32-bit parameter. In 64-bit mode however you will have to create a single 64-bit parameter and pack all 4 16 bit values correctly into that 64-bit value!
@acramer wrote:
In regard to 32 vs. 64 bit issue, the bitness you refer to is the bitness of LabVIEW software in use or the bitness of the target machine labview/the application is running on?
Yes, the OS bitness is irrelevant. It's about the subsystem your process is running in, either the 32-bit or 64-bit one that determines the bitness mode for this.
An yes 32-bit for non Windows LabVIEW versions is a past thing since 2017. The Windows version will sooner or later follow. My guess is at latest, when mainstream support for Windows 10 ends. While there were almost no 32-bit installations of Windows 10, it was still an option. Windows 11 is 64-bit only.
