LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

USB communication failure under high CPU usage

Hello All,

 

I am facing some quite frustrating problem, occasionally USB communication failure under high CPU usage

 

the device is a monochromator connected to a computer using USB

 

The monochromator and dll is provided by vendor

 

Here is the details:

1. we use the dll provided to do the communication

2. we managed to called the dll (according to what the dll return)

3. we found that the dll is not sending the command occasionally under high CPU usage (according to usb sniffer)

4. the vendor of this dll is not sure what is happening

 

Basically we suspect few thing:

1. The way labview call the dll

2. the driver and kernel issue

3. other instrument accessing same resource

 

we are not computer expert so we are not sure so we randomly try something

 

Here is what we try:

1. set the reentrancy of the vi (personally i dont think this related)

2. use shared import library (personally i dont think this help much unless we have no clue how to use the dll)

3. The vendor added 1ms delay in this dll, managed to reduce the chance kink happening but still cannot eliminated it completely

4. setting labview priority to high in task manager (no effect)

 

I think we are like headless flies heading nowhere, can someone shed some light on us?

0 Kudos
Message 1 of 8
(3,768 Views)

@coloredsound wrote:

 

 

Basically we suspect few thing:

1. The way labview call the dll

2. the driver and kernel issue

3. other instrument accessing same resource

 

we are not computer expert so we are not sure so we randomly try something

 


1) Is pretty unlikely. If you did something wrong in the configuration it should not only cause errors in this situation but others too. And an error in LabVIEW itself is even less likely. It's understandable though that the vendor is trying to put the blame on any other piece involved than his own.

 

2) That's a very likely candidate. High CPU situations means also often high interrupt load and that could cause some race conditions in the kernel driver when handling the hardware interrupts, so that some get lost.

 

3) Do you have such an instrument? It's a nice idea but bears no substance, if such an instrument doesn't exist in your setup!

 

And please revert the time critical setting and such! If you don't know what you are doing, you are creating more problems with that than you can solve. If you haven't done so, setting the Call Library Node to run in any thread instead of the UI thread however might be a smart thing to do, as that could have a significant impact. There is a good chance that the vendor DLL is not thread safe and using running in any thread will cause bad things to happen but it's at least worth a try.

 

Your vendor really should b able to tell you if the DLL is threadsafe! If he can't or doesn't know what that means, he should hire a better software developer. Smiley Happy

Rolf Kalbermatter
My Blog
Message 2 of 8
(3,735 Views)

Hello rolfk,

 

I agree that driver and kernel issue is likely candidate and judging from my experience labview should be the last to be blamed

 

update for the instrument part

just now i isolated the monochromator from all others instrument, so i can exclude this candidate

 

as for the thread issue, regardless of UI thread or Any Thread option, the usb communication still failing from time to time

 

i need to persuade the vendor to seriously look into the driver issue

0 Kudos
Message 3 of 8
(3,723 Views)

@coloredsound wrote:

 

 

 

i need to persuade the vendor to seriously look into the driver issue


That's probably the difficult thing. Debugging kernel driver issues is a pain in the ass, especially if it is an error like this which only happens occasionally. Unless you do this pretty much daily, you often need to setup a system specifically for this and that is not an half an hour installation but a lot more.

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 8
(3,703 Views)

Well if it's USB it could also be cable lengths causing problems. How long are the cables and is it directly connected or through a hub? Is the hub powered? Does it work better with shorter cables and so on.

We had to move a setup around to be able to use shorter USB cables to a camera, else it would often fail.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 5 of 8
(3,651 Views)

I have seen several times problems with USB com, when a USB hub was used. Remember, laptops often use internal USB hubs, so you even get different stability when you connect the cable to different ports in a laptop...

The recommend best option is to use a good brand PCI to usb card in a desktop PC...

0 Kudos
Message 6 of 8
(3,645 Views)

Definitely try the other suggestions too! Cables or USB hubs can be a serious problem and so could be certain USB ports on your computer. So try to simplify your USB setup as much as possible when doing your tests.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 8
(3,624 Views)

Hello Blokk,

 

I am using pxi, I think it is good enough

 

the cable is connected through a hub, but it still having the same problem if I directly connect it to pxi

 

I will try the shorter length suggestion (the cable is quite long, it look like more than 1.5 meters)

 

0 Kudos
Message 8 of 8
(3,603 Views)