02-09-2011 11:00 PM
This problem is NOT resolved.
The only solution that I or anyone else has found is to buy a different piece of hardware.
National Instruments does not seem to be interested in solving this problem.
Please reccomend a low cost DAQ from an alternate supplier to any of your colleagues.
If your DAQ is still under warranty return it to National Instruments.
02-15-2011 09:15 AM
I found a very strong correlation between the DPC latency and the occurance of this issue, a few days ago. On both my atom machines and my laptop, I observe a periodic spike in DPC latency using a tool called "DPC Latency Checker" (dpclat.exe).
These spikes occur whether the DAQ board is present or not, and when there's a spike while the DAQ board is running, the DAQ board throws the internal buffer overflow exception. The spikes are alleged (by the tool) to be caused by bad behaving drivers.
A Microsoft tool called "xperf" combined with "xperfview" can pin-point the driver. And I've used that tool on my Windows 7 laptop to observe that my graphics card driver is the culprit, but I skipped pin-pointing it on my atom boards and instead just disabled the audio/ethernet/"standard game point" devices using he Device Manager. It's been 92 hours and both boards have ran incident free (it's too early to know for sure if this just isn't fluke that it has lasted this long, but it looks very promising at this point).
Getting it to work on my laptop may be a "no-go" due to it being the graphics card, but if you get lucky and it's an audio or ethernet driver, your fix might be to just disable them.
Hope this helps!
08-10-2011 09:40 AM
I am having these issues on my 6008, having tried everything suggested in this thread. I too believe NI should have designed this product to not timeout on BUS delays and come up with a different solution.
Has anyone tried to run their Labview VI as ultra-high priority in windows?
My issue is that I use all 6 USB ports for video, I2C, and DAQ on a quad core T7600 dell PC. I still get timeouts. Since NI does not seem to have urgency on resolving this issue, I may have to find another competitor USB DAQ.
08-10-2011 12:39 PM - edited 08-10-2011 12:40 PM
Well, I'm not sure this applies to everybody in the thread, but we did discover that error -200361 can sometimes be returned incorrectly on the 6008/6009 when used with certain hubs on Windows 7, and by extension Windows Server 2008 (CAR #282875). The root cause is the mishandling of split USB transactions by the Windows 7 USB stack.
NI has implemented a workaround for this issue in DAQmx 9.4. If you are continuously encountering error -200361 on Windows 7, try setting the following property (only available in DAQmx 9.4 and later):
This sets the maximum amount of outstanding transfer requests to 1. NI's USB devices often utilize multiple outstanding requests to increase throughput, but this added throughput should not be necessary on the 6008/6009. The Windows 7 USB Stack is not handling multiple queued IRPs on full-speed devices (like the 6008 and 6009), so limiting the number of outstanding IRPs to 1 should be a reasonable workaround to the problem.
08-24-2011 09:55 AM
I see that there has been some development to this,
It's been a couple of months since I last puzzled with the unit, however:
Can this property also be set via VB.net? (programming in VS2010) Is the property available here also with DAQmx 9.4?
08-25-2011 11:58 AM
If you change the code to limit the number of outstanding IRPs to 1, this workaround will also work in VS2010. This exact node won't be available but you should be able to do it in code. Hope this helps!
08-25-2011 02:47 PM
I was able to look into this issue a little more and I have the code you will need. You will need to find what exactly to call since it will be specific to your code. For my example, I am going to be calling myTask. You can find what it is called in your code by looking for the following two lines (they may not be next to each other):
Private myTask As Task
myTask = NewTask()
Again, I am using myTask as the example. In order to call this property node, you will need to add the following line of code using your call from your program:
myTask.AIChannels.All.UsbTransferReguestCount = 1
Hope this helps!
09-07-2011 06:08 PM
Starting to have trouble with this problem. I'm using a windows 7 tablet. Error 200361 seems to suggest that the onboard 6008/9 memory is full. However, I notice that as soon as I change the buffer size for the task to something too low I get this error. I'm confused because I thought the buffer size was specifying a buffer in RAM on the PC not on the card? I thought in a continuous acquisition data was read from the card regardless of how often the task reads data.
I came across this property- "AI data transfer mechanism" property. The options are:
USB bulk = where data xfers independently from the application (this seems to be the default)
Programmed I/O = where data transfers take place only when DAQmx read/write are used.
Interrupts = Also application independent.
DMA = Direct memory access; also application independent.
I'm wondering which of these will work the best to avoid the memory overflow. Will test soon.
Also does anyone know if the xferReqCounts property was changed to be called xferReqSize or am I looking in the wrong place? DAQmx version is 9.3.5.
09-08-2011 10:30 AM
The property that you are looking for was only recently added in DAQmx 9.4 (see my post a few posts back). xferReqCounts is different from xferReqSize, and is what you will need to set if you are in fact running into the issue relating to the mis-handling of split transactions.
Keep in mind that -200361 could also be legitimately returned if the host computer cannot transfer data quickly enough across the bus--USB transfers are CPU dependant. The xferReqCounts property only fixes the issue where the error is erroneously returned. It's probably a good idea to download and install 9.4 to try out the new property in any case.