DAQmxRegisterSignalEvent with different callbacks DAQmxCfgChangeDetectionTiming

[John_P1]

//Initialization
DAQmxCreateTask("",&samplHandle);
DAQmxCreateAIVoltageChan(samplHandle,"Dev1/ai0","",DAQmx_Val_RSE,-10.0,10.0,DAQmx_Val_Volts,NULL);
DAQmxCfgSampClkTiming(samplHandle,"/Dev1/PFI0",1000000,DAQmx_Val_Rising,DAQmx_Val_ContSamps,1051);   //replace PFI0 with whichever PFI line you have your external clock connected to
DAQmxStartTask(samplHandle);

//Call this in a loop while program is running
DAQmxReadAnalogF64(samplHandle,1051,10.0,DAQmx_Val_GroupByScanNumber,data,1051,&numRead,NULL);
myFunction();

//Close references at end
DAQmxStopTask(samplHandle);
DAQmxClearTask(samplHandle);

The read call blocks until 1051 samples are available so this is effectively a polling approach.  You could put the read into an EveryNSamplesEvent callback if you prefer to keep it event-driven.  If your clock is really at 1 MHz without any pause between lines then you might need to read more than one line at a time in order for the software to keep up.

The input task runs continuously--assuming you want to sample every pixel then this is necessary.  There isn't a trigger since I am assuming you start the software before you start driving the CCD.  You could add a start trigger if you need to synchronize the start of the task to the first sample in a line.

Best Regards,

[NazRB]

John, thank you. This is what I did:

{
DAQmxCreateTask("",&samplHandle);
DAQmxCreateAIVoltageChan(samplHandle,"Dev1/ai0","",DAQmx_Val_RSE,-10.0,10.0,DAQmx_Val_Volts,NULL);
DAQmxCfgSampClkTiming(samplHandle,"/Dev1/PFI0",2000000.0,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,10510);

DAQmxCreateTask("",&hFallHandle);
DAQmxCreateDIChan(hFallHandle,"Dev1/port0/line0","",DAQmx_Val_ChanPerLine);
DAQmxCfgChangeDetectionTiming(hFallHandle,"Dev1/port0/line0",NULL,DAQmx_Val_HWTimedSinglePoint,1);
DAQmxRegisterSignalEvent(hFallHandle,DAQmx_Val_ChangeDetectionEvent,0,myCallback,this);

DAQmxStartTask(hFallHandle);
}

void myCallback()
{
DAQmxStopTask(samplHandle);
... do my things;
DAQmxStartTask(samplHandle);
DAQmxReadAnalogF64(samplHandle,10510,10.0,DAQmx_Val_GroupByScanNumber,data,10510,&numRead,NULL);
}

I just wanted someone to confirm if I understand the principle behind this sheme correctly.

To get such fast sampling I used external TTL signals (don't know if I can call it a clock since it is not phase constant). My TTL signals pulse at around 1MHz. I set the sampling rate in CnfgSamplClockTiming to 2,000,000. The help says to set it at the maximum possible rate of the external clock.

Question #1: was it ok to choose such rate?

I also configured the task to acquire finite number of samples. In this case, I assume that if myCallback stops the sampling task, the task will be stopped even if it did not get all 10510 samples.

Question #2: will the task stop automatically after it obtained 10510 values (with DAQmx_Val_FiniteSamps setting)?

Question #3: if I start the task again, will it start from the beginning (will the new sample go into data[0])?

I know that myCallback will be called every 10510 cycles. Thus, I do not need to keep track of how many samples I get, as long as I can assure that a sample is taken on every rise of PFI0.

Question #4: Would it be more beneficial to use DAQmx_Val_ContSamps instead of DAQmx_Val_FiniteSamps? I do not see any difference at this moment. How does the system with DAQmx_Val_ContSamps setting uses my allocated data[] array? Will it write the sample at the 10511th rise into the data[0], or it will allocate some system buffer for sampling?

Question #5: Is there a way to avoid starting and stopping task each myCallback? They say it slows the performance.

Thank you in advance.

[John_P1]

1.  Specifying the rate in software for an external sample clock is just used for some minor details (e.g. buffer size for continuous tasks and convert clock rate if using multiple channels) so shouldn't be a big deal.  If your clock is actually up to 2 MHz this could be a problem as the ADC itself might run into overrun errors (single channel sample rate spec is only 1.25 MHz--from personal experience you should be able to go above this but perhaps not all the way to 2 MHz). 

2.  Yes.  You can verify with DAQmxIsTaskDone or DAQmxWaitUntilTaskDone.  Changing this answer...  the task will not be "stopped" in the sense that I think you are asking for.  You cannot start it again in order to restart the acquisition until you have explicitly stopped it first.

3.  Yes.

4.  If you want to obtain consecutive sets of data you should use continuous timing.  During the time it takes to restart the task in finite mode you might miss samples.  In continuous mode, DAQmx allocates a buffer (or you can specify whatever size you want using DAQmxCfgInputBuffer) from which data is read.  With default parameters, the read pointer is set to the first unread sample (so if you read 10510 samples every time, you'll get the first set of 10510 samples, followed by the next 10510 samples, etc.).  When necessary (but this is really only required in very specific circumstances), the read pointer can be manually set through DAQmxSetReadRelativeTo and DAQmxSetReadOffset.  The buffer is circular and the oldest samples will be overwritten once it fills up (trying to read samples that have been overwritten will result in an error).

5.  See #4.  However, if you are set on using Finite mode you will have to restart the task.  You can reduce the amount of time this takes by calling DAQmxTaskControl(samplHandle,DAQmx_Val_Task_Commit); before starting the task the first time.

I still am not sure what the need is for the change detection task.  Why not call DAQmxRegisterEveryNSamplesEvent on the analog task instead?  If you want to synchronize the start of your input to the new line signal you can configure a start trigger (though this would only synchronize at the beginning and relies on each line always generating the same number of pulses).

Best Regards,

[NazRB]

John,

Very informative and helpful. Thank you.

[NazRB]

Can not find what's the delay time when using external clock for sampling analog signal. Does anyone know? By delay I mean the time from the trigger rising edge to the start acquiring a sample. Also, the duration of sample acquisition.

[John_P1]

If you're looking for an exact specification check out Appendix B of the M Series User Manual.  The biggest delay is going to come from the configurable "Delay From Sample Clock" property which introduces a minimum of 2 timebase ticks between the sample clock and the generation of the convert clock (so using the 20 MHz timebase would result in 50-100 ns of delay on top of the various propagation delays).

I would be surprised if any of this matters for your application though--why do you ask?

Best Regards,

[NazRB]

How do I know if I am "using 20MHz time base"? Does it still matter if I am using external clock? My signal if interest lasts only about 300ns, so I need to make sure I sample within this interval.

[John_P1]

On M Series, the driver should default to the 20 MHz timebase for the convert clock when you have an external sample clock, but you can always verify using DAQmxGetAIConvTimebaseSrc.

However, given that the 50 ns of jitter might make a big difference since your signal is so short, you should consider using the external signal as your convert clock (DAQmxSetAIConvSrc).  You should be able to use the same signal for a sample clock and a convert clock on M Series (see here, though it's a LabVIEW example).

The settling time of the analog front-end might give you some problems--what kind of results are you getting?  Ideally you'd want to take the sample right at the end of the 300 ns pulse to give the signal as much time to settle as possible.  Hopefully you can adjust your clock signal relative to your analog signal, there might be some trial and error involved to determine what delay gives the best results.

Best Regards,