change detection on digital input

[Neil.Pate]

Hello DAQ experts,

I am trying something new, and am not having much success.

My goal is to be able to monitor two digital input lines for a change in state (for now a rising edge).

Attached is a VI which kind of works, but has one very odd problem.

The event fires every time there is a rising edge on either of the two input port pins, so I know that is working ok, but I dont know how to read back which port pin caused the event. In my example I try to do a read on the task, but (and this is the odd bit), it only returns data every fourth event, and then it returns four samples! How can I set it up so that as soon as the event happens I can read back which port line caused the event? I dont really understand how you can read back multiple samples without setting up a sampling rate etc (is there a default sampling rate on digital inputs?)

For the record I am using LV 8.5.1 with DAQmx 8.7.1f3 and a PCI 6221 DAQ device (but I dont think the problem is with my system configuration).

many thanks
nrp

[Neil.Pate]

well, after more struggling this weekend I am no closer to understanding this problem.

Can anybody explain the four samples at once issue to me?

[Neil.Pate]

update: I may have sorted it out.

If I change the sample mode to Hardware Timed Single Point, then everything seems to work as expected! Not really sure why, if this is a necessity of doing a change detection, it is not mandatory? (i.e. LV should give an error if the wrong sample mode is set).

It is probably my lack of understanding that is clouding this issue

At least now I have it working with my event structure so I do not have to resort to polling which is really what I wanted to stay away from in the first place.

[Kevin_Price]

Based on some other threads I've happened to skim, I *think* the reason you only could get samples in groups of 4 at a time has to do using DMA for data transfer.  It wants to transfer data in 32-bit chunks to optimize usage of the 32-bit data bus.  Your particular board only captures 8 bits at a time on the port that's capable of change detection.  So the data doesn't get transferred until you have 4 digital changes.  There's a chance that using interrupt mode may also work.  The possible advantage is that with interrupt mode, you can still hope to buffer *all* changes.  With hw-timed single point, it's harder to be sure.

The way I've figured out which bit changed to cause a sample to be taken is to hold onto the previous sample and compare for differences.  The main problem with this method is figuring out which bit changed to cause the very first sample. 

-Kevin P.

[Neil.Pate]

Thanks Kevin,

Great suggestion, changing the channel data transfer mechanism to interrupts then allows me to have continuous samples for the sample mode.

So now I have two ways of accomplishing what I want to do (either hardware timed single point [which used programmed I/O for its data transfer mechanism], or continuous samples [and using interrupts]).

As I dont really have a better understanding of the pros and cons of each method I think I am going to stick to using hardware timed single point.

Regarding solving which bit caused the transition, I think I am going to have to do it the say you suggest, by storing the previous sample.