USB DAQ module disconnects

[Manu01]

Hello,
I have a program running labview 2011 connected by USB to a NI- 9172 Daq .

During operation of the USB DAQ module disconnects and sometimes I wonder if the cause is the program 
( acquisition rate )?
This program runs 24 / 24 and performs temperature measurements ( thermocouples) + voltage measurements + relay drive .
I have to have constantly high acquisition rate to recover a voltage from an energy meter (pulse of 250ms )
Along the VI file for investigation.
If anyone could help me, that I would be of great help .

Cordially.

MinLabSmart.vi

[ensegre]

Style quite awful (stacked sequences, local variables, no modularization, and what - you open and close various files for rereading unchanged (?) data between each A/D and D/A operation?), so it's difficult, for me at least, to understand what you want to do. Anyhow, two suggestions which are a bit of a shot in the dark:

1. Open, define and keep open the Daq tasks properly. Don't rely on the auto behavior of DAQmx Read and Write if performance is of any concern.
2. Provided that opening delays are not of concern there, check for poor USB cables/flaky connectors/EM interference. I remember an occurrence I had where simply using shorter cables, wound a couple of turns over a ferrite core, solved random "resource unavailable" issues.

Edited June 7, 2016 by ensegre

[bbean]

Make sure all your power options are set so that the computer doesn't turn off when not being used (no hibernate, no sleep, no usb suspend, etc)

[hooovahh]

I'd also suggest you wire directly to the PC.  Using any hubs powered or unpowered is asking for trouble.

[Manu01]

Hello,

Following my investigations:

I am less convinced that the problem comes from the program.

I removed the USB cable connecting the module to the PC (It turns out that the cable had been installed
contained 2 extensions that were hidden in a buy electric chute). The total length of 3m.
This cable was nearby the 230V power cables of this cabinet.
So I replaced this set of cables by the original cable module and I physically isolated from the 230V power cables.
I also added a ferrite on the cable closest to the acquisition module and a second closer to the USB plug of the PC.

I also turned off when the PC starts the Auto Power Device Monitor "NI".
In case of disconnection and reconnection I had the message of this monitor indicates to me that the module was detected.
So I assumed (this is a guess ...) if my app is running and if the USB connection is lost and then found and if this "NI" Device Monitor detects the reconnection of USB , maybe it could "block" the acquisition ???. It does not concern the loss of USB, but only phoénomène blockage of acquisition ...

Last thing, on the PC that manages the acquisition, there was another application (foreign to LABVIEW) to
retrieve information about a different type of equipment with a USB cable to emulate a serial port running with FTDI driver.
I also fired this acquisition to eliminate potential conflict problem of address to another?

I attached some pictures to my post, if someone has an idea, it is welcome.

Thank you.

[hooovahh]

Yeah using the original cable, and using no extensions is a good test to see if it works in any situation.  You shouldn't have to have a work around, but if there isn't any other option, you can try to capture the error seen when the device is disconnected, then have your code retry to connect to the hardware with some amount of timeout so that if it goes away for a short time you can recover.  This is of course only if the DAQ you are trying to measure isn't a continuous signal in which case the only solution is to not disconnect in the first place. 

Some NI USB devices have firmware updates, is this one of them?  You can go into MAX, find the hardware, and there usually is a tab or button for updating the firmware.

Have you tried other USB ports?  They aren't all equal and some have less internal hubs than others. 

Have you seen this type of issue on any other computer?  It is possible the device is faulty.