subvi randomly not working

[Pedro89]

Hi everyone,

I'm experiencing very odd behaviour from LabView and am hoping, you could help. I use a DLL for connecting to, writing to, reading back from and finally disconnecting from a USB HID device.

First step: init, sending a simple keep-alive, works fine (99% of the time)

second step: getVer, request to get the version from the device. There lies the problem. My SubVis for writing and reading are the same in both routines. Anyhow, in the GetVer routine, sometimes the writing part doesn't work. The called DLL tells me, 64 bytes (input buffer size) written and outputs a success message. Problem is, nothing really was written to the device. (I have another program to check the USB-stream from the device to the pc and there is no answer / the SubVi waits for input from the device and there is none).

Has anyone ever had a problem like this, where date doesn't seem to be transported correctly? (Sometimes it works without any problem, I have no idea how this could be possible.)

Thanks in advance, if I missed out on anything, tell me please.

Regards,

Pedro

[Norbert_B]

Pedro,

i understand that you wrap the DLL in some VIs. Those VIs are used in both cases you mentioned. The wrapper is executed "properly" in both cases, but your hardware interface (USB) does not work as intended.

What you can do is the following:

a) Check if the DLL works properly if called from other applications like C/C++, TestStand, CVI, ...

b) It is possible that the USB interface is still not ready for interaction once you send the command. So the command is stored in the IO buffer, but probable never sent out. Play around with timing/highlight execution to verify timing issues and maybe you have some kind of sniffer software at hand which enables you to verify that the command is set into the buffer as expected.

hope this helps,

Norbert

[Pedro89]

Hi Norbert,

the DLL that is being wrapped works fine in the tool, with which I can check, if the hardware sends anything back, so your point a) is checked.

I tried the whole highlighting thing and everything seems to go okay. I'll try different timing approaches, since sometimes it works and sometimes it doesn't seems to be traceable back to such a problem.

Thanks for your reply, but I am always open to more input.

Regards,

Pedro

[Norbert_B]

Pedro,

sporadic errors and malfunctions which seem to depend on timing are in general an indication for race conditions. So please make sure that you are not running into this issue.

Possible solutions:

- Make sure that the calls to the DLLs (call library function node, CLFN) are "serialized" using the UI thread for execution (settings dialog) if the DLL itself is "not thread safe".

- Make sure that the VIs you created as wrapper are called sequentially (or create on FGV as "API" for the DLL, the FGV being non-reentrant {default}). Please use dataflow programming to ensure order of execution (so no sequence structure please!).

Norbert

[Pedro89]

Hi Norbert,

I'm using signal flow, in this case the error in/error out to make sure the SubVis with the DLL calls are processed in the right order. I attached a screenshot of my GetVer routine. VID,PID and the serial number (SERNO_DUMMY) are usb parameters I need to communicate with the device.

In order of calling (in case the image isn't clear: connect, check connection -> case structure, write to hid dev., read to hid device in a while loop and repeat, until the write data is read (sometimes the hardware sends data I do not need, such as button values or poti-states), desonnect from hid dev.

6B is the GET_VER command of the hardware, 6C is the first element of the answer array, needed for comparison, if the right data has been read.

As I see it, there should be no race conditions or sequence problems. If you find any problems, be it the ones that can produce my error or just bad programming, please tell me.

Regards,

Pedro

[Norbert_B]

Pedro,

you are correct that the LV code seems to be free of race conditions IF this code is the only code running at a time.

But it is possible, that the writing in the DLL itself works asynchronously. For instance TCP is a protocol which "finishes a write command" as soon as the values are passed on to the write buffer for the TCP connection. There is no guarantee of any kind that the command is really available at the instrument once the writing in the software has been done.

I can imagine that your USB DLL is working similarily. So if you write too many data too fast, you will probably running into a buffer overflow without noticing. So "speeding down" the exeuction using highlight mode/breakpoints should do the trick here. If you highlight the execution and NEVER run into the issue (still not a 100% guarantee), you have overloaded the interface. Introduce wait functions in your code between access of the USB interface.

Norbert

[Pedro89]

Hi Norbert,

Sadly, waiting and/or highlighting do not solve this problem. Tried boh options more than just once. It's getting annoying. One thing I noticed: At times it works, at times not, but if it has worked once, then the other times afterwards (if I don't close the VI) it seems to be working permanently. Any guesses on that behaviour?

In the final version, there will be a big mainloop running in the background, the one from the caller/main VI. But for testing, I used these functions as stand-alone. Oddly enough, the DLL outputs a successful writing process and 64 bytes of data were written.

It seems to me as if LabView wouldn't let this data through to the device or isn't even reading it back from the DLL. I highly doubt that the DLL itself is erroneous, since it works fine with the test program it came with.

Are there any reported cases of LabView holding back data? 😄 Is there a way to monitor LabViews general I/O port, or the specific one, I use here to pass data to the DLL and from the DLL to LabView?

Regards,

Pedro

[Norbert_B]

Pedro,

i don't think that LV itself is the issue here. LV will just call the DLL and return once the function of the DLL finishes. So it rather seems to me that the DLL does not "get connection to the USB interface". Do you have an indication for proper functionality in the DLL?

Can you check if user rights do affect the issue?

Does changing the execution thread in the API VIs affect the issue?

Norbert

[Pedro89]

Hi Norbert,

changing the thread, in which the DLL call is executed, does not affect this error, neither does starting LabView with admin privileges. This sure is one stubborn error. The ConnectToHidDevice VI actually has a return value that indicates, if the connection was correctly established, if that's what you mean with your fist question..? Also I use the IsConnected VI as a case decider. So it should be all set for writing an reading.

Regards,

Pedro

[Norbert_B]

Pedro,

do you have something to check if the data is actually written to the buffer correctly?

If the DLL uses NI VISA, you can use "NI I/O Trace" to verify this. You can start this tool (if installed) using LV >> Tools >> Instrumentation.

hope this helps,

Norbert