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 and give us initial/actual line states anytime. 

Another possible solution (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]

I already commented in a similar thread on a much lower-usage forum.  I would like a better solution too.  I agree that the inability to query for initial state in a DI change detection task is problematic, but I differ somewhat from the OP on the preferred implementation.

Though this is close to being a duplicate post, more eyes will see it here on this forum so I'd request any moderator to let this thread stay here.

-Kevin P

[bstreiff]

You can use a second DI task, with DI.Tristate=FALSE, to read the current state of the lines in an active Change Detection task. This was a quick test I did with a NI 9401 in a CompactDAQ chassis, with another NI 9401 (on which I was just toggling lines from MAX Test Panels) as a stimulus:

[Kevin_Price]

The option for a 2nd, software-timed on-demand DI task is good info and a big improvement over my advice in the other thread (do the same kind of on-demand "sneak peak", then stop and reconfigure the *same* task for change detection).

However, it still doesn't fully solve the problem.

I expect it's fairly common in change detection tasks that it's important to be able to figure out exactly which bits changed on a given sample.   This is simple enough for every sample *except* the very first one due to the lack of "initial state" info.

Using the method you posted can do a pretty good job in many cases.  It'll work if the software polling loop that queries state is faster than the first change caught by the change detection task.  But there will be some cases where the changes are too fast for the software polling to keep up reliably.   Especially in a case where the change detection task is triggered to sync to some specific bit or other signal, it's important to have a hardware-accurate knowledge of initial state.

So, first, thanks, that's a very helpful and large step of progress.   But I still think there's real value in a full hardware-accurate solution.  (I recognize now that this could be a board design limitation rather than a DAQmx driver limitation.)

-Kevin P

[bstreiff]

---

@Kevin_Price So, first, thanks, that's a very helpful and large step of progress.   But I still think there's real value in a full hardware-accurate solution.  (I recognize now that this could be a board design limitation rather than a DAQmx driver limitation.) 

Yes, there's a hardware limitation here; the change detection circuitry only latches the state of the DI and PFI lines on change, and there's no way for us to make a "phony change" to force the circuit to fill those registers without an actual associated change.

If you need to have the initial state come in on the Change Detection task's data path, and you can spare a digital line to be used as an output, you could add that to the set of lines to monitor for change detection, then strobe that in software to induce a change:

This approach is probably easier on an M or X Series (with the port1/port2 DI banks that are dual-mapped with PFIs) than it is with cDAQ (where I had to add another NI 9401 to get an extra digital line).

It's certainly possible that this strobe could take place internal to the driver (maybe even using PFI resources that may not necessarily be exposed as digital lines, e.g. on cDAQ) if there were a theoretical "ChangeDetect.DI.FetchInitialSample" property set-- that certainly seems worth an Idea Exchange pitch.

[Laciba]

Hi @Kevin and @Brendon!

Thanks for the help!

I've tried Brendon's solution (second DI task, with DI.Tristate = FALSE)! It works!

And I agree with the proposal of Brendon:

"It's certainly possible that this strobe could take place internal to the driver (maybe even using PFI resources that may not necessarily be exposed as digital lines, e.g. on cDAQ) if there were a theoretical "ChangeDetect.DI.FetchInitialSample" property set-- that certainly seems worth an Idea Exchange pitch."

It would be nice if this solution could work for NI 651x-like boards too...

[Kevin_Price]

Brief followup to expand on bstreiff's latest example.

The earlier software-polling based approach can work pretty well in a lot of situations, especially if digital changes will be infrequent prior to task start.

A situation where digital changes are happening frequently and regularly prior to task start usually makes the idea of "initial state" a bit dubious, I think.  Because the software to start the task has no timing sync to this rapidly changing digital pattern, you're kinda jumping into the datastream at a fairly random point.  You've already accepted that fact, so the ability to know the state prior to the first change seems less relevant.

Hence my earlier brief reference to triggered tasks.  *That* seems like a case when this initial state knowledge is more likely to be important.  And the latest method posted by bstreiff can be used very effectively if the trigger is its own distinct (and brief) pulse signal rather than one of the bits already being monitored.   It would require an available bit on a port that supports change detection.  The trigger signal would be parallel wired to both this spare bit *and* to a PFI pin to be used as a start trigger.  The task would be triggered off the *leading* edge of the trigger pulse while the DI task would be sensitive only to the *trailing* edge. 

The leading trigger edge marks the point in time that the app "starts to care" about the data, and immediately thereafter the trailing edge produces a DI change detect sample.  This will establish initial state for all the other bits before any of them change to cause "normal" sampling to begin.

Small caveats: there's still a chance another bit will change between the leading and trailing edges of the trigger pulse.  The shorter the pulse, the less likely that will be.  On M- and X-series boards, one could game the system by letting the original too-wide trigger signal trigger a single pulse with minimal width which gets wired as the DI task trigger and extra bit.

-Kevin P

[Laciba]

Hi @Kevin and @Brendon!

I've tried Brendon's solution (second DI task, with DI.Tristate = FALSE) on NI PCI 6514 card. I used "Event Structure".

If I push the "Read DI Lines" button - before the first change or after any change or without any change on lines - i get an "Read DI Lines: Value Change" event and i can read actual state of DI.

If change any lines I get a Change Detection event and I can also read (changed) DI state too.
This means that only the software depends on success! That's why I think there is no need to use PFI, or a bit on a port that supports change detection.

Introducing a new "ChangeDetect.DI.FetchInitialSample" property requires only DAQmx software modification.

See attached picture!

In this case no second task would be required and after calling "DAQmx Start Task VI" the first data returned by first "DAQmx Read VI" would be the initial state!

[Kevin_Price · Accepted solution]

I posted to the Data Acquisition Idea Exchange about this.

-Kevin P