sampling in NIDAQmx for M an E series boards

[AndreyCherepenko]

  Hi.

  If it isn't right place for my question,
then could you please point me to proper one.

 I wonder about sampling in NIDAQmx.
When I try to use Internal Sample Clock with function:
DAQmxCfgSampClkTiming(taskHandle, NULL, rate, 0, DAQmx_Val_FiniteSamps, nsamp);
(all other things are default after DAQmxResetDevice(); board - PCI 6281);

nsamp can't be 1 but just 2 or more

I remember with old NIDAQ situation was the same.
If I right understand, there is some output register on the PCI board
which is loaded by Sample Clock. It needs one more pulse of Sample Clock
Does it mean the first sample is wrong
  (because the same clock is used for start ADC) ?

And should I call DAQmxCfgSampClkTiming with nsamp=N+1 (when I need N samples)
  and through away the first one which would be returned by DAQmxReadAnalogF64() ?


Thanks
  Andrew

[Elijah_K]

Hey Andrew,

The reason that 1 sample isn't allowed when acquiring a finite number of samples is because it defeats the purpose of the mode.  If you only want one sample at a time, then set the timing for 'On-Demand' mode.  Finite mode is used when hardware timing is necessary, which innately isn't possible when acquiring one sample.  Sampling on demand is timed by software, ie: the data is read when the software asks for it. 

When you need N samples, set the timing property for N samples.  The first sample is perfectly valid.

[AndreyCherepenko]

 Hi, Elijah.

 It sounds like as that restriction was made intentionally to teach for using of INDAQ 😉

 I have external trigger signal to start measurement and internal sample clock for the sampling.
Length of measured signal is defined by external conditions.
 I would like to measure that whole signal with maximum accuracy, so I need maximum
sample clock with certain number of samples which could be 1.
And it needs to respond quickly to some events, so I try to minimize time spending in NIDAQ.

In general features programme looks like: this.

Measurement parameters definition:

DAQmxResetDevice();
DAQmxCreateTask();
DAQmxCreateAIVoltageChan();
…
DAQmxCreateAIVoltageChan();
DAQmxCfgSampClkTiming(taskHandle,  NULL,  rate,  0,  DAQmx_Val_FiniteSamps, nsamp);  where rate and nsamp are defined from outside
DAQmxCfgDigEdgeStartTrig();

Then continuous loop:

DAQmxStartTask();
while(1) {
        if (DAQmxWaitUntilTaskDone()) {
                DAQmxReadAnalogF64();
                DAQmxStopTask();
                DAQmxStartTask();
                Some rendering  acquired data and output results
        } 
        watch out some events
}

I don't think it would be suitable to use 'On-Demand' mode here.

And I have another question about sampling.
We made some experiment to find out minimum delay time for
DAQmxSetDelayFromSampClkDelay();
We were extending that delay from minimum until influence of neighbour channels disappeared, because
we thought that multiplexer isn't fast enough.
We've got strange result - delay didn.t affect much on the influence but  sample frequency certainly did.
Because of that my first question was about validity of the first sample

[Elijah_K]

Why do you not want to use on-demand mode?  It sounds like you want a software controlled loop that acquires one sample every iteration, which is exactly when you use On-Demand mode.  Why are you trying to minimize your use of NI-DAQ?  What un-desireable behavior have you encountered?  Maybe with more information about your application I could help point you in the right direction.

The ghosting you described between channels occurs when you have floating inputs.  Charge builds up on the analog to digital converter, which isn't immediately dissipated when unconnected.  If you tie those to ground or connect a signal, you should not experience any ghosting.

[AndreyCherepenko]

 Hi, Elijah.

> Why do you not want to use on-demand mode?
> It sounds like you want a software controlled loop that acquires one sample
> every iteration, which is exactly when you use On-Demand mode.

 No.
 In each iteraion I get a number of samples which depend on external conditions.
 I measure impulse signals with different widths.
I use external trigger to start and internal sample clock with maximum speed
  to get maximum samples but sometimes impulse can be as short as just one sample.

> Why are you trying to minimize your use of NI-DAQ?

 Because the programme has a lot of other things to do.

> What un-desireable behavior have you encountered?

 The call to it consumes CPU time too much.


> The ghosting you described between channels occurs when you have floating inputs.

All unused channels were shorted.
And main purpose of our experement was to estimate of multiplexer switching time
  and worst recharging input parasite capacitance time.
Becase of that we connected signals with very different amplitudes to neighbour channels
(without overloading of course) and tried to mesasure influence between.


Thanks.
  Andrew

[Erik_J]

Hi Andrew,

If you only want to acquire one sample, I would not recommend "On Demand" mode because it is software timed and therefore is nondeterministic.  If you only want to acquire one sample, I would suggest using the Hardware-Timed Single Point mode because it uses hardware timing and yet only acquires one sample at a time.  The "Finite Sample" mode requires at least two samples because it uses a buffer.

As for your code, I would suggest an if statement like the one below:

if(nsamp = 1)
    DAQmxCfgSampClkTiming(taskHandle, NULL, rate, 0, DAQmx_Val_HWTimedSinglePoint, nsamp);
else
    DAQmxCfgSampClkTiming(taskHandle, NULL, rate, 0, DAQmx_Val_FiniteSamps, nsamp);


If you want to acquire continuously, then I would strongly recommend setting up your timing using the DAQmx_Val_ContSamps parameter, this will set up your mode as a "Continuous Acquisition".  With this mode, you do not have to stop and re-start the task on each iteration of your while loop - this will make your program much more efficient.

> And I have another question about sampling. We made some experiment to find out minimum delay time for DAQmxSetDelayFromSampClkDelay();
> We were extending that delay from minimum until influence of neighbour channels disappeared, because we thought that multiplexer isn't fast enough.
> We've got strange result - delay didn.t affect much on the influence but  sample frequency certainly did.
> Because of that my first question was about validity of the first sample

I'm not quite sure what you are asking here, both the delay time and frequency will affect the influence from other channels, and it is possible that the frequency will affect it much more.  If you would like more information about ghosting, the KnowledgeBases linked below can provide some good information.
KnowledgeBase: How Do I Eliminate Ghosting From My Measurements?

I hope this helps!

Regards,
Erik J
Applications Engineer
National Instruments

[AndreyCherepenko]

Hi Erik,

> I would strongly recommend setting up your timing using the DAQmx_Val_ContSamps

 need to wait aqusition of whole impulse before rendering.

But that that case I can't use DAQmxWaitUntilTaskDone(). Can I ?

>I'm not quite sure what you are asking here, both the delay time and frequency will affect the influence from other channels ...

Well. In other words I suspect that delay which is set by DAQmxSetStartTrigDelay()

   and  another one which is set by DAQmxSetDelayFromSampClkDelay(() are not added for the first sample.

Am I right ?

Thanks,

    Andrew

[Kevin_Price]

---

Erik: >> I would strongly recommend setting up your timing using the DAQmx_Val_ContSamps

Andrew: >  need to wait aqusition of whole impulse before rendering.  But that that case I can't use DAQmxWaitUntilTaskDone(). Can I ?

---

True enough, you won't be able to use "DAQmxWaitUntilTaskDone() anymore.  But you really don't *need* to.  I've made a bunch of utility functions for myself to provide "Wait until X or Y or Z or timeout" style functionality for situations like this.

For example, make a loop that queries the # of available samples.  Compare this with a variable holding the result of the previous query, then replace the 'prev_value' with the newly queried value.  If the values were different, save a timestamp to mark "most recent change."  Perform a short delay to let your thread sleep for 10 msec or so before the next loop iteration.  If the values were the same, compare the current time to the timestamp marking "most recent change".  If not much time has passed, do your 10 msec sleep delay before the next iteration.  If "enough time" has passed, you can know that you're done receiving sample clocks and can exit the loop and read all available data.  Somewhere in there you should compare time inside the loop with a time before the loop started to provide an overall timeout condition.

If I followed correctly, your app needs to be prepared for an finite but unknown # of samples coming in, including 1.  With normal finite acquisitions, you must define the # of samples ahead of time.  With continuous acquisitions, you don't need to know -- you can instead put some intelligence into the way you query task status and read data out of the acq buffer.  The end result can be the ability to handle *any* number of samples from 0 to 100000 or more.

-Kevin P.

[AndreyCherepenko]

Hi  Kevin,

I do measurement of impulse with known variable length

   and with unknown repetition frequency (about 10-100 Hz).

Erik's suggestion

> if(nsamp = 1)
>     DAQmxCfgSampClkTiming(taskHandle, NULL, rate, 0, DAQmx_Val_HWTimedSinglePoint, nsamp);
> else
>     DAQmxCfgSampClkTiming(taskHandle, NULL, rate, 0, DAQmx_Val_FiniteSamps, nsamp);
 

is quite good for me.

But, I think, his supposition about 'DAQmx_Val_ContSamps'  isn't.

How can I  discern adjacent impulses (and ExtTrigEvents)  ?

I couldn't find function which reports how many samples have been got since last StartTrigEvent,

  beside waiting with  DAQmxWaitUntilTaskDone().

All our sources have 50 ohms impedance, but  the first sample seems  to be sensitive to neighbour channel.

Thanks,

  Andrew

[Kevin_Price]

I only program LabVIEW so I really don't have much to offer on specific function calls from C.

The value of *continuous* acquisition is something Erik also said -- you wouldn't have to keep stopping and reconfiguring the task over and over depending merely on the special case of whether your # samples was either 1 or >1.  As he said, your code could run much more efficiently without these stop/reconfig/restart cycles.  Then again, if the triggering behavior is crucial you may need the stop/reconfig/restart anyway.

Some of your other questions may very well depend on your choice of continuous acquisition vs. finite or single-point, but I'm honestly not clear on what you mean with the question, "How can I  discern adjacent impulses (and ExtTrigEvents)  ?"  Could you explain this part for me?

-Kevin P.