PXI-6551 Device Data Underflow

[broke]

Hello.

I have a PXI-6552.  I need to capture my DUT's (ADC) output after a very long and very precise sequence of vectors.  And I want to loop on this sequence over 1,000 times (to average the results).

The following script works:

script ADCcapture
  generate vecsetup marker0 (0)
  repeat 1000
    generate vecsample marker0 (424)
  end repeat
end script

Here are the waveform sizes for each of the waveforms listed:

vecsetup = 280 cycles
vecsample = 262,060 cycles

My sample record length = 512 and number of records to capture = 1,001

The first marker in my script is my Start Trigger for my Acq. session.  All subsequent markers are advance triggers.

As I said, this example works, but the "vecsample" waveform is much smaller than it should be.  It should be 5x bigger, but I do not have that much memory.

Fortunately, the bulk of "vecsample" is a repeating sequence of keep alive clocks (that in my above example are just exhaustively written out as continuous vectors).

I know that I cannot nest loops, and I now know that I cannot nest more than 55 instructions inside my finite (repeat 1000) loop.

So, I attempted to divide my break my "vecsample" waveform up into 3 sections that I could "split the difference" between vector memory and script size limitations:

script ADCcapture
  generate vecsetup marker0 (0)
  repeat 1000
    generate vecsampleA marker0 (424)
    generate vecsampleB
    generate vecsampleB
    generate vecsampleB
    ...  (note: I have exactly 50 copies of "generate vecsampleB")
    generate vecsampleB
    generate vecsampleB
    generate vecsampleC
  end repeat
end script

Here are the waveform sizes for each of the waveforms listed:

vecsetup = 280 cycles
vecsampleA = 1,660 cycles
vecsampleB = 4,884 cycles
vecsampleC = 16,200 cycles

vecsampleA contains unique stuff at beginning, including the previous sample period's ADC output.
vecsampleB contains 1,221x copies of the 4-cycle keep alive clock pattern that I need.
vecsampleC contains some unique stuff at the end.

Again, my sample record length = 512 and number of records to capture = 1,001

In the end, this generates the same number of cycles as the previous example:
1,660 + 4,884 * 50 + 16,200 = 262,060 cycles

However, when I execute this new script, I receive an error:

Exception caught
Detail:  [Error -1074115901] Windows Error 0xBFFA4AC3
DLL Description:  DAQmx Error -200316 occurred:
Measurements: Device data underflow. The device was not able to move data fast enough to keep up with the sample rate for the active script.

Run the operation at a lower sample rate, or look for the following in the active script: markers might be too close together, waveforms might be too small, waits might be too short, or subsets might be too small. If you are using an external clock, the provided clock might have gone away during your generation.

Status Code: -200316

Sorry for the lengthy post.  Any help is much appreciated!
Brian

PS: I found the following topic regarding this issue, but it did not help me understand my error (as it seems that my markers and waveform sizes seem to be big enough):

http://forums.ni.com/ni/board/message?board.id=70&message.id=10306

[Dan_K · Accepted solution]

Hello Brian,

I recreated your issue on my side, thank you for the detailed description of your problem, it made it much easier to figure out what was going on.

Although I am still looking into the root cause of the issue, there seems to be a problem with the number of commands in the repeat loop. You need 2 less commands within the repeat loop. This can be demonstrated as the problem by moving two of the commands outside the loop, maintaining the same number of lines in the script, but two fewer lines in the repeat loop itself.

In your case I would just double the size of vecSampleB and only run it 25 times. This should allow you to begin moving forward.

As for the underlying issue, when I find out I will let you know.

[broke]

Thank you for finding this solution Dan!  I'm not sure why I didn't think to try further shrinking the number of instructions in the loop (since I earlier found the 55 instruction limit by putting way too many instructions in the loop). 

I've read that Markers take up byte counts... perhaps 52 generates + 1 marker exceeds the real underlying requirement leading to "max 55 instructions in a finite repeat loop".

Brian