06-13-2016 06:52 PM
My configuration:
Hardware : NI-DAQ 6351X
Software : NI-DAQmx 15.1
I am reading analog input using a 1 Khz external sample clock using the callback approach, which works fine.
Timing is configured like this:
const int kBufferSize = 2000; samplePerSecondPerChannel = 1000.0f; int32 activeEdge = DAQmx_Val_Rising; int32 sampleMode = DAQmx_Val_ContSamps; uInt64 sampsPerChanToAcquire = kBufferSize; DAQmxErrChk(DAQmxCfgSampClkTiming(mTaskHandle, srcClock, samplePerSecondPerChannel, activeEdge, sampleMode, sampsPerChanToAcquire));
Registering for data callback like this:
uInt32 nSamples = 50; DAQmxErrChk(DAQmxRegisterEveryNSamplesEvent( mTaskHandle, DAQmx_Val_Acquired_Into_Buffer, nSamples, 0, EveryNCallback, (void*)this ));
In the EveryNCallback, I read values like this:
float64 timeout = 2.0; bool32 fillMode = DAQmx_Val_GroupByScanNumber; // Group by scan number (interleaved) uInt32 arraySizeInSamps = kBufferSize; // The size of the array, in samples, into which samples are read. float64 buffer[kBufferSize]; // The array to read samples into, organized according to fillMode. int32 SampsPerChanRead; // The actual number of samples read from each channel. float tmpBuf[kBufferSize]; // The array to read samples into, organized according to fillMode. error = DAQmxReadAnalogF64(taskHandle, nSamplesPerChannel, timeout, fillMode, buffer, arraySizeInSamps, &SampsPerChanRead, NULL);
Again, this all works fine.
My issue occurs when restarting the Task. The following sequence:
Remove external clock signal
Stop Task
Start Task
Resume external clock signal
Results in a long delay (~5-10 secs) before data begins being delivered. It's almost as if it's working thru stale samples in the buffer from the previous external clock's pulse train sequence,
My question is: Should this sequence of events work? Do I need to clear out a possibly incomplete buffer?
thx!
Morgan
06-14-2016 01:16 PM
Morgan,
Nothing jumps out at me as incorrect but I do have a few questions for you that might help with troubleshooting.
1. Are you able to verify that the clock signal is indeed starting when you believe it to be? Perhaps with an occiliscope.
2. If you do just the last two steps (Start the task and then connect the clock) when you first start your program does it exhibit similar behavior or is it only when the task is stopped and restarted?
DAQmx uses a state model and sometimes it can take a little while to reserve the resource and start the task but 5-10 seconds seems excessive. Checking if this only occurs during restarts or also during initial startup may provide some insight into the cause. Generally if the state transition time is the cause then I would recommend explicitely commiting the task before starting it to reduce the time required to restart.
Some help for explicitely calling state transition
http://zone.ni.com/reference/en-XX/help/370473H-01/mstudiowebhelp/html/verifycommitstartstopdaqtask/
06-15-2016 02:30 PM
Thanks for the suggestions,
RE 1 Yes external clock signal is verified independently.
RE 2 Yes - Initial Start Task, then resume clock works correctly. Suspending and resuming the clock after inital start task also works correctly. It is only after
Stop Task
Start Task
Resume clock
That the issue seems to occur. The Stop Task appears to be a required condition.
I'll look at managing the state transitions directly and seeing if that can help me resolve.
Thanks!
Morgan
06-16-2016 05:09 PM
Please let me know if that works. I'm interested to know what you find.