6537 underflow error with two boards, but not with another

[ricsenior]

Hi all, 

We have three identical PC's, each with a NI PCIe 6537 card fitted. Our application generates a fixed amount of data clocked out at 40MHz. Two of the PCs report “Onboard device memory underflow” when running this application, the third doesn’t. If I swap the 6537 from the 3^rd PC with another PC, that PC starts working correctly and the 3rd PC now reports underflow errors. If I reduce the clock speed down to 20MHz, all three 6537/PCs operate without error.

I'm using DAQmx device driver version 8.8.0f2 and have updated the 6537 firmware to version 07052112.

I’ve attached code which exhibits this problem.

Does anyone have any thoughts or suggestions as to what might be causing this problem, and why the code below works with one NI 6537 card but not two others?

Thanks

Ric

[John_P1]

Hi Ric,

The error sounds like you are not transferring data quickly enough over your PCIe bus to the 6537s.  I am not immediately sure what could be causing this problem in 2 out of 3 boards or what might be different between the boards.  Do the three 6537s have the same part number?  Could you let me know what the part numbers are?  I would like to check if you have different hardware revisions.

Also, let me double-check to make sure that I understand correctly.  Do you have three 6537s on three seperate computers, and only one of the 6537s will output at 40 MHz, regardless of the computer that you are using?  Are you using the same PCIe bus when you switch the boards?

-John

[ricsenior]

Hi John,
Thanks for your reply. The numbers on the three boards are
  192203B-03    E7086E    "good" board  
  192203B-03    E7087D    
  192203B-03    E70861
Just to confirm, I have three 6537s on three separate computers and only one will operate at 40MHz, regardless of the computer used. The PCs we're using are Dell Precision 390, they only have one PCIe x1 slot available.
Regards
Ric

[John_P1]

Hi Ric,

I'm still looking into the issue, but I have a couple of questions for you in the meantime.  What is the result if you use a smaller buffer size (e.g. 1M instead of 256M samples)?  Also, do you still experience the same behavior if you don't export the sample clock?  I'll see if I can track down a 6537 over here to see if I can replicate the behavior you are seeing using your code.  Let me know the results of using a smaller buffer and not exporting the sample clock, and I'll get back to you as soon as I have more information.  Thanks!

-John 

[ricsenior]

Hi John,

Thanks for looking into this.

 I see the same problem with the following two lines commented out:-

     //DAQmxErrChk (DAQmxSetExportedSampClkOutputTerm(taskHandle,"/Dev2/PFI4"));
     //DAQmxErrChk (DAQmxSetExportedSampClkPulsePolarity(taskHandle,DAQmx_Val_ActiveHigh));

With a buffer size of 1MB, underflow is reported for ~50% of the runs.

Regards

Ric

[John_P1]

Hi Ric,

I tried your code using a 6537 and a Dell Precision 380 using DAQmx 8.7.2 and was unable to reproduce the problem--which version of DAQmx do you have installed on your computers?  I would recommend to update to 8.7.2 if you are not at that version so we can rule out one more variable.

Also, let's try commenting out the SetPriorityClass and SetThreadPriority functions for good measure.  Setting the Priority Class to Real-Time may be preventing important operating system functions from executing.  The more I think about it, this could be the explanation for the behavior you are seeing since the driver will consume less resources when running at a lower rate and consume them for a shorter period of time when generating less samples.

If the above suggestions don't offer any help, it's would be tempting to say that there is a hardware problem with the 6537s since we have confirmed that the code and computer will work with one of your boards but not the other two.  However, given the fact that the two boards run correctly at a lower sample rate, and that changing the buffer size improves performance (though not completely) leads me to believe there could be something else at play--whether that's with your DAQmx driver or with your code.  Could you try testing at various buffer sizes and report the results.  Since this parameter seems to affect the performance, it would be good if we could characterize exactly what is happening.

If none of this seems to be helping, I'd like to give you a call so we can go over everything on the phone.  I just need your permission to look up your information from an administrator if this would be ok with you.  Keep me posted on how everything goes, I look forward to hearing back so we can get this issue resolved for you. 

-John 

Message Edited by John P on 12-09-2008 06:59 PM

[ricsenior]

Hi John,

I was using DAQmx version 8.8.0f2, I tried last night rolling back to version 8.7.2 on the machine/board which reports underun errors. I've also tried commenting out the SetPriorityClass and SetThreadPriority functions. These two changes didn't seem to improve the problem.

I updated the code last evening to automatically sweep from 1KB to 128MB transfer size, and ran this code on two machines overnight. For each transfer size I ensured that 256MB had been transferred, before increasing the transfer size by a power of 2.

Results are attached, with the bad machine/board, it sometimes had a problem with the 1KB transfer size and never made it past a transfer size of 32KB without a problem. With the good machine/board no errors where reported all evening other than one error at startup, with a transfer size of 2KB.

At first glance, I'm guessing that the probability of an underflow error on a bad machine/board is related to the number of bytes transfered, rather than the transfer size.

Please feel free to give me a call.

Thanks for your assitance.

Regards

Ric

[John_P1]

Hi Ric,

I have another suggestion for you: try setting the DO_DataXferReqCond property using the following function: 

DAQmxSetDODataXferReqCond(TaskHandle taskHandle, const char channel[], int32 data);

The value we want to set the property to is DAQmx_Val_OnBrdMemNotFull, which will allow data to be transferred to the device any time the on board buffer is not full (by default, the data is only transferred when the buffer is empty, so at high rates you are pushing the limits of DMA transfers).

-John

[ricsenior]

Hi John,
Thanks for your reply,
If I include the new command DAQmxSetDODataXferReqCond

      DAQmxErrChk (DAQmxCreateTask("",&taskHandle));
      DAQmxErrChk (DAQmxCreateDOChan(taskHandle,"Dev2/port0","",DAQmx_Val_ChanForAllLines));
      DAQmxErrChk (DAQmxSetDODataXferReqCond(taskHandle,"Dev2/port0",DAQmx_Val_OnBrdMemHalfFullOrLess));

I get the error message
      Measurements: Specified property is not supported by the device or is not applicable to the task.

Do I have the correct command?
Thanks
Ric

[John_P1]

Hi Ric,

Sorry for the confusion, you cannot modify that property on a 6537--I should have verified before posting.  Could you try to run one of our continuous output examples.  You can find the examples at:

C:\Documents and Settings\All Users\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Digital\Generate Values

This is a tricky problem, so I'd like to see if one of the out-of-the-box shipping examples will work for continuous generation so we know if the card can receive data fast enough from the PC buffer.

-John