poor analog output performance (error 200018)

[Daniel_Kiracofe]

  Hello.  I have a PXIe-6124 board with pxie-8102 realtime controller.  the board is speced at 4 MS/s analog output (single channel), but I am having problems getting it to work at anything above about 500 kS/s.  I am attaching my example program below.  If I set the rate to 500k, it works.  If I set to 1M, it does not work and I get error 200018 (DAC conversion attempted before data to be converted was available).  I am using DMA transfer.

  I also tried increasing or decreasing the number of samples written per loop (between 50 and 300), and using a timed-loop in labview real-time.  That gives basically the same result (sometimes I get error 200016 instead, "Onboard device memory underflow").

  Because the controller is a dual core controller that is literally doing nothing else (what I showed is the entire program, nothing else running),  I'm sure that I must have some software setting wrong.  I cannot believe that this controller cannot keep up with this card.  Does anyone have any suggestion on what I could try?

  Labview version is 2010 and DAQmx version is fairly recent.

[Kevin_H.]

So I can start by telling you that the memory underflow is being caused by not loading samples into the buffer as fast as the device is trying to use them. Have you used any of the stock NI example programs to test? I'm still looking into some of those errors, but for now the more information/testing you can do, the better (using stock NI examples helps us narrow the problem away from configuration and gives us a fighting chance to recreate it on our end)! It sounds like both errors are actually underflow related (meaning the data you're trying to write isn't being provided to the buffer fast enough to be output).

In case you've never used them, the examples you'll most likely want to look at are under the example finder (Help->Find Examples...) Hardware Input and Output->DAQmx->Analog Generation->Voltage.

[Daniel_Kiracofe]

Hi Kevin. thank you for your suggestion. I have tried the example "Cont Gen Voltage Wfm - Int Clk - Non Regeneration".  this seemed to be the example closest to what I wanted to do.  If I choose sample rate = 1 MS/s and buffer size = 5000 samples, it works.  But if I choose 4000 samples (or less) it does not work (same 200018 error).  Of course for this simple example the buffer size does not matter so much, but my target application is going to be read some data, perform calculation, write some data.  I need to have a relatively small latency between the input and output.  5000 samples = 5 ms loop rate, which is not acceptable for my application.  My ideal latency between input and ouput would be around 40 - 50 us, and I could probably live with something in the 200 us range, but 5 ms is just too much.  So I guess my question is really how can I take this example and get it to work with smaller buffer sizes / faster loop rates?  If 5 ms is really the best this hardware can do, I'll be forced to buy some analog ICs and do the operation the old fashioned way.

Now, when I do analog input (for example, take my example vi that I posted previously except analog in instead of analog out), I am able to do 4 channels at 4 MS/s each (i.e. 32 MB/s) and maintain an average loop time of 56 us.    My analog output example requires only 2 MB/s data transfer rate (16 times less) and only a loop time of 200 us (~4 times slower) yet it does not work.  So how come analog output performance is so poor compared to analog input performance?

any suggestions?

[Daniel_Kiracofe]

also, for what its worth, this error does not appear to caused by slow loop rates.  for example, if I intentionally slow down the loop in the example (by adding a 6 ms wait) then I get a different error ( 200290 generation stopped to prevent regeneration of old samples).  So it appears to me that error 200018 is not caused when DAQmx Write vi is not called frequently enough, but rather when the data transfer to the device quick is not enough.  Again, 2 MB/s does not seem like it should be taxing the PXIe bus that much, so I think I must have some software setting wrong...

[Kevin_H.]

The problem is that you're not getting the FIFO filled with data fast enough. Why exactly this is happening, I'm not sure. In order to run at 4MS/s you'd need to fill the buffer with that amount per second. Which means your loop execution would be at best 8191 (The FIFO Size) Sample Size every 2.04775ms. To get down to the speed you want your smallest number of samples each time should be 200 S every 50microseconds. Any less than that and you'd get an underflow. How are you determining how fast your loop is executing? 

[Daniel_Kiracofe]

  I am attaching another example.  Perhaps the problem will be more clear.  In this one, I use the real-time module timed loop.  I have a rate of 1 MS/s and I am trying to write X samples every X microseconds. Because of the real-time module I can tell if any loop is late.  I observe the following behavior

X = 50 or less  "Loop was late" indicator is on, and I get error 200290.  clearly, this problem is the loop speed.

X between 100 and 4500.  "Loop was late" indicator is off, and I get error 200018 (or sometimes 200016).

X = 5000 or greater.   "Loop was late" indicator is off, no DAQmx errors.

So, although the CPU is able to keep up with a 100 us loop speed, the DAQmx write appears to be unable to keep up with anything faster than about 5 ms loop speed.  This 5 ms is the same number that I found with the labview example program.   I can accept the fact that the CPU just won't be able to do an infinite loop speed.  But why the data transfer to the card is so slow?

[Daniel_Kiracofe · Accepted solution]

Ok. I figured it out.  Here is an interesting fact.  At a rate of 1 MS/s, attempting to write 4096 samples every 4096 microseconds works perfectly fine.  But, attempting to write 4095 samples fails!!  4095 is of course 2^12 - 1.  So it looks like the DMA was only performing transfers of 4 KB at a time, so when it got 4095 samples, it was waiting for one more sample to start the transfer, but by the time it got that sample it was too late.  I changed the DataXferReqCond property to "less than full".  Now I can write about 150 samples at a time instead of 4096.  Much improved!

By the way, this would be a really really good thing to put in the error message text for error 200018 so that other people don't spend several days tearing their hair out like I did...

thanks for the assistance

Daniel

[Kevin_H.]

That's really interesting! Thanks for sharing your solution! I'll pass the suggestion on.

[DanCee]

Very handy - thank you.