Understanding DAQmxRegisterSignalEvent and Hardware Events generally

[iyerv]

I am just beginning to explore using a Change Detection scheme, and am quite confused by the DAQmx documenation. We are using the C API.

 The DAQmx Help has a section titled Events under the Timing & Triggering heading. Here the term 'Events' refers to items such as 'Counter Output', 'Change Detection', etc, and the text implies that the event will be signalled in hardware, not software. The following section is titled 'Exported Signal Behaviors', and suggests that the event can be signaled as a pulse, toggle, or level, and refers to an 'Output Behavior' attribute controlling this.

However, in the DAQmx C help, the only reference to the 'Counter Output'/'Change Detection', etc. events is in the DAQmxRegisterSignalEvent() function, whose arguments allow one to bind a callback function to the event. In other words, the event would be signalled in software, not hardware.

Meanwhile, there is no property termed 'Output Behavior' that I can find in a search of the DAQmx C help.

So, it seems that the DAQmx help and the DAQmx C help are saying opposite things...the former refers to these events as being in hardware, the latter in software. (Both documents agree that Done and EveryNSamples events are software events).

Which is it?! Or am I missing something?

I'm using DAQmx 8.8 at the moment. 

[Doug_L._Bear]

Both are right.

The change detection event mentioned in the first case would be something setup in hardware as either the sample clock or a trigger for another task.

http://digital.ni.com/public.nsf/allkb/EF1D8E3FF2639EB4862575910067D02C?OpenDocument

The change detection event in the C reference manual is how to inititate a software function (ie the callback) when the change is detected.  If you would like to use the hardware change detection to trigger another acquisition or to use a sample clock for another acquisition it will still be hardware timed and can be set in the timing and triggering functions.   For example the function DAQmxCfgChangeDetectionTiming.

[iyerv]

Thanks for reply. Sounds encouraging.

What we are seeking to do is collect a fixed number of samples on some DI lines, every time a change detection occurs on any one of those (very same) DI lines.

The link you sent suggests that we can use  DAQmxCfgChangeDetectionTiming to specify those lines, and then use DAQmxCfgDigEdgeStartTrig to take the terminal associated with the ChangeDetection event as its input. Indeed, the Terminal Names page in the DAQmx C documentation has some events listed as terminals, which I hadn't noticed before, although notably ChangeDetectionEvent is not on the list. Seems like a documenation error.

In our case, we don't want to use the ChangeDetection for timing after the trigger--we want to collect N samples following every change detection.

It's not clear this is directly possible, because can't simultaneously program a Task to have both SampClk and ChangeDetection Timing. I don't know if I could simultaneously program another DI Task that took the ChangeDetectionEvent from the first task as its trigger, and used SampClkTiming, and would be using the very same physical channels.

The link mentions setting up a task with 'unused physical channels'. Can I set up my Change Detection task with a Channel of say line 8, with Change Detection Timing with sources of 0:7. Then my 'real' Task would have a Channel of lines0:7, and would use SampClkTiming and DigEdgeTriggering with the ChangeDetectionEvent as the source ??

In other words, is it possible to use the very same lines for a Channel in one Task, and as the risingEdgeChan/fallingEdgeChan associated with ChangeDetectionTiming in another

Task?

Message Edited by iyerv on 08-06-2009 01:05 PM

[Doug_L._Bear]

Instead of using change detection I would setup a trigger to just watch for rising or falling edges on the counter line.  Set it up as a finite acquisition task with N samples and to be retriggerable.

[iyerv]

Hi there..

    Thanks for note. The idea you suggest would not handle the requirement of triggering when any of several digital input lines has a rising edge, as best as I can tell. This is where the Change Detection scheme is excellent, in that it perfects the OR gate operation we require. I'm just not sure the best way to then record from the very same digital input lines following this change detection event. One approach, rather ugly, is to wire same N lines to two sets of DI lines (i.e. total 2N lines), with one for change detection and one for digital input. This is obviously wasteful of digital input lines.

     Another approach is to use an external OR gate to create a single line trigger event for the DI lines.

     I'm just trying to cover bases here and verify that it's not somehow possible to achieve our application more gracefully, given the numerous features on the NI DAQ boards. 

Thanks 

--Vijay

[Doug_L._Bear]

Yea, so the problem that you've run into is that the same lines cannot be used for two different tasks at the same time, you should a receive a resources reserved error.  It seems as if your solutions would work the best, with the external OR gate using the least amount of DIO lines.