DAQmxSetBufOutputOnbrdBufSize on M-series

[bburan-ohsu]

I'm trying to set the onboard buffer size for the output buffer to a value smaller than 8191 samples (which appears to be the default for the PCI-6259). I know I can set this on a X-series card (e.g., the PCIe-6321). However, when I use DAQmxSetBufOutputOnbrdBufSize with the PCI 6259 it seems to work. However, as soon as I write some samples and start the task, I get an error saying that the only allowable buffer size for the PCI-6259 is 8191.

If that's the case, how do I determine whether a DAQ card allows me to set the buffer size before I attempt to set this?

[Mathieu_R.]

Hello,

I do not have a precise answer, but I'll try to provide some elements.

Specifications of NI 6259 and NI 6321 do not show any differences about onboard buffer's configurability. Perhaps is there something to improve in NI hardwre documentation...

The NI DAQmx C Reference Help shows that the property Output » Onboard Buffer Size is supported by the NI 6259, but do not explicitly tells if all hardware supports writing this property (the property description is global to DAQmx C Reference help, not specific to a device).

Programmatically, you can use advanced task control to Verify task. This allow you to get the error before actually starting the task.

Additionaly, M series relies on NI-STC2, X series relies on NI-STC3. Does the ability to configure the onboard buffer size was available only on specific AO boards (67xx), may have been added for X Series, and is related to the NI-STC3 ? I don't know. Can someone of NI tell us what is there "under the hood" ?

An other point, why do you need to configure onboard buffer size? In most cases, DAQmx driver handles it for you...

Best regards,

[bburan-ohsu]

Controlling the onboard buffer size allows me to overwrite data that I have already uploaded to the general buffer. Once data is transferred to the onboard buffer I can no longer overwrite that. I like to write ~30 seconds worth (based on the sampling rate) to the buffer and continually provide samples every 2 seconds. The large buffer size (30 seconds) ensures that if the program ever stalls for some reason, the analog output won't run out of samples. However, as soon as a certain event (rising edge on a DIO line) occurs, I want to update the analog outputs to play a new signal. I want this signal to appear as soon as possible after the rising edge. So, I check where the analog output is pointing to in the buffer, add the number of onboard buffer size samples to that (plus a few extra samples as a fudge factor) and overwrite the rest of the buffer from that point. Smaller onboard buffer sizes means that I can I can change the signal sooner.

Thanks for the suggestion. I will set up a function to test whether the property is supported by configuring an analog output task, setting the onboard buffer size, then trying to verify it.

It would be great if a NI engineer can clarify this. It seems like a pretty big oversight in the documentation.

[DaSage]

You might try playing with the regeneration settings associated with your code. Analog output generation, by default, is in regeneration mode. This allows the DAQ driver to continually iterate through and output the data in the PC buffer. Non-regeneration mode, by contrast, requires that the user constantly provide fresh data (this should already be satisfied since you’re providing samples every 2 seconds, just set a long enough timeout). For your application, non-regeneration will keep what’s in the buffer as small as the amount of data you’re putting there. Use a DAQmx Write Property Node with RegenMode set to Do Not Allow Regeneration to change the default settings. Let me know if this helps!

                                                                                                 

As far as documentation goes, I’m not finding anything that exhaustively states whether or not certain hardware (M series vs. X series) allows for buffer configuration. I’ll definitely keep looking though! 

[bburan-ohsu]

I already have it set to not allow regeneration. The real issue is the onboard buffer size limiting how much of the buffer I can overwrite in response to an event (e.g., change of state on a DIO line).

[DaSage]

I’ve been talking to other engineers, and it turns out that you might actually need an X-series device, like you had mentioned, to set the buffer size. I’ve simulated both a PCI-6259 and a PCIe-6353 (NI’s recommended alternative to the 6259), and the buffer error only shows up for the 6259.

Could you implement queue architecture as a FIFO for DAQmx? If, for example, you’re only interested in monitoring so many data points at a time (discarding the rest) until you see the trigger, and changing signals as soon as possible after that, you could programmatically enqueue the new signal at the front of the queue (Enqueue Element at Opposite End).

This community page explains the concept a little bit better, if you’re interested:

https://decibel.ni.com/content/docs/DOC-12057

[bburan-ohsu]

Thanks! It appears that FIFO is not part of the DAQmx drivers, so I'd still run into the limitation of not being able to modify samples queued for generation once they are written to the onboard buffer. Regardless, my primary complaint is that M-series devices should not falsely report that you can set the onboard buffer size, nor is there a way to ask NI-DAQmx if setting the property is allowed. It makes it difficult for me to write software that is compatible with a large variety of NI acquisition devices.

[DaSage]

Could you possibly direct me to where you found the bit of information stating you could change the on-board buffer size for M-series devices? I've yet to find anything that explicitly states whether or not you can.