LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

USB-6009 USB port bug

Solved!
Go to solution

Hello,

 

I would like to ask for advice. This is the scenario in a nutshell:

We have a new project already written in LabView to control a mass-spectrometer of a K-Ar dating machine, and to record data from two analog channels of an NI USB-6009 device. Rate is the maximum: 24 kHz per channel.

 

After deployment we started to get a strange DAQmx driver error, but only when we used a certain USB port of a DELL laptop (this port was an 2.0, the others 3.0 SS). All other USB ports did not create this error. After several days, when we realized, the error is not in our LabView code, we have found this conversation in the forum:

http://forums.ni.com/t5/Multifunction-DAQ/USB-6009-overflow-error-on-continuous-mode-after-restart-o...

We think that, it would be strange to tell the client that, "please do not use this NI device on this port, because it is a bit buggy...", so

we were very happy, since setting this DAQmx property via property node solved the USB port error (see attached file).

 

However, a few days ago we have got an unexpected behaviour: our program during a finite mode DAQ finished the acquisition a few seconds earlier then it should have done. There was no error signal, but only this strange behaviour, looks like the "Task done?" DAQmx VI signalled "too early".

Since this "error", we could not reproduce it again (so far), we used the program several times without problems via this "slow" 2.0 USB port of the laptop.

 

Well, I am still interested in a final solution from NI to solve this problem in their products and in the DAQmx driver. I heard from many colleagues that, they run into this USB port bug many times, when they use NI HWs, and this problem is very annoying. I know the solution usually easy: plug the device to a different port. But I think these hardwares should work flawless on ALL USB ports...

 

 

 

0 Kudos
Message 1 of 7
(2,901 Views)

Hi Blokk,

 

I need some more information to work on this issue, so could you please help me and tell me some more details.

 

I would like to know if you have an error code and message?

It would be even useful to know the DAQmx driver version you are using and with OS you run.

 

Could you please give me that information?

 

Thanks,

Melanie

Best regards,
Melanie Eisfeld
Senior Applications Engineer, National Instruments Germany
Certified LabVIEW Developer
Certified TestStand Architect
0 Kudos
Message 2 of 7
(2,825 Views)

Hello,

we have the newest DAQmx driver installed: 9.7.0

OS is Windows7 Pro 32bit.

 

Error code is the same as in the linked discussion above:

error -200361

 

Regards,

 

0 Kudos
Message 3 of 7
(2,792 Views)

Hello Blokk,

 

at the moment there is just a workarround for this. This workarround is mentioned in the thread you linked above.

 

You have to set a property with a Property Node. You can find that property when you create a new Property Node "DAQmx Channel". Then select "Analog Input" >> "General Properties" >> "Advanced" >> "Data Transfer and Memory" >> "USB Transfer Request Count". This property has to be set to 1. You can change the Access Mode of the Property Node when you right click it and select "Change all to write".

 

If you don't see this property, right click on the Property Node and select "Select Filter...". Choose "Show all Attributes".

 

Regards,

Melanie

Best regards,
Melanie Eisfeld
Senior Applications Engineer, National Instruments Germany
Certified LabVIEW Developer
Certified TestStand Architect
0 Kudos
Message 4 of 7
(2,752 Views)

Hi,

 

Yes, we do use the linked workaround to avoid the bug. But even with this property node change we got unrealiable behaviour using DAQmx (but at least the code does not crash with error code). We are not sure yet about whether the strange behaviour (fixed time DAQmx task finishes earlier then supposed to do) is related to the combined use of the problematic (2.0) USB port + property node value changed to value 1.

 

Recently we will test the labview code via the fast SS USB 3.0 port (where we did not have any problems before), with the property node "AI.USBXferReqCount" value set back to default (4, if i remember well). If we do not get the DAQmx task bugs any more, it can mean that, the mentioned workaround is not a real workaround, only fixes crashing but still causing other DAQmx problems?

0 Kudos
Message 5 of 7
(2,744 Views)
Solution
Accepted by topic author Blokk

Hi Blokk,

 

so you have found your own workarround by plugging the USB module to another USB port.

 

You said the error only accures on special USB ports on your computer. This can be caused by an internal hub used in the computer. USB hubs can cause difficulties with NI hardware.

 

Do you have further questions?

 

Regards,

Melanie

Best regards,
Melanie Eisfeld
Senior Applications Engineer, National Instruments Germany
Certified LabVIEW Developer
Certified TestStand Architect
0 Kudos
Message 6 of 7
(2,733 Views)

Thanks, this is finally a clear answere, about the main cause of the problems 🙂

Of course, we will use the USB 3.0 ports since we want to avoid problems, but we were also very interested about why this happens.

Thanks again for the info,

Best Regards,

0 Kudos
Message 7 of 7
(2,726 Views)