"Communications failure" Exception

[drharris]

Hello,

We are currently using a U6 integrated into a custom software package using UD. The basic functionality works well, but unfortunately it has no endurance. After about 16.5 hours of continual running, we start to get LabJackUDExceptions until we restart the software. The exceptions simply say "Communications failure". Given the length of time before failure, I cannot run it in debugging mode to see what else might be going on. Nor are we around to look at the LED on the U6.

The U6 is running the latest (1.03) firmware and is connected directly to the computer via USB (no hubs). We are not using Stream mode, just the simple AddRequest looping method.

In an attempt to solve the problem, I try reconnecting to the labjack altogether (e.g. u6 = new U6()) and redoing all the settings. Sometimes, this seems to work and we start getting good data, but most of the time it does nothing, and we keep getting exceptions until we restart the software. When performing the reconnection, no exceptions are thrown and all settings seem to be accepted ok. It's almost like the driver itself is getting clogged up and isn't resetting itself until we let the software close and reopen.

Any ideas what could be causing this? Appreciate any help in advance!

David Harris
Cerex Monitoring Solutions

[LabJack Support]

Hello,

We are currently using a U6 integrated into a custom software package using UD. The basic functionality works well, but unfortunately it has no endurance. After about 16.5 hours of continual running, we start to get LabJackUDExceptions until we restart the software. The exceptions simply say "Communications failure". Given the length of time before failure, I cannot run it in debugging mode to see what else might be going on. Nor are we around to look at the LED on the U6.

The U6 is running the latest (1.03) firmware and is connected directly to the computer via USB (no hubs). We are not using Stream mode, just the simple AddRequest looping method.

In an attempt to solve the problem, I try reconnecting to the labjack altogether (e.g. u6 = new U6()) and redoing all the settings. Sometimes, this seems to work and we start getting good data, but most of the time it does nothing, and we keep getting exceptions until we restart the software. When performing the reconnection, no exceptions are thrown and all settings seem to be accepted ok. It's almost like the driver itself is getting clogged up and isn't resetting itself until we let the software close and reopen.

Any ideas what could be causing this? Appreciate any help in advance!

David Harris
Cerex Monitoring Solutions

When the U6 fails, can you run another program like LJControlPanel and find/communicate with the U6 without having to power cycle the U6?

The most common case of that error would be if something is just killing the USB link between the U6 and the PC. We had one user who was seeing something similar who found that the cause was plugging the LabJack into the USB port on his monitor. When the power saving mode for his monitor turned on that (for some reason) killed the power to the USB link.

[drharris]

When the U6 fails, can you run another program like LJControlPanel and find/communicate with the U6 without having to power cycle the U6?

The most common case of that error would be if something is just killing the USB link between the U6 and the PC. We had one user who was seeing something similar who found that the cause was plugging the LabJack into the USB port on his monitor. When the power saving mode for his monitor turned on that (for some reason) killed the power to the USB link.

We do not have to power cycle the labjack itself to recover. Typically, we can simply exit our software, start it again, and it will resume normal functionality, all without messing with the LJ or USB cable. This is what is so strange, because if I perform the exact same steps in software (reinitializing everything), it does not always recover. Sometimes it does, sometimes not.

I'll ask our electrical guy about the USB link. We use a single-board PC, and the USB cable goes directly to the root controller on the board, so I can't imagine that USB connectivity should ever fail. Perhaps we should try a new USB cable?

[LabJack Support]

We do not have to power cycle the labjack itself to recover. Typically, we can simply exit our software, start it again, and it will resume normal functionality, all without messing with the LJ or USB cable. This is what is so strange, because if I perform the exact same steps in software (reinitializing everything), it does not always recover. Sometimes it does, sometimes not.

When you reinitialize everything do you unload and reload the DLL? That is likely the difference compared to closing and restarting your program, and suggests that perhaps the driver is gummed up. Replace your current copy of labjackud.dll (in your system directory) with V3.18:

http://files.labjack.com/UD/

If you still have the problem, can you send us software to try and recreate the problem? Try to make the simplest program that still causes the problem.

Do you see the same problem on different computers?

Is it always about 16 hours to when the problem starts?

[drharris]

When you reinitialize everything do you unload and reload the DLL? That is likely the difference compared to closing and restarting your program, and suggests that perhaps the driver is gummed up. Replace your current copy of labjackud.dll (in your system directory) with V3.18:

We are using C#.NET, and I do not think it supports any type of DLL reloading (to my knowledge). This is the only difference I was thinking of, too. We will run an overnight test with the 3.18 and see if that solves the issue. If not, then I'll try to pare the program down to something more basic and send it in.

Do you see the same problem on different computers?

Yes, we have tried on the single board and also on a laptop. However, it was using the same Labjack. Maybe we will also try running it with a different setup completely (new labjack, computer) and see if it does the same.

Is it always about 16 hours to when the problem starts?

Almost like clockwork. However, when the reconnect procedure does work, it seems to be more random when it fails (1 hour, 8 hours, etc.)

I'll keep testing and update when I can narrow it down for you.