How can i read DI states if task timing is Change Detection and no change states of lines?

[Laciba]

How can i read the di port lines after Start Task without closing and re-opening the task if Task Timing is Change Detection and no change states of lines? For example it is necessary to get the initial state of lines without loss of any state!!!

See attached example! -> When I push the "Read DI Lines" button i would like to be able to READ DI LINES EVEN IF NO CHANGE ON DI LINES!

There could be one option: The possibility of an event generating programmatically that is equivalent to a Change Detection Event. That would be the most correct solution.

This should be a basic opportunity...

[Kevin_Price]

I don't know of a direct solution for this problem.  All I've found to do was to first set up an unclocked DI task to take a sneak peak at the initial state, then stop and reconfigure the task for change detection.

This can work fine if you have control or knowledge that the state won't change between your sneak peak and the time it takes to reconfigure the task for change detection.  Without that guarantee, I don't know of a clean solution.

Maybe you should post this idea to the Data Acquisition Idea Exchange?  It might be possible to add a DAQmx property that would allow you to retrieve the initial state just prior to the first change.

Anyone out there have a better method?   If so, please educate us...

-Kevin P

[Laciba]

It would be the best:

To add a new Reg Events.signalType property value: example "Change Detection with Initial State" that would allow you to retrieve the initial state immediately after "Start Task" but prior to the first change:

If signalType property == "Change Detection with Initial State" -> we get an event immediately and automaticly after "Start Task" and can be read initial state of lines using "DAQmx Read.vi". The following events only come when the lines change.
If  signalType property == "Change Detection" (for backward compatibilty) -> we get events only when the lines change... just like now.

[Kevin_Price · Accepted solution]

One way or another, it'd be good to be able to know the initial state.

I tend to prefer something like the property node solution so it's available to the programmer that needs it but doesn't get in the way for the programmer that doesn't.  I tend to do stuff where tasks get sync'ed to one another with a common sampling clock signal, and if the DI task got an extra sample or extra event, it'd tend to throw things off.  It's easy enough to code around that, but the code needed to *prevent* throwing things off is no simpler than the code needed to know when to query the property node I proposed.

-Kevin P