LabVIEW
How to call USB Reset Utility for Silicon Labs .dll
Solved!
Connected, I should get 1 or 0 because of its description, but I got 2147483647
But if I use signed or unsigned, it can only go to 0??
It's defined as BOOL, this is Microsoft speak for a 32-bit integer that is to be interpreted as boolean. With the following meaning:
FALSE is 0 and anything else is TRUE!
So define it in the Call Library Node as a 32-bit integer value. The DLL has no idea about you configuring it as a floating point or not. It simply writes a 32-bits integer number into the pointer passed on the stack to it. If you then go and tell LabVIEW "Look there is a double precision floating point!" the Call Library Node will dutifully believe your authority and interpret it as such. There is nothing else it can do as it can't ask the DLL: "Are you really passing me here a floating point value? Or is it maybe rather an integer? Maybe with the meaning that 0 is FALSE and 1 is TRUE? Or could it be that 12345 means you gonna crash, or maybe something else?"
The DLL does its thing as it was programmed by the programmer and LabVIEW does the thing you tell it that the DLL is doing. If they match that is great, if they don't ... well bad things will happen.
So change that back to a 32-bit integer, signed or not is not that important in this case. Then use an Is Unequal to 0 node to change it into a LabVIEW boolean. That's how it should work according to the API documentation. The documentation says that it should only return 0 or 1, but it could for whatever reason also return 0 and -1, that would still be according to what a BOOL is supposed to represent in the Microsoft Windows API. And if you tell LabVIEW that this is an unsigned 32-bit integer then that -1 will suddenly look like 4'294'967'295, which is simply the two complement of -1.
But your current configuration is utterly wrong. Not only is there a size mismatch (a double uses 64 bits, while the BOOL is a 32-bit integer value) but LabVIEW will pass in a (probably initialized to 0) 8 byte location to the DLL, which then overwrites 32 bit of that with its own value, resulting in one of the bits being set to one. Then LabVIEW goes and interprets this as 64-bit double precision value and voila, it is not 0 but far from anything intelligible to you.
It could be that for whatever reason that IsConnected = FALSE is actually the truth!
There is no sense in trying to interpret the data differently if you don't like its value. You will have to investigate why the DLL thinks that it is not connected.
