9215 lock-up after other USB device removed

[NVMS]

I am using a USB-9215A for continuous data acquisition. I interface to it using .NET 2.0 (C#) via NI-DAQmx v8.5. My task is set up to read simultaneous channels in continous acquisition mode.

A fault occurs when another USB device is disconnected - the AnalogMultiChannelReader throws this exception:

    NationalInstruments.DAQmx.DaqException: No transfer is in progress because the transfer was aborted by the client. The operation could not be completed as specified.

After this, the device can be reset okay, and passes the tests. But any subsequent attempts to start a task (be it in a .NET environment or the Measurement & Automation Explorer) is met by the exception:

    NationalInstruments.DAQmx.DaqException: Measurements: Specified property cannot be set while the task is running.

The only recourse from here seems to be to physically disconnect and then reconnect the DAQ device. The problem can also be resolved by restarting the PC. The device cannot just be disabled/enabled in the Windows Device Manager - this does not work.

Is the problem that there actually is a task still running? If so, is there a way to forcibly stop any tasks running inside the device?

Also, is it a known problem that removing another USB device causes the DAQ device to fail? Note: It doesn't always happen - only sometimes.

[Speedy_Badger]

Hello NVMS,

This is a peculiar behavior indeed. I have looked into the issue and I cannot find anything that explicitly reports the same symptoms in relation to the DAQmx 8.5 or the USB issue itself.

"Is the problem that there actually is a task still running? If so, is there a way to forcibly stop any tasks running inside the device?"

When you reset your device, the tasks that are currently running should stop as well. You can verify this by running a basic task in MAX and resetting your device. You will notice that the task stops running upon reset.

You could attempt to manually stop the task in code by referencing the task and using the clear task method in .Net 2.0, however resetting the device should do this.

I have a couple questions regarding your system setup that I am curious about, that hopefully will also lead us to a good solution.

1. What is the other USB device that you are disconnecting when this behavior occurs?
2. When you disconnect the device, are you disconnecting the device by physically removing the USB connector or are you disconnecting the device through your operating system settings?
3. Does this occur with any additional USB device, or only a specific one?
4. Do you have any other NI DAQ devices that show these symptoms?
5. What operating system are you using?
6. Are you using the USB slots on the front of your computer, or the USB slots on the rear backplane of the computer?

The USB slots at the front of the computer are simple extensions for convenience and are meant for simple USB devices such as USB drives and so on. For high bandwidth devices such as DAQ boards, it is recommended to use the USB slots located directly on the backplane of the motherboard.

From what you've provided so far it seems like this issue is related to how the operating system, the USB bus, and the USB devices are interacting with one another. See if you can answer the above questions, and include any additional information you think of and we will try to work through it. Thanks!

Regards,

[NVMS]

"You could attempt to manually stop the task in code by referencing the task and using the clear task method in .Net 2.0, however resetting the device should do this."

    Well the problem is present after my code stops executing. And once it's restarted, the task doesn't seem to exist inside the DaqSystem.Local.Tasks array.


To answer your questions:

1. I'm connecting and disconnecting a USB thumb drive. For context, the USB-9215A forms part of a datalogging system that is most often permanently installed in outback Australia. The thumb drive is used to copy off recorded data in cases where telemetry is not installed or is failing. Experimenting now, I'm finding that if I connect/disconnect a thumb drive through a USB hub, the problem doesn't occur - it's only when I connect it directly into a motherboard USB port.

2. Physically.

3. There is another proprietary USB device we use that is unstable in its own right - I have created a way (using a DO from a USB-6008 and a relay) of resetting the power on this other device programmatically. I have seen that the resetting of this other device also can cause the USB-9215A to wig out.

4. The USB-6008 doesn't appear to show these symptoms, however it is not used for continuous acquisition. I presuppose that it's only around the time the DAQ is acquiring that it's susceptible to the changes in USB configuration.

5. Windows XP. It occurs both on Pro and Home editions.

6. I'm using the USB ports the motherboard. As mentioned before, the workaround may be to include a USB hub inside the box, which acts to isolate the USB-9215A from anything else going on. This isn't ideal though, as adding anything else to the system inevitably adds to the power consumption. The devices we've chosen have been low-power industrialised components.

Cheers.

[Speedy_Badger]

Hello NVMS,

Thank you for getting back to me with more information. The behavior you describe points my thoughts to a USB bus issue being the culprit. You mentioned that using a standalone USB hub could be a potential solution. Have you tested this theory? I would be interested to know if this is the case.

You mentioned that you are physically removing the USB storage drive. Have you attempted to disconnect/disable the storage drive through the Windows interface before physically removing it? “Pulling the plug” on a USB device without properly disconnecting it in software can cause the OS and USB controller to behave strangely.

Can you attempt to set up the USB devices on a different system? This could help us determine if there is specific hardware involved with this issue or not.

Another test would be to set up a continuous acquisition task on the USB 6008 and see if you can replicate the behavior across all of our devices.

Finally, if your system supports it, see if you can connect the USB storage device to a different port than the 9215A. This solution is similar to using a USB hub, but without the extra power consumption.
If we can narrow down the source of the behavior to specific hardware we can take further action on this issue.

Regards,