Problem with unknown initial pre-change DI state in Change Detection tasks

[Kevin_Price]

When a DI change detection task runs, the first sample shows the DI state *after* the first detected change.  There's not a clear way to know what the DI state was just *before* the first detected change, i.e. it's *initial* state.

This idea has some overlap with one found here, but this one isn't restricted to usage via DAQmx Events and an Event Structure.  Forum discussions that prompted this suggestion can be seen here and here.

The proposal is to provide an addition to the API such that an app programmer can determine both initial state just before the first detected change and final state resulting from each detected change.  The present API provides only the latter.

Full state knowledge before and after each change can be used to identify the changed lines.  (Similarly, initial state and change knowledge could be used to identify post-change states.)

My preferred approach in the linked discussions is to expose the initial state through a queryable property node.  The original poster preferred to have a distinct task type in which initial state would be the first returned sample.  A couple good workarounds were proposed in those threads by a contributor from NI, but I continue to think direct API support would be appropriate.

-Kevin P

[Laciba]

Based on your advice I've posted this My idea to the "Data Acquisition Idea Exchange" (exactly here) in May but then (May 29) the post has been moved to the Multifunction DAQ forum (this forum) by Kristi Martinez NI webmaster......

I suggest to developers the following consideration:

Introducing a new "DAQmx Timing VI" instance: "ChangeDetection with Fetch Initial State"

In this case there is no need second task - which only works if first channel have "tristate = false" and second channel have "disabled filter" DAQchannel only! - would be required and after calling "DAQmx Start Task VI" the first data returned by first "DAQmx Read VI" would be the initial state automatcly!

[Laciba]

Repair:

"first channel have "tristate = false" and second channel have "disabled filter"

repair to

"second channel have "DI.Tristate = False" and "DI.Dig.Fltr.Enable = False"....