Problem with USB 9233 - 50405

[phonoX]

Hello,

I have a problem with my USB 9233 Card. The card is runnig for acoustic data aquisition in one of the test stands at one of our customers.

Sometimes I now get the error - 50405 No transer is in progress - The transfer was aborted by the client. ....

I have to dis- and reconnect the USB cable. After that - the device works again...
This happend ca. 2 times a week - very very bad for an automated test stand ...
I don't know the cause... can anybody help me?

the System is DualCore, WXP SP2,  NIDAQmx 8.5,  USB 2.0 (connected at the back of the pc)

[Jan_Kniewasser]

Hello phonoX,

thanks a lot for your detailed request. The information where you plugged in the device was helpful, because you are right, it´s one of the problems if you connect it at the front. Please install the latest version of DAQmx (we are at the moment at version 8.6.1) The following Link will help you.

DAQmx 8.6.1:     http://joule.ni.com/nidu/cds/view/p/id/950/lang/de

Please deinstall the devices before you install the new DAQmx Version. Then install the driver and after that plug in the devices again!

Please let me know if that helps!

Best wishes, Jan Kniewasser

NI, Germany

[balki]

Can you please post your application?  How long is the device typically running before it fails? 

[phonoX]

Sorry,

I can't post the application. It's part of our software package and isn't able to run in a stand alone mode. It's a c++ application.

We're using the app. for many years and we have a lot of test stands running in a solid mode at our customers. We never had such problems with PCI or PCMCIA Cards. This was the second project using the USB module in a customer project. We also have some 9233 modules for our project engineers, but never recognized this kind of problem.

[balki]

PhonoX,

I'm sorry, but let me clarify my request.  If you are requesting help, I need to know how you are using the device.  Are you running a finite or continuous acquisition?  Are you setting any attributes on the channels?  Are you explicitly transitioning task states?  Are you starting and stopping the task repeatedly?  How many channels are in your task?   At what rate are you sampling?  If you can't post the entire application, can you post at least a snippet of the code that is controlling the DAQ device without any of the processing logic?  It would greatly help in debugging your problem.

When I asked about time to failure, I meant how long does your application run before you see this failure?  I understand that this application may have existed for many years, but I'm assuming from your post that this failure case doesn't happen immediately when the task is started on the 9233.  There is some delay before you see your error case.  How big is this delay?  10 seconds?  10 minutes?  10 days?

[phonoX]

Hello,

thanks for your're reply.

We're running in continuous acquisition with 2 channels @ 25kHz.

Terminalmode and Range ist also set by the application.

If the app is started, the tasks will run cont. until it is shut down by the user. The problem is we cannot reproduce this failure. Sometimes we have no problems for hours (the application is sometimes offline, sometimes online) and then it happens immediately after going online and starting the tasks.  

We updated to DAQmx 8.6.1 as described above - with no effect.

we're using the following functions to run the app.

The code is a snippet from our NIServer.dll.

void CRNIChannel::CreateVoltageChannel(TaskHandle taskHandle)
{
 // could raised exception
 CString strChannel = GetNIChannelFullName();

 int enTerminalMode = DAQmx_Val_Diff;
 switch (m_enTerminalMode)
 {
 case NI_TERMINAL_RSE:
  enTerminalMode =DAQmx_Val_RSE;
  break;
 case NI_TERMINAL_NRSE:
  enTerminalMode = DAQmx_Val_NRSE;
  break;
 case NI_TERMINAL_DIFF:
  enTerminalMode = DAQmx_Val_Diff;
  break;
 case NI_TERMINAL_PSEUDODIFF:
  enTerminalMode = DAQmx_Val_PseudoDiff;
  break;
 default:
  enTerminalMode = DAQmx_Val_Diff;
  break;
 }

 CheckError(DAQmxCreateAIVoltageChan(taskHandle, strChannel, "", enTerminalMode,
  m_eMinExpectMeasureValue, m_eMaxExpectMeasureValue, DAQmx_Val_Volts, NULL));

 CheckError(DAQmxCfgSampClkTiming(taskHandle,NULL,10000,DAQmx_Val_Rising,DAQmx_Val_ContSamps,2));
 
 float64 eMinOnlineMeasureValue = 0, eMaxOnlineMeasureValue = 0;
 CheckError(DAQmxGetAIMin(taskHandle, strChannel, &eMinOnlineMeasureValue));
 CheckError(DAQmxGetAIMax(taskHandle, strChannel, &eMaxOnlineMeasureValue));

 float64 eResolution = 0;
 CheckError(DAQmxGetAIResolution(taskHandle, strChannel, &eResolution));
 
 int32 nResolutionUnits;
 CheckError(DAQmxGetAIResolutionUnits(taskHandle, strChannel, &nResolutionUnits));
 ATLASSERT(nResolutionUnits == DAQmx_Val_Bits);

....

/*********************************************/
  // DAQmx Start Code
  /*********************************************/
  
  CheckError(DAQmxStartTask(g_taskHandle));

  /*********************************************/
  // DAQmx Stop Code
  /*********************************************/
  if (g_taskHandle != 0)
  {
   DAQmxStopTask(g_taskHandle);
   DAQmxClearTask(g_taskHandle);
  }

[balki]

Thanks for your detailed response.  I'll try to see if we can reproduce the situation over here.  I did have one more question.  What is the make and model of your USB 2.0 host controller?   This can be determined via Windows Device Manager->Universeral Serial Bus controllers.  For example, mine says "Intel(R) 82801G (ICH7 Family) USB2 Enhanced Host Controller".   This is important as we have found idiosyncrasies with different host controllers, like the one detailed in this article: 

USB Host Controller Chipsets for use with M Series USB / NI CompactDAQ

 http://digital.ni.com/public.nsf/allkb/22E3AA18078CEDA886257195005574A4

[phonoX]

Ok

the device manager shows:

Intel(R) 82801GB USB Universal Host Controller 27C8

Intel(R) 82801GB USB Universal Host Controller 27C9

Intel(R) 82801GB USB Universal Host Controller 27CA

Intel(R) 82801GB USB Universal Host Controller 27CB

Intel(R) 82801GB USB2 Enhanced Host Controller 27CC

USB Composite Device

USB Root Hub

[kilobite]

National Instruments is aware of the -50405 problem but is not able to fix the problem. instead the just  talk in the forum about possible solutions, like installaing new daqmx driver and so on. The problem is with allmost all their USB  DAQ products making them USELESS !! -in allmost any application.   -To bad that is.

We have stopped using National Instruments products and i suggest u do the same. We have wasted 100000 + USD in developertime trying to fix the problem but without any luck.

Sad that National Instruments keep ther USB products on the marked making people wast theit time and mony trying to develop / selle product based on National Instruments equipment that will never work.

note. we have testet this on many different computers in a very long timeperiod, the problem occurs seldom on some units but it will happen.

JK

[Tiptop]

Hello phonoX,

We have been doing some research into this issue here at National Instruments and we like to know more details about your setup.

We have been unable to reproduce a -50405 error by simply running a task on the USB-9233.  Hence the long turnaround on this issue.  However, we have been able to reproduce this issue with other interactions in the system.  It appears that there may be issues with detecting a device being unplugged, which we are still investigating on our side.  Our theory is that with some USB controllers, when you unplug one device, other devices can sometimes see a voltage drop great enough to send a disconnect signal to Windows.  Then we return the -50405 error.  My guess is that your setup has other USB devices (then the 9233) that are being plugged or unplugged.  Is that the case?  Can you explain your setup a little more?  What does online and offline mean?  Are you powering down the computer?  Powering down a USB-hub? 

Thanks,

Justin