CLFN problem with values

[Pedro89]

Hi everybody,

I am calling an external DLL via CLFN and have a weird problem. I'm using a function to connect to a USB device and when I manually enter the values for VID, PID and SerialNumber (these three values identify the USB device) in the SubVI, where the DLL is called, it works 100% of the time.

But whenever I call the SubVI in another VI and simply pass the values, it won't work at times. I used the lamp for debugging, but it did pass the values (as far as I can see) correctly.

Info: The DLL I'm calling is a wrapper for a C++ DLL, I pass VID and PID as unsigned words and SerialNo as const string*. The CLFN configuration looks like this:

int8_t ConnectToHidDevice(uint16_t VID, uint16_t PID, const CStr SerialNo);

Anyone ever had a similar problem? I'd be pleased with any input, this problem is driving me nuts.

Regards,

Pedro

[JonN]

Are you using the correct calling convention? The CLFN defaults to C, you may want to try setting it to stdcall.

[smercurio_fc]

Well, since the user said they have a VI that calls the DLL and it works 100% of the time, I doubt very much the issue is with the calling convention....

As for the question: is this subVI a VI that you wrote, or was it an example? Did you check to see if the "Preferred Execution System" for the VI was changed? Was the configuration of the DLL changed in terms of the "Thread" to use?

Can you post this VI?

[Pedro89]

Good morning everyone,

I'll attach the SubVI used for Connecting to the device through the DLL. The weird part I noticed yesterday (after posting this of course), is the fact, that the DLL-SubVi seems to work when I don't use the SerialNumber I obtain through another program (but which is correctly stored within a cluster), but hardwire one through a string constant to the SubVi input.

As if that weren't oddly enough, when I seperately start the SubVi and write the SerialNumber into the exact same cluster, but per hand, it works.

Hope this helps.

Regards,

Pedro

[rolfk]

Show us the prototype of the C function and preferably a parameter description. Your problems point clearly to an error in the Call Library Node configuration that does not match the effective function interface. But in order to see that one really needs to have not only the VI but also the C function declaration.

You can't diagnose a car problem only by looking at it's outside either.

PS: if you can show us the C code for your wrapper that would be even better.

[Pedro89]

Hi rolfk,

THat's a nice analogy, you got there 😉

The C-function-descriptor, as taken from the header file of the dll:

/**
 * Summary: Establishes a connection to a USB/HID device. The device is specified by its
 *          vendor id, product id, and serial number.
 *
 * Params:  usVendorId - Vendor id of the USB/HID device to connect to
 *            usProductId - Product id of the USB/HID device to connect to
 *            szSerialNumber - Serial number of the USB/HID device to connect to (UNICODE)
 *
 * Returns: Nonzero, if a connection to the device has been successfully established; otherwise zero.
 */
extern "C" SEN_USB_LABVIEW_API unsigned int ConnectToHidDevice(unsigned short usVendorId, unsigned short usProductId, const char* szSerialNumber);

Regards,

Pedro

[rolfk]

---

@Pedro89 wrote:

Hi rolfk,

THat's a nice analogy, you got there 😉

The C-function-descriptor, as taken from the header file of the dll:

/**
 * Summary: Establishes a connection to a USB/HID device. The device is specified by its
 *          vendor id, product id, and serial number.
 *
 * Params:  usVendorId - Vendor id of the USB/HID device to connect to
 *            usProductId - Product id of the USB/HID device to connect to
 *            szSerialNumber - Serial number of the USB/HID device to connect to (UNICODE)
 *
 * Returns: Nonzero, if a connection to the device has been successfully established; otherwise zero.
 */
extern "C" SEN_USB_LABVIEW_API unsigned int ConnectToHidDevice(unsigned short usVendorId, unsigned short usProductId, const char* szSerialNumber);

Regards,

Pedro

---

The red marked word is your problem.

[Pedro89]

rolfk,

So when I enter the text manually, i.e. through my keyboard, LabView accepts it as UNICODE, but when I read it with my function and write it into my Cluster, it does not? A quick google brought up, that I can use "force unicode" on string values on LabView, would this resolve my problem?

Regards,

Pedro

[Pedro89]

(I somehow can't exit my previous post)

EDIT:

The SerialNumber does not work, when I use Read from textfile to obtain it. Any possibility that LabView reads it with the wrong encoding?

Regards,

Pedro

[rolfk]

---

@Pedro89 wrote:

(I somehow can't exit my previous post)

EDIT:

The SerialNumber does not work, when I use Read from textfile to obtain it. Any possibility that LabView reads it with the wrong encoding?

Regards,

Pedro

---

I don't see your code, nor the text file nor anything else. Possible? yes, but it could be also your eye color which is causing this.

Seriously, you need to learn to pose helpful questions, otherwise nobody can help you.