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

[RonW]

We're using a PCI-6533 via .NET 2.0 to output a file. In our application, the timing of the output is not critical, but it is important that the output not be corrupted with spurious transitions or missing data.

We are getting an underflow error. Is there some way to tell the driver to simply continue if this error occurs, maybe by telling the task to start again after some more data has been written to the buffer?

[Dan_K]

Hello RonW,

As I see it you have two choices in this situation:

1. You can write all of the data to the buffer from the file. If this is not possible you can try to break it up into as large of chunks as possible.
2. Or, you can perform a series of finite write tasks where all of the data is written to the buffer before the task starts and it closes out after generating those samples. You could then loop back around and perform a new task to generate the next set of samples without worrying about an underflow.

[RonW]

The problem is not that the computer can't keep its own buffer full; the problem is that the card (a 6533) has a very small onboard buffer, and can't read from the computer's buffer often enough to keep its own small buffer from getting empty.

In C#, I'm using try and catch. Is there something I can do, on catching the -200621 error, to simply resume the ongoing write operation?

Thanks.

[Dan_K]

Hello RonW,

In short, when the -200621 error occurs the current write operation has been aborted by the driver.

There may be another way. At what rate are you trying to generate with your device?

[RonW]

2 MHz, 16 bits wide.

Can I stop the task, then restart it using

TheWriter.WriteMultiSamplePort(true, EmptyArray);

to send the data remaining in the buffer without losing any data, and without sending any extraneous data?

As I mentioned, exact timing is not important; the data stream contains clocking information. But it's important that the data stream not be corrupted.

[Dan_K]

Hello RonW,

The problem isn't with the data coming from the disk, but the small onboard memory of the PCI-6533. There are a few things you can do:

• Slow down your generation.
• Perform a task that allows data regeneration.
• Use the PCI-6534. The PCI-6534 has much deeper onboard memory and would be much more appropriate for this type of task.

[RonW]

There's a command:

TheTask.Timing.SampleClockUnderflowBehavior = SampleClockUnderflowBehavior.PauseUntilDataAvailable;

which exists, but which is flagged by

TheTask.Control(TaskAction.Verify);

as not supported or not applicable to the task (error -200452).

I'm configuring the task as follows:

TheTask.Timing.ConfigureSampleClock(
     String.Empty,
     ClockRate,
     SampleClockActiveEdge.Rising,
     SampleQuantityMode.FiniteSamples,
     SamplesToTransmit);

and invoking the write using:

TheWriter.WriteMultiSamplePort(true, Buffer);

Can I configure the task some other way (handshaking burst mode?), or invoke the write differently to allow the "Pause until data available" option?

Thanks.

[Dan_K]

Hello RonW,

The different properties of DAQmx property nodes are device specific. This means that certain properties are only supported by certain DAQ devices. Unfortunately the Sample Clock Underflow Behavior Property is not supported by the NI 6533/6534.

[RonW]

I set up the write to use handshaking burst mode:

TheWriteTask.Timing.ConfigureHandshakingBurstExportClock(
     String.Empty,
     ClockRate,
     DigitalLevelPauseTriggerCondition.Low,
     ReadyForTransferEventLevelActiveLevel.ActiveHigh,
     SampleClockPulsePolarity.ActiveHigh,
     SampleQuantityMode.FiniteSamples,
     SamplesToTransmit);

This almost works. ACK1 (PFI 6) is looped to REQ1 (PFI 2) externally, which is a preexisting condition I have to accept and work with.

With the 6534, this works fine. But on the 6533, it doesn't. The 6533 refuses to assert ACK1 until after REQ1 is asserted.

I tried:

TheWriteTask.Timing.HandshakeStartCondition = HandshakeStartCondition.Immediate;
TheWriteTask.Triggers.HandshakeTrigger.ConfigureNone();
TheWriteTask.Triggers.StartTrigger.ConfigureNone();
TheWriteTask.Triggers.PauseTrigger.ConfigureNone();

in various combinations, to no avail. I didn't get an error, but they just didn't work.

I have a separate system at my desktop that has a 6533 with nothing connected to it, so it doesn't have the loopback from ACK1 to REQ1. If I configure the write as above, but set DigitalLevelPauseTriggerCondition.High instead of Low, it works without any of the additional Timing and Triggers statements.

Is there any way I can actually force this task to start and run regardless of what REQ1 does?

Thanks

[RonW]

From experimenting using the 6533 at my desk, it appears that the

TheWriteTask.Triggers.PauseTrigger.ConfigureNone();

function does not work when writing using handshake burst mode and exporting the clock. Using this function causes the write to time out, both in C# and in LabVIEW (using the Pause.Trigtype property).

According to the online documentation, this is a supported function of the 6533, so I don't see what I'm doing wrong.