05-28-2017 03:17 AM - edited 05-28-2017 03:20 AM
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?
05-28-2017 05:05 AM - edited 05-28-2017 05:16 AM
@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.
05-28-2017 06:25 AM
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
05-28-2017 11:04 AM
@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.
05-29-2017 02:07 AM
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
05-29-2017 02:23 AM
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...
05-29-2017 05:45 AM
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.
05-29-2017 09:44 PM
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)