Reducing pre-filling for buffered analog output

[Catherine-B]

Hi Dan, 

I found a couple of examples that seemed to allow other people to successfully use the data transfer request condition during non-regeneration tasks, so it may be helpful to compare your code against them.

http://forums.ni.com/t5/Multifunction-DAQ/non-regenerative-analog-output-in-C/td-p/1144133

http://zone.ni.com/devzone/cda/epd/p/id/1733

Best, 

[dmorris]

I compiled and ran the first example you pointed to.  The author sets the data transfer request condition by calling:

myTask.AOChannels.All.DataTransferRequestCondition = AODataTransferRequestCondition.OnBoardMemoryHalfFullOrLess;

I set a breakpoint here, and checked the DataTransferRequestCondition at a few points throughout this function, by inserting this and looking at the value of "a" in the debugger:

AODataTransferRequestCondition a = myTask.AOChannels[0].DataTransferRequestCondition;

After he sets the buffer size, it's still OnBoardMemoryHalfFullOrLess.

After he commits the task, it's still OnBoardMemoryHalfFullOrLess.

After he configures the sample clock, it's still OnBoardMemoryHalfFullOrLess.

**** After he starts the task ("myTask.Start()"), myTask.AOChannels[0].DataTransferRequestCondition is now suddenly OnBoardMemoryNotFull. *****

Is this an API bug?  A driver bug?  Something specific to the USB-6216 (I don't have another interface with buffered AO to check this on)?  Any chance someone at NI can take a look at the standalone example I provided and try it on a 6216?

-Dan

[Spicy_Mystery]

Hi dmorris,

Just wanted to let you know we haven't forgotten about this issue.  We've been looking into it but have been unable to reproduce the error you're experiencing.

Could you give us some more direction into how we can reproduce the issue?  Possibly send us your code?

Please let me know!

[dmorris]

In my previous post (dated 10/11), I suggested some places to insert debug breakpoints in the example that Catherine suggested ( http://forums.ni.com/t5/Multifunction-DAQ/non-regenerative-analog-output-in-C/td-p/1144133 ).   That gives us a nice common starting point.

Did you try inserting those same breakpoints and running on a USB-6216?  Did you see the DataTransferRequestCondition change right after starting the task?

If it matters, I'm running on Windows 8 x64.

Thanks!

-Dan

[dmorris]

Any further thoughts on this?  I'm about to purchase another DAQ, and the resolution of this issue affects whether or not I can use a USB-6216: the problem I'm seeing (I can't push latency down below 8000 samples) basically makes closed-loop control impossible for low-bandwidth applications.  Would love some clarity on whether this is a fundamental limitation or not.

Thanks!

-Dan

[John_P1]

Is USB a requirement?  If latency is at all a concern you'll be much happier with a PCI or PCIe device.

The 8000 sample issue is a bit ridiculous though (appearing to be able to set the transfer request condition but then not actually being able to has to be a bug, right?).

If you have to use the 6216 for your application then the easiest workaround that I can think of (assuming there isn't any way to get the data transfer request condition working--I don't have the hardware to experiment) is to repeat samples and generate at a higher rate (not sure if you saw my previous thread).

Best Regards,

[Izzzzz]

Hey John & Dan, 

I reproduced the issue with the same hardware and noted the same behavior of setting the Data Transfer Request Condition and then when I read the property after the task was started it would only return Onboard Memory Less than Full. I am checking with some colleagues regarding if this is expected behavior for USB devices due to the transfer mechanism, and/or this feature should not be available for USB devices. Dan I would follow John's recommendation regarding moving to a device with better latency PCI or PCIe device, and or the information he posted in his linked thread.

Best Regards,

Izzy O.

Applications Engineer

National Instruments

Ni.com/support

[dmorris]

FYI I recently purchased a USB-6231, and I don't have this problem: when I set the data transfer request condition to "DAQmx_Val_OnBrdMemEmpty" or "DAQmx_Val_OnBrdMemHalfFullOrLess", it "sticks".  

So this issue does not appear to apply to all M-series USB devices, so far just the USB-6216.

-Dan

[John_P1]

There isn't an NI USB-6231, maybe you mean USB-6221?

The 622x, 625x, and 628x all share the same back-end design.  The 621x devices are unique compared to the other M Series however.  

To me, it seems likely that all 621x should exhibit the same behavior as what you see on your 6216.  If the USB-6221 does not show the behavior then I would expect the 622x, 625x, and 628x to behave similarly.

I'm not sure if this helps you at all or not, just pointing it out.

Best Regards,

[dmorris]

Right you are; it's a USB-6281.