Bug: Running cdaq NI9264 Error -200018

[AdamBarnett]

I am running a Cdaq with several modules both input and output through the Matlab data acquisition toolbox.

I am running at ~7.8Khz, which I believe should be fine, but I am getting the warning:

Warning error with the daq  - Reduce the scan rate. DAC conversions could not be completed for all analog output channels of the NI 9264 (DSUB) (cDAQ1Mod1) within the specified clock period

Digging in I find the error code produced from the NI side is -200018 which suggest I am getting underflow, however as far as I can tell on my end and through the data acquisition toolbox code the data is all being queued upfront before starting the run.  I haven't been able to get much help from Mathworks so I was hoping someone here might have seen a similar issue.

[andres.vargas]

Hello Adam,

Underflow normally means that you are not putting enough data into the FIFO and on the host side the FIFO read is timing out.

Have you tried increasing your Output Frequency? If I read the NI 9264 datasheet correctly, it should handle up to 25 kHz.

[AdamBarnett]

Apologies I'm a little confused by your suggestion.  If I'm getting an underflow error then wouldn't increasing my output frequency cause the issue to get worse?  Or do you mean the frequency with which I add data to the FIFO?

[andres.vargas]

Hi there Adam,

If you increase your frequency too much you could fall into an Overflow problem. I do mean: "Write to FIFO faster".

[AdamBarnett]

Ah I see, in that case I don't know that I have the control to do that.  Using the Matlab data acquisition toolbox it does not seem that I have access to the frequency options.  In fact from my end it appears as though the entire data is all being queued prior to starting the acquisition session.  

Is it possible that the adding to the FIFO is happening behind the scenes?

Thanks a lot,

Adam

[andres.vargas]

Hi Adam,

I am not sure I follow what you mean by behind the scenes.

I suggest that you reach out to MathWorks Support and dig for a way to configure Output Frequency, it seems like too important a feature for them to not have. Have you tried adding to the loop?

[AdamBarnett]

Hi Andres,

Apologies, because I am working with the Mathworks data acquisition toolbox.  That in turn is internally interacting with a National instruments interface which appears to operate differently to the daqmx dlls.  As a result it is tough for me to know what is happening within both of those pieces of code.  It also means that I think I am using the wrong terminology in places as the Mathworks mostly uses its own.

To clarify the terminology, when you say Output Frequency do you mean the rate at which the data sent to the daq is sent out over its channels?  If so I have access to that, it is called the Rate in the Mathworks system.  If not then I'd appreciate some clarification as I'm not sure what that would mean.

I'm also I'm afraid not sure what adding to the loop means.  Within mathworks I am calling these commands on their 'daqsession' (which isn't exactly the same as the daqmx session I think):

session.Rate = 7800; (approximately)

session.AddChannel (for all of the channels)

session.QueueOutputData( data )

session.StartBackground( )

session.IsDone; (until it's finished)

Sorry for being verbose, but hopefully that helps you understand what is going on.

I will say that I've also opened a ticket with Mathworks, but my previous experience with this situation is that they will point to the NI side of the codebase as being the culprit (besides which I think these forums seem to understand the daq operations much more fully).

Thanks a lot,

Adam

[andres.vargas]

Hi Adam,

Try increasing session.Rate!

I simply meant asking for their help too!

[AdamBarnett]

Increasing session.Rate doesn't appear to help (in fact it may make the problem worse).  However it's also not an option I can use in the long term as I am using an external signal as a clock for the entire session which runs at that rate.