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

[Dan_K]

Hello RonW,

When you are performing Burst Handshaking you need to have a Device Under Test (DUT) that provides the pause trigger when it is ready to recieve data. The following links describe this operation.

KnowledgeBase 1SSFQR00: How Do I Configure the Handshaking Lines of a 6533/6534 Board?

KnowledgeBase 35KDQAKD: How Are the ACK and REQ Lines Controlled on the 6533/6534 DIO Devices?

A good example of this type of generation in .NET can be found by going to Start»All Programs»National Instruments»NI-DAQ»Text-Based Code Support».NET 2.0 Examples and navigating to Digital\Generate Values\ContWriteDigChan_Burst\cs.

Take a look at these KnowledgeBase articles and the example and let me know if you have any questions.about setting this up. However, you will most likely still have issues with the generation you want to perform. The 6534 will work much better in this application.

[RonW]

OK, now I've got it REALLY almost working. I'm using burst mode.

I'm trying to transmit a 404-sample block using WriteMultiSamplePort(), followed by WaitUntilDone() on port 1. The samples are 16-bits, sent from port 1 to port 2. ACK1 (pin 3) is connected to REQ1 (pin 2). I set up the frequency to 1.5 MHz, which created a PCLK1 period of 700 ns.

Port 2 is set up as a change detection read beforehand, and one of the bits from port 1 is used to clock in data from a unit under test, so the sequence of statements is:

ReaderAsyncResult = TheReader.BeginReadMultiSamplePortUInt16(69, null, null);

TheWriter.WriteMultiSamplePort(true, TxBuff);  // Ushort buffer.

//***** This statement times out.

TheWriteTask.WaitUntilDone(TimeSpan.FromSeconds(WayMoreSecondsThanAreNecessary));

TheWriteTask.Stop();

while(!ReaderAsyncResult.IsCompleted)

{

     System.Threading.Thread.Sleep(1);

}

RxBuff = TheReader.EndReadMultiSamplePortUInt16(ReaderAsyncResult);

I'm testing this on two systems.

System 1 (desktop).

This system has a 6533 and a 6534. Regardless of which card I use, this works. ACK1 is asserted for 282.8 usec, i.e. 404 sample times.

System 2 (laptop).

This system has a 6533. ACK1 is asserted for 282.1 usec, i.e. 403 sample times. WaitUntilDone times out and throws an exception (-200560).

This 6533 was tested in the desktop system, where it worked correctly.

If I test the 6534 in the laptop, it works correctly, sort of. For some reason, port 2 sometimes doesn't see all the transitions from port 1, but that's another problem for another day; I want to get the 6533 working in the laptop.

The desktop has DAQmx 8.6.0f12.

The laptop has DAQmx 8.6.0f5.

Both are running Windows XP SP2.

Thanks.

[Dan_K]

Hello Ron,

How are you connecting the 6533/6534 to your laptop? Also, have you checked to see if there are any samples on the buffer before checking to see if the task is done? You can do this by adding a Available Samples Per Channel call from a DAQmx Read Property Node before the Wait Until Done VI.

Message Edited by Dan_K on 02-16-2009 11:43 AM

[RonW]

The 6533 is connected to the laptop using a PCI expansion chassis that is an available accessory for the laptop. I just wrote a test program that does nothing but configures the write task and does a write. This is in C#, so I don't have any actual VIs. Nonetheless, I added a line to get the available samples. So now the code is:

TheWriter.WriteMultiSamplePort(true, TxBuff); 

AvailableSamples = TheWriteTask.Stream.AvailableSamplesPerChannel;

TheWriteTask.WaitUntilDone(TimeSpan.FromSeconds(WayMoreSecondsThanAreNecessary));

AvailableSamples is always 1, regardless of whether I test it on the desktop, where it works, or the laptop, where it fails.

[RonW]

One more thing: my test program lets me set the speed and size of the write. If the size is over 19 samples, the write fails regardless of the rate- even if I set it to 1000 samples/second.

If I configure the task using ConfigureSampleClock(), the write fails with error -200621 (Onboard device memory underflow).

If I configure the task using ConfigureHandshakingBurstExportClock(), the write fails with error -200560 (Wait Until Done did not indicate that the task was done within the specified timeout).

The failures only occur on the laptop. On the desktop computer, there are no failures except an underflow at high rates when using ConfigureSampleClock(). I have eliminated the breakout box and cable as a source of the problem by testing them on the desktop computer.

Remember that the 6533 card that is failing in the laptop worked fine in the desktop. Self-test of the card under MAX in the laptop also works.

[Dan_K]

Hello Ron,

What exactly are you referring to in reference to the breakout box and cable? Are you referring to the PCI expansion chassis or the cable and breakout box coming out of the 6533?

As far as the PCI expansion chassis goes, do you know if it supports DMA transfers? How is it connected to the laptop? The use of PCI expansion chassis are not officially supported by our devices as they are not tested in this type of configuration.

[RonW]

The breakout box is the SCB-68, complete with the official National Instruments cable to connect it to the 6533.

The laptop is a Promark A770 with a 1.6 MHz Pentium M, running Windows XP SP2. The PCI expansion unit is an available option, and is attached to the underside of the laptop.

I assume the expansion unit does support DMA, because the card actually outputs all the data, except the 17th sample (see below). If DMA weren't supported, it wouldn't do this.

I just did some more testing, and here's what I found out:

• If the transfer size is less than 20 samples, all samples are output correctly.
• If the transfer size is 20 or more samples, the 17th sample is omitted from the output. The 16th sample is not stretched to cover it; it's as if the 17th sample were never part of the original data.
• This behavior happens regardless of whether I configure the task with ConfigureSampleClock() or ConfigureHandshakingBurstExportClock(), and regardless of the sample rate. The only difference is the value of the error that gets thrown.

[Dan_K]

Hello Ron,

The problem here is most likely with the PCI expansion unit. Unless you can suggest another variable that is different between the two systems that could be causing this problem, it is unlikely that you will be able to use the 6533 with this PCI Expansion unit.

[RonW]

I'm now running my test utility on a Dell Precision 490 desktop with a PCI-6533 card.

I am writing a buffer of 800,000 16-bit samples using burst handshake mode.

The sample rate is 1.5 MS/sec (actually a 700ns sample time).

ACK1 is looped back to REQ1 in an SCB-68.

Usually this completes within a second, but sometimes WaitUntilDone() times out (I gave it about 7 seconds), and I get a status code of -200560.

I just did 32 writes with 6 failures.

[Dan_K]

Hello Ron,

I would like you to try a couple of things.

1. First, do you have ACK2 and REQ2 connected? This is the second part of the handshaking and could be an issue.
2. Second, regardless of this connection could you try running the task at a slower rate, say 750 kHz.

We need to do the second step to try to remove the error condition. Once we get the error condition taken care of we can work backwards to get your application working.

Message Edited by Dan_K on 02-20-2009 04:16 PM