USB-6009 using MX driver freezes one one computer but not others

[cabele]

I'm using a USB-6009 to acquire two analog voltages at low data rates. I'm using the DAQmx routines, in particular the "Analog 2D DBL NChan NSamp" instance inside a loop. There's also a "Start Task" and "Stop Task" just before and after the read inside the loop.

On my development system this all works fine. But I have several systems in the lab that I need to deploy this application to, and I do that by building an EXE. One at least two other systems this works fine, but on one particular system (naturally, the one that I really want to use) it always freezes. Sometimes it's nearly immediate, other times it runs for a few minutes before locking up. It locks up hard - I don't even get an error message. If I close the application (using the X box) I get a small dialog box that says "Resetting VI:". That never completes or times out Once it locks up the only way I can recover is to unplug the USB cable and plug it in again - even the "Reset" in Measurement and Automation Explorer hangs without any message. And the LED on the USB6009 keeps blinking, like there's nothing wrong.

The lab systems have the current runtimes for labview and for DAQmx. I've actually gone as far as uninstalling all NI software from both systems and re-installing the same versions on both.

I'm having a lot of trouble thinking of any way to debug this, anyone have ideas?

[SnowMule]

What op system?

if windows,

Make sure all the "USB Root Hubs" have "Allow the computer to turn this device off to save power" UNCHECKED.

Are you going through a USB hub?  Make sure that hub has power saving off as well (I uncheck that with everything I can).  Tried swapping hubs/DAQs?

[cabele]

Yes, the OS is Windows 7 Pro (64 bit) on all the systems I'm using. In general I'm plugging the DAQ directly into a port on the laptop, although I have also tried it with a USB hub on the machine that fails. Didn't seem to make it any better or worse.

Additional information: when I do get an error (instead of just a lock up) it's "Error -200284 occured at Read Values.vi, Possible reason(s): Some or all of the samples requested have not yet been acquired." When I dismiss that error things are locked up just as I described previously, and I have to unplug the USB to recover.

"Allow ... device off..." was checked for all of the USB hubs on all of the systems I'm using. I unchecked it for all hubs on the problem system, but that doesn't seem to have made any differrence.

Thanks for the suggestion in any case.

[amezam]

Hello Cabele,

Are all systems using the same hardware and same settings? This code means there’s a timeout error in your application, check the KB Why Do I Get Error -200284 from my DAQmx Read VI?. You could try debugging the executable with the steps given in the KB Remotely Debugging Executables in LabVIEW, this will allow you to open the block diagram of the executable and use probes and highlighted execution to check what might be generating this problem.

Best Regards,

amezam

[cabele]

Yes, in all cases I'm using the same hardware (just plug the USB-6009 into each computer) and the same application as an EXE file.

I did look at the error -200284 page when I first ran into this problem, and none of those solutions seemed to help. In particular increasing the time, adding a delay between the "start" and the "read", and changing the sample rate didn't fix it. But that's not entirely surprising - the application often runs for several minutes (with the loop acquiring data every 100mS) before the fault occurs. And, of course, the same hardware and software works fine as long as I let it run (an hour or more) on other systems. 

Thanks for the link to the remote debugging page, I'll see if I can get that to work.

[c3mdc]

Was there ever a resolution to this proiblem?  I'm having the identical issue.  Works fine on one PC, crashes on another.

Thanks

[cabele]

>

> Was there ever a resolution to this proiblem?

>

Yes and no. Yes, the problem seems to have gone. No, there isn't anything I can tell you to fix it.

After some amount of unsucessful debugging I just ran it on one of the systems that worked. I also continued to make changes to the program, since it was in development. At some point I tried it on the problem system again and it works now. Unfortunately I have no idea what change fixed it, so I'm afraid I can't help you.