DIO-32HS/6533/6534: How to continue after underflow?

[RonW]

Our test program is using port 0_16, and is not using port 2. That said, ACK2 is not connected to anything, and REQ2 is looped to P0.4.

If the breakout box is not present, then neither are our loopbacks; can we rely on floating inputs to the 6533 to float low, or is their impedance high enough to make that an unsafe assumption?

[Dan_K]

Hello Ron,

That would definitely be an unsafe assumption. When you leave an input floating you are effectively connecting it to a high impedance load. This can cause undesired behavior when performing acquisitions. If you want to insure that your inputs will always be low you can always tie them directly to ground.

[RonW]

Are there differences at the hardware level with how DAQmx and Traditional DAQ configure burst mode with the 6533? The problem of failing to write the 17th sample and timing out is unique to DAQmx. Traditional DAQ is immune. I made a LabVIEW program that allows me to send bursts using either DAQmx or traditional DAQ. In the SCB-68 breakout box, ACK1 is looped around to REQ1. Regardless of the packet size, Traditional DAQ sends the burst without error. I verified this with a storage scope. If the packet size is 20 samples or more, DAQmx drops the 17th sample, as if it were never part of the packet, and Wait Until Done eventually times out with error -200560, even though the scope shows that the last sample was sent and ACK1 is deasserted. Some 6533 cards are not subject to this problem, and some are. Some seem to work, then degenerate over the course of several minutes, with the probability of failure increasing over time. In our case we have two cards whose serial numbers are x22 apart. One works consistently, and the other only works for a few minutes after the computer is turned on, and eventually degrades to the point where it can't send any packets at all. The part numbers are the same between the cards, as are all the date codes except the DAQDIO-A. -This only happens with DAQmx. Traditional DAQ is immune. -This only happens on Promark A770 laptops with a PCI expansion bus. We tested it on two such systems. Other PCs don't have the problem. -The laptops have DAQmx 8.6.1f0. One desktop has 8.6.0f12. Another has 8.9.0f1. -It only happens with some 6533 cards, and there seems to be nothing that distinguishes cards that work from cards than don't other than their success or failure. -With burst mode, the error is -200560, regardless of the write speed. -With non-handshake mode, the error is -200621, regardless of the write speed.

[DJ_L.]

Hey Ron,

Check out the following Knowledgebase documents:

- Why Does My NI-653x Device Require Extra Clock Edges to Transfer Data When It Operates in Burst Mode...

- How Are the ACK and REQ Lines Controlled on the 6533/6534 DIO Devices?

- How Do I Reverse the ACK and REQ Pin Assignments for NI 653x Devices in LabWindows/CVI?

You can also check out the following example code: 653x Bidirection Bust Mode I/O in DAQmx

Most likely you are running into the issue mentioned in the first KB above. Have you tried to communicate between 2 different 6533's to see if you can get the communication working that way? Let us know if adding extra clock pulses helps or not. Thanks, and hope to hear from you soon.

Regards,

DJ L.

[RonW]

The KB you mention assumes an external clock, which we aren't using; we're using ConfigureHandshakingBurstExportClock. The problem still occurs if we use ConfigureSampleClock.

In both cases, the 17th sample is not generated if we write at least 20 samples. This occurs at any sample rate (we tested down to 1000 S/sec). The only difference between the modes is that with burst mode, the failure is a timeout on WaitUntilDone (-200560), whereas with sample clock mode, the failure is a bus underflow error on WriteMultiSamplePort (-200621). In both cases, an oscilloscope verified that the final sample was actually generated.

Interrupt mode works, but won't approach the sample rates we need.

Thanks.

[richipedia]

Seems like I am running into exactly the same problem. Has a solution been found already?