Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

USB-6525 - Change Detection

Solved!
Go to solution

I have two questions regarding the Change Detection facility of the NI USB-6525 product:

 

1) Assuming a pulse of suitable length occurs (say 100ms), can the signal change be guaranteed to be detected and handed over to the CPU even if the processor is under heavy load? My concern here is not when CPU is alerted to the change, but just that it does eventually happen. i.e. I don't want to miss performing an action when a pulse occurs.

 

2) According to what I'm reading in the user guide, the change detection interrupt that fires on the PC will not say which channel is changed nor will it say what the states of the channels are. I'm assuming then that the interrupt handler must then perform a follow-up read of all channels to see exactly what has changed. My question here is, does this follow-up read command read the channel states at the time it is executed or does it read cached values of the channels from the time the interrupt occurred? In other words, if you are using change detection to wait for a small pulse on multiple channels, can this follow-up read command be relied upon to see this pulse or will the pulse have passed by the time the follow-up read command is executed and therefore not be able to tell which channel was pulsed.

 

0 Kudos
Message 1 of 6
(4,612 Views)

Hi Nichoals,

You’re right a change detection event on you device will generate an interrupt. These interrupts should be handled and/or queued by the CPU.  100 ms is a relatively long time for interrupts and processes to be handled by the CPU.

With change detection events you can do a lot of things, one of which is the “Follow up read” that you mention from the manual so that you can tell which line changed. This does not reference a cached value and you have the potential to lose that information if your change event is sufficiently short. This would be system dependent however.

Matt
Applications Engineer
National Instruments
0 Kudos
Message 2 of 6
(4,593 Views)
Thanks for your answer. I'm clear on your response to my second question, but I just wanted to further clarify that first point if possible. It is important for me not to miss a rising edge of a channel. This channel is occasionally pulsed with a pulse width somewhere between 50-100ms.  If I monitored this channel using the Change Detection facility, are you saying that because Change Detection is interrupt based and queued by the system, I should never miss that a pulse occurred? Sorry, just need to be clear.
0 Kudos
Message 3 of 6
(4,591 Views)
Solution
Accepted by NichoalsH

Hi Nichoals,

Sorry if I wasn’t clear enough. You should not miss a change detection event. A 50 ms pulse is more than long enough to generate the change detection event and cause an interrupt to be issued. If the process is under extremely heavy load the interrupt may be queued and handled when the process has more availability, similar to your computer freezing for a moment while you are typing and then it “catching up” and displaying all the previously typed characters. I hope that’s clearer let me know if not.

Matt
Applications Engineer
National Instruments
0 Kudos
Message 4 of 6
(4,582 Views)

Mr.F 已写:

Hi Nichoals,

You’re right a change detection event on you device will generate an interrupt. These interrupts should be handled and/or queued by the CPU.  100 ms is a relatively long time for interrupts and processes to be handled by the CPU.

With change detection events you can do a lot of things, one of which is the “Follow up read” that you mention from the manual so that you can tell which line changed. This does not reference a cached value and you have the potential to lose that information if your change event is sufficiently short. This would be system dependent however.


Hello, from the NI tutorial , the device does latch the data:

Once a change occurs, data is latched in the hardware buffer, and then the pattern is transferred via Direct Memory Access (DMA) or Interrupt to the PC memory.

I'm not a expert about this. Could you confirm your statement?

0 Kudos
Message 5 of 6
(3,055 Views)

The DI task that's set up for a change-detection based clock will buffer up a sample of its digital lines every time one of the configured edges occurs.

 

You should probably plan to read 'all available samples' from the task to be sure you're acting on the most up-to-date state of the port.   It's conceivable that, say, 3 changes happen in quick succession before you can read data from the task buffer.  If you only read 1 sample, it'll be the oldest change and you won't yet know anything about the subsequent 2.  I ran into this kind of thing because the UUT had digital responses that were independent and not sync'ed to do their changes simultaneously.  They would very often change almost-but-not-quite simultaneously due to a change in stimulus.  I'd get a burst of several samples that were in the order of a microsec apart and needed to be sure to read *all* of them to know my current state.

 

 

-Kevin P

 

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 6
(3,049 Views)