Internally-clocked digital output with DAQmx Base (C API), M-Series

[jgd]

Hello,

May I please ask for a pointer to some example C code that shows how to perform internally-clocked digital output on the PCI 6289? (The "ContWriteDigPort-ExtClk.c" sample assumes an external clock source.)

I'm using DAQmx Base 1.5.0f2 on Mac OS X with the C API. My goal is to be able to pass a vector of samples to DAQmxBaseWriteDigitalU32(), and have them clocked out on, say, Dev1/port0. I haven't yet figured out the right invocation of DAQmxBaseCfgSampClkTiming(), so my writes only service a single sample per call. Ideally, the behavior would be to step through the sample vector once, and hold the last value (rather than looping through the sequence again).

Thanks!

[WM_John_Weeks]

According to the DAQmx Base Readme, DAQmx Base supports only "correlated" DIO on M-series devices. That means that you can't do timed DIO with a timer dedicated to the DIO ports.

Consequently, the externally-clocked example is actually the one you want. You don't actually have to use a truly external signal for the clock. You can use a counter/timer to generate a pulse train, and specify the counter output as the clock signal (/dev1/counter0internaloutput). It is also possible to set up an analog input or output task and use that clock to time DIO (/dev1/ai/sampleclocktimebase or /dev1/ao/sampleclocktimebase).

The shipping examples include only a continuous DIO example. In the call to DAQmxBaseCfgSampClkTiming, substitute DAQmx_Val_FiniteSamps for DAQmx_Val_ContSamps. One of the strengths of DAQmx is that writing tasks are all pretty similar, so you can look at an analog output example to get the flavor of what you need to do for DIO. The main difference being that you have to specify an explicit clock signal for DIO, and you have to use the functions appropriate to setting up DIO channels and writing DIO channels.

[jgd]

John,

That's good information; thanks!

Setting up a pulse train on Dev1/ctr0, then getting Dev1/port0 sample clock timing from /Dev1/Ctr0InternalOutput seems to work for a sample mode of DAQmx_Val_ContSamps. However, if I pass DAQmx_Val_FiniteSamps to DAQmxBaseCfgSampClkTiming() for the DO task, I get the error:

"Requested value is not a supported value for this property. (Sample Mode)"

There's an AO example (multVoltUpdates.c) which passes DAQmx_Val_FiniteSamps with no ill effects on this hardware.

Also, I noted that DAQmxBaseWriteDigitalU32() fills in `sampsPerChanWritten' with the value 1, even though I can confirm with a scope that multiple samples are being output. This contrasts with the AO example I mentioned (as well as another example, contGeneration.c), in which DAQmxBaseWriteAnalogF64() hands up the value 512.

Any thoughts?

Thanks again!

[WM_John_Weeks]

You said:

"Requested value is not a supported value for this property. (Sample Mode)"

I say:

That's annoying!

I see in the M-series Help file:

>The FIFO supports a retransmit mode. In the retransmit mode, after
>all the samples in the FIFO have been clocked out, the FIFO begins
>outputting all of the samples again in the same order. For example,
>if the FIFO contains five samples, the pattern generated consists of
>sample #1, #2, #3, #4, #5, #1, #2, #3, #4, #5, #1, and so on.

That makes it sound like the "retransmit" mode is special, but I suppose it's possible that it's the default,
and DAQmx Base doesn't do anything else.

This is the sort of problem that made me abandon DAQmx Base.

You also asked:

Also, I noted that DAQmxBaseWriteDigitalU32() fills in `sampsPerChanWritten' with the value 1, even though I can confirm with a scope that multiple samples are being output.

And I don't really have much to say. Digital I/O is a bit peculiar, even with DAQmx. DAQmx Base is *more* peculiar. I had a similar question a while back (that I can't find any more) and it turned out to be specific
to DIO.

Sorry I can't offer any better solution.

[Tom_W_[DE]]

Hi All-

To address a few questions posted in this thread:

Correlated digital I/O is the only hardware-timed mode supported by the physical M Series hardware; no dedicated timing engine for digital I/O operations exists.  So, this is not a shortcoming of the NI-DAQmx Base driver as the same situation is true even for NI-DAQmx.

Finite correlated digital output operations are not supported under NI-DAQmx Base.  The only valid choice for correlated digital I/O is DAQmx_Val_ContSamps.  This has nothing to do with the "retransmit mode."  That mode, also commonly called regeneration mode is the default mode of operation and the only one possible with NI-DAQmx Base. 

I am curious about your use of DAQmxBaseWriteDigitalU32().  Are you writing an array of data using that function or a single point at a time within a loop of some sort.  The sampsPerChanWritten return value doesn't indicate the number of samples physically clocked out by the card, but rather the number of samples buffered with that particular call to DAQmxBaseWriteDitgitalU32().  Given this info, is it possible that the value is being returned properly?  If not, please post back with a portion of your code that replicates what you're seeing and I will be happy to look into it.

Thanks a lot-