Working with NI USB-6353

[conprove]

Hello, everybody!

     I´m using the USB 6251 OEM for over two years without biggest problems, but my applications are increasing complexity and NI start to offer NI USB 6353, with many improvements, mainly about speed transfer.

     My problem is: using 6251 I run an application that generates analog data with 100KS/channel (2 channels) and generates a digital stream data with 1MHz, 8 bits wide. Both tasks are Nsamples mode, without regeneration and can´t stop or loose data while running. It works really fine on 6251. On labview, just changing the necessary (using Daq Assisant to replace tasks) to use 6353 an error message appear on screen:

     "Onboard device memory underflow. Because of system and/or bus-bandwidth limitations, the driver could not write data to the device fast enough to keep up with the device output rate. Reduce your sample rate, or reduce the number of programs your computer is executing concurrently."

     If 6353 is faster than 6251 why this error just happen on 6353? Is 6353 worse inthis case than 6251?

Cristiano

[stilly32]

Hi Cristiano,

Can you please post your code? Both of these are USB so as far as transfer rates they are both USB Bandwidth limited, but neither should have problems with the tasks you are descibing. One thing that comes to mind - port 0 on the 6251 is only 8 bits wide, so 1MS/s = 1MB/s USB Bandwidth. However on the 6353 port 0 is 32 bits wide, so if your code is just referencing port 0 then 1 MS/s = 4MB/s USB Bandwidth. If your physical channels were "<device name>/port0/line0:7" then they would be equivalent.

This still shouldn't be a problem unless you have a lot of other USB traffic or just a really slow system.

Thanks,

Andrew S

[conprove]

Hi!

     Thanks for your fast reply. Follow the VI used to make the tests. As I said I´ve just started to work with USB NI-6353 and it´s a very simple test.

     Our product software development is made in VB .net 2005 plataform. Just to make the initial tests I´m using an Evaluation version of Labview 2009 to start the tests.

Cristiano

[conprove]

     Hi,

     the problem related still hapens.... On both DAQs I´m using a 8 bits wide digital stream and the channel are setted 8 bits wide too, keeping the same transfer rate. I can´t believe in loss of performance using USB 6351 instead 6251. A newer and more expensive DAQ is worst than an older one?

Maybe I´m doing something wrong.

     Ideas????

Cristiano

[stilly32]

Hi Cristiano,

I was able to reproduce what you are seeing. This appears to be a bug and I have filed a corrective action report (#258362) to R&D. One thing to note, it is not a problem with the device streaming data - if I set either the AO task or the DO task to continuous instead of N Samples then I do not see the problem, even though the device is streaming the same amount of data when non regeneration is enabled. It appears to be an issue of starting/stopping both tasks over and over again - for some reason it is causing a problem with the AO.

As far as a possible work around - does your application require you to start and stop your waveform generations (which is what the DAQ assistants are doing) or can you just let DAQmx continue to generate the waveform over and over again in HW? What are you trying to accomplish? I'm hoping we can find a short term solution while we are investigating the bug.

Thanks,

Andrew S

[conprove · Accepted solution]

Hi Andrew,

     I´m waiting a work around to fix this bug. In my application I use this way to generate waveforms to get more control. The application control how many cycles are generated on each step, depending of digital inputs, digital output stream also is controlled. This way is realy important have these both tasks working at same time. We have the same tasks on 6251 and we decided to migrate to 6353 because it has more channels and improvements on communication.

     Thanks for everything and I´m waiting a report to fix this bug.

Cristiano

[stilly32]

So one simple work around, use DAQmx Control Task and unreserve the task after each DAQmx Stop (right click on the DAQ assistant and select "Open Front Panel to see what the assistant is doing for you.) The start / stop process will be slower, but at least you'll avoid the error.

Hopefully this will meet your needs until the bug is resolved.

Thanks

Andrew S

[gaving]

I know this has been resolved, but I just wanted to show that DAQmx is not that hard to program in, and gives you more control over the state of the hardware than when you use the DAQ Assistant.  When I program it this way I also do not get the error you saw.  All of these functions can be found on the DAQmx palette and their context help can give you more information how to wire them up.

-gaving