DAQmx flaky on certain computers with some PCI-6533 cards.

[RonW]

We're using DAQmx to use a PCI-6533 card in burst mode.

If we send 20 or more samples out in burst mode, regardless of the sample rate, the 17th sample is omitted and Wait Until Done times out with error -20056.

If we send 20 or more samples out in regular timing mode, regardless of the sample rate, the 17th sample is omitted and the Write fails with error -200621.

If we send less than 20 samples out in either mode, they are all sent correctly and there is no error.

This problem only exists on Promark A770 laptops with a PCI expansion chassis. Regular desktops are immune.

This problem only occurs with DAQmx (LabVIEW or Visual C#). Traditional DAQ is immune (LabVIEW only, so far).

This problem only occurs with some PCI-6533 cards. Others are immune.

If we swap cards between laptops, the problem follows the card.

Cards that don't work seem to be flaky about it. They'll work a little bit at power-up, then degenerate to over the next few minutes to the point where a write test is virtually guaranteed to fail.

We're using WinXP and DAQmx 8.6.1.

[Margaret F.]

Hello,

Thank you for posting to the NI Forums! I suspect that the problem has to do with the use of the PCI exansion chassis. We do not officially support our products in these expnasion chassis because we have yet to find one that succesfully and reliably works. Please try plugging the expansion chassis into the desktop and see if you get the same behavior. Please feel free to ask any more questions you might have about this issue.

[RonW]

Since the problem only occurs in the laptops, not desktops, I'm guessing that's the case.

But since the problem only occurs with DAQmx, not Traditional DAQ, is there be some way of "detuning" DAQmx, maybe with start parameters for the service, or an entry in an INI file?

[Doug_L._Bear]

What do you mean by "detuning?"  Traditional DAQ is a lower level driver and so may not have the built in device handling that DAQmx has, which could be the cause of the issue here.

[RonW]

I'm guessing that something is close to the borderline here- a number of wait states programmed into a register, or the amount of time between writing to register A and reading from register B. By "detuning" I mean changing the critical quantities parametrically. Although this might entail a hit on the theoretical peak performance, we aren't pushing that.

Using interrupts instead of DMA works, but only gets us about 5% of the speed we need.

[Margaret F.]

Hello,

It looks like you have another forum thread for the same issue. We do ask that you do not duplicate issues as each forum is monitored by an engineer here at NI and will be posted to. I have spoken to Dan who is researching this issue and will be posting to that forum thread soon. In the future, please direct all posts related to this issue here. Thanks!

[RonW]

I apologize for the multiple posts; I'm approaching this problem from multiple angles (one angle per thread), and one of the responses I got told me to post on a different forum.

My understanding of the problem has evolved. Initially I thought it was a garden variety 6533 buffer underrun, but it looks like that isn't the case, so the subject of my initial post is no longer accurate.

Thanks.