SampleCompleteEvent Callback not reached

[Devor]

Thanks in advance. Any idea why SignalCallback is never called below? Here is the setup:

// DAQmx Configure Code

/*********************************************/

DAQmxErrChk (DAQmxCreateTask ("", &taskHandle));

DAQmxErrChk (DAQmxCreateAIVoltageChan(taskHandle,"Dev1/ai0:1","",DAQmx_Val_Cfg_Default,-10.0,10.0,DAQmx_Val_Volts,NULL));

DAQmxErrChk (DAQmxCfgSampClkTiming (taskHandle, "", 10000.0, DAQmx_Val_Rising, DAQmx_Val_HWTimedSinglePoint, 1));

//************************  SignalCallback is setup here - but not reached after task start  *************************

//************************* As if DAQmx_Val_SampleCompleteEvent never happens? Am I missing something?

DAQmxErrChk (DAQmxRegisterSignalEvent (taskHandle, DAQmx_Val_SampleCompleteEvent, 0, SignalCallback, NULL));

// DAQmx Start Code

/*********************************************/

DAQmxErrChk (DAQmxStartTask(taskHandle));

[Austin_S]

Devor,

Depending on which compiler you're using (LabWindows/ CVI, Visual Studio, for example), there are certain function calls that you may have to implement in your code to allow your application to handle the event.  Take a look at this KnowledgeBase article and see if it helps.  The steps and functions to add are listed and described so that your application is set up to handle the event being called.

[Devor]

Thank you but the article you mentioned has very little info - it just says that I need to create an event queue and work out all the mechanics of executing calls associated with Ni-DAQ events like sample complete?  Did NI create any sample code to work in Windows lets say with a regular old compiler (i.e. Visual C++ 2008). It's ok if they didn't I just want to understand what I got.  I am looking at the NI-DAQ ANSI C code samples that came with my system and almost all have some sort of "Event" driven structure. Does that mean I can't use any of them without implementing a Windows specific Event queue/processing wrapper?

Here is a good example: ftp://ftp.ni.com/pub/devzone/epd/cont_acq-intclk_hw_timed.c . What compiler/environment does this need to be built to work? CVI? LabWindows? It does compile just fine with Visual C++, returns no errors and quitely goes through the end until I quit. It just doesn't call the routines that are associated with events (other than the DAQmxRegisterDoneEvent which does call the DoneRoutine just fine).

[Austin_S]

What happens if you try this line of code using DAQmxRegisterEveryNSamplesEvent instead of DAQmxRegisterSignalEvent?  You'll have to change your number of samples read to 1 (your "N" value), but it'd be interesting to see if this function works for you.

DAQmxErrChk (DAQmxRegisterEveryNSamplesEvent(taskHandle,DAQmx_Val_Acquired_Into_Buffer,NUM_SAMPLES,0,EveryNCallback,NULL));

[Devor]

Already tried that - None of the routines associated with "Events" other than the DAQmxRegisterDoneEvent routine can be reached.  NI-DAQ's event based examples I tried compile and run to the end just fine, but with wrong functionality - not calling any of the functions. Very subtle disfunctionality that I discovered maybe due to fact that I am using Visual C++ and not CVI. I would expect NI would have some kind of a flag to warn users their event driven routines are non-functional outside of CVI.  It seems like NI-DAQmx is unpractical for tasks beyond the simple straight shot sampling and outputing predetermined analog data streams. Big divergence from what I remember NI-DAQ in the old days, it seems like it was friendlier to non-CVI developers. If anyone has an example to make event driven routines work outside of CVI using standard windows compiler - that would be a life saver. 

[Brad_K]

Hi Devor,

DAQmx_Val_SynchronousEventCallbacks is intended to simplify synchronization for event-driven GUI applications. You only need to use it if you want the event callbacks to get executed from the UI thread. Otherwise, specify 0 for the options parameter.

The examples that get installed in "C:\Users\Public\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C" work with Visual C++, and they include project files for multiple versions of Visual C++. The event callback function signatures use CVICALLBACK, but that is #defined in NIDAQmx.h and does not require CVI headers. The example you linked should be able to build with a similar project file. If it compiled and linked without errors or warnings, then I doubt that the compiler is the issue.

What device and NI-DAQmx version are you are using?

Also, note that while the DAQmx_Val_HWTimedSinglePoint mode is supported on Windows, its performance is very limited compared to LabVIEW Real-Time (or to buffered acquisitions on Windows), because it turns off buffering in order to reduce latency. What sort of latency requirement does your application have? If latency isn't an issue, you are much more likely to be successful using a buffered acquisition (i.e. DAQmx_Val_FiniteSamps or DAQmx_Val_ContSamps).

Brad

[Devor]

Brad,

Our target functionality is [1- read in one sample (ai0), 2-process sample, 3-output result (ao0)] and repeat the 3 steps fast as you can in fixed time intervals.

1- Timing and syncrhonization is necessary. Event callbacks work like quasi interrupts in this case that is our best chance of real-time like behaviour.

2- NI support (more than person) has suggested the difference between VIsual C++ compiled version and CVI compiled version is the likely the reason behind loss of functionality in event driven calls. Event managent is taken care of in CVI where as in Visual C++ the code needs the additional windows event queue handler. Almost all examples in the NI-DAQmx have some sort of event driven call.

3- If you consider the target functionality, you will see that "Latency" is one of the  the reasons we need DAQmx_Val_HWTimedSinglePoint. This conclusion is a result of a good deal of testing with buffered acquisition. While the latency was improved drastically with the new version of Ni-DAQmx (9.3), it is still present. If there is an alternative here I would love to hear more about it.  Thanks. 

-

[Brad_K]

Hi Devor,

Thank you for describing what you are trying to do. PID Control-Single Channel looks like it's closer to what you need. It's written in LabVIEW, but the function calls should translate directly to the C API. Note the use of DAQmxWaitForNextSampleClock() to synchronize the control loop with the sample clock; I would expect this to have lower latency and jitter than the sample complete event (as implemented on Windows).

As for Visual C++ vs. CVI, programs compiled using both compilers end up calling into the same DAQmx API code in nicaiu.dll. The main difference is that the CVI version of NIDAQmx.lib implements user protection (i.e. bounds checking) before/after calling into nicaiu.dll, but the Visual C++ ("msvc") version of NIDAQmx.lib is an ordinary Visual C++ import library that links directly to nicaiu.dll. With either compiler, you can specify options=0 to execute event callbacks asynchronously in a separate thread, or you can specify options=DAQmx_Val_SynchronousEventCallbacks to execute event callbacks in the UI thread. If your application doesn't have a UI thread, you should use options=0, like all of the ANSI C examples that ship with DAQmx.

What device are you using? Some of the lower-level code that dispatches events is device-specific, so it's possible for a bug to affect some devices and not others. Also, no one can reproduce your setup without knowing what your setup is.

Brad

[Devor]

Thanks Brad,

Our hardware is PCIe-6353. I have tried all of the suggestions, including DAQmx_Val_SynchronousEventCallbacks option and 0 and it was no-go. The DAQmx_Val_HWTimedSinglePoint sampling option has proven very challenging to work with, perhaps indeed there is an issue with our hardware model in which case it would would be great to know.

On the latency of DAQmxWaitForNextSampleClock() :  isn't the primary factor the type of "read" rather than the synchoronization form?  It looks like the PID example is using HWTimedSinglePoint.

On the PID vi; GIven the difficulties we have had working through the vagueries of the current NI-DAQmx knowledge to adapt  straightforward Ni-DAQmx C examples into a workable solution (consider the number of forum threads) I'd worry about going down the route of vi to C conversion.

.

[Brad_K]

Hi Devor,

I built the example you referred to using Visual Studio 2010* and tried it with a PCIe-6353, and I can confirm the sample complete event problem is an X Series bug. The sample complete event executes in HW timed single point mode on M Series (PCI-6251) but not X Series. This only seems to affect HW timed single point mode: the sample complete event executes correctly when using DAQmx_Val_ContSamps on X Series. I filed a corrective action request (CAR #297667) so we will fix this in a future release of NI-DAQmx.

Re: DAQmxWaitForNextSampleClock() latency: DAQmxWaitForNextSampleClock() and the sample complete event both have some overhead. I think that the overhead of the sample complete event is higher and more variable, but I don't have any numbers to back this up. Anyway, whatever difference there is between these two approaches on Windows is insignificant compared to the difference between Windows and LabVIEW Real-Time, because Windows is not a real-time OS. You will not be able to sustain very high loop rates on Windows. The PID example I mentioned errors out immediately at 10000 S/s on Windows with a Core 2 Duo E6300 CPU and a PCIe-6353. It runs without errors at 1000 S/s, but I only ran it for a couple of minutes, and it errored out when I switched to another application and dragged some windows around. Again, Windows is not a real-time OS.

* Using the command line "cl cont_acq-intclk_hw_timed.c /O2 /I "C:\Program Files (x86)\National Instruments\Shared\ExternalCompilerSupport\C\include" /EHsc /link /LIBPATH:"C:\Program Files (x86)\National Instruments\Shared\ExternalCompilerSupport\C\lib32\msvc" nidaqmx.lib"

Brad