Change detection on USB-6001?

[jsiegel]

I want to use a USB-6001 (not yet in my possession) to detect when a digital signal changes state. It's okay if I miss some state changes, but at any time I check (it doesn't necessarily have to be event-driven), I need to know if a state transition has occurred since the last time I checked (and I also need to know the state at the time). My use case is a proximity sensor--I need to know if at any time a device has moved out of range (even if it has moved back into range by the time I check it) so I can abort a process.

Software polling of the digital line state could potentially miss transitions. It seems like using DAQmx's change detection is the ideal solution, but the USB-6001 does not support this. I considered using a counter--each time I check the counter I can tell if a state transition has occurred by checking to see if the count has changed. But as far as I can tell, it can't tell me the current state. Furthermore, the DAQmx example "Counter - Count Edges.vi", does not list the USB-6001 as a supported device--is this really true? The example gives no errors when I run with a simulated device, and I can't think of a simpler counter application that the USB-6001 could support.

Another possible solution would be to use the DI signal as the clock source for a timed event structure. I'm not exactly sure how to do this, but I'm pretty sure the USB-6001 does not support this. Also, I think it may not be possible to determine the DI (Clock) state.

Does anyone have any suggestions for how to do what I want to do with a USB-6001? If it's not possible with a USB-6001, what would the best available (USB) device that could do it?  It's hard for me to figure out exactly what capabilities a board supports.

[MrJacket]

Hey,

You should not have any issues with the example code. Looking at the specifications sheet, you should be able to do most of the examples in LabVIEW with that device. 

In regards to the DI signal as a clock, that might work, but sounds a little complicated with the USB 6001. I would go through the counter method that you suggested to make the process easier.

Regards

-Brian J.

[jsiegel]

Brian, thanks for your response. To be clear, you are saying I shouldn't have a problem with the "Counter - Count Edges.vi", and you are not saying I should not have problems with other examples (such as the "Digital - Change Detection.vi"), correct? It's hard for me to map specification sheets to DAQmx capabilities. Is there a document that maps boards to capabilities? I thought I had seen such a document before, but I can't find it now. (Maybe there are too many boards and too many capabilities to make this practical.)

So if I use a counter to count the number of change events on a line, can I also determine the state of the line at the same time as the counter read? It doesn't seem possible. One possible solution is to connect the signal to both a PFI line (counter input) and also to a DI line (on a different port) and also read the DI in a separate task. The two pieces of information won't be synchronized (and will use twice as many resources), but it might be good enough for what I need to do.

Jeff

[Kevin_Price · Accepted solution]

With the counter task, you'll only be counting edges of 1 polarity.   You can count how many times you've entered the "out of range" area or how many times you've left.  You won't get separate counts of each.

You won't use a lot of resources by pairing up your counter task with a DI task to query instantaneous state.  You're correct that these tasks won't be synced.  Given your general description, "sync" sounds less important to me than latency of the DI read.

Again, the counter task will track how many times you've gone "out of range."  This count will keep incrementing, so no matter when you query it, you'll get info about the past history.  The DI task only checks instantaneous state.  The *latency* of this query determines how long in the past the DI state was measured.  (It will be in the order of msec over USB).    Together you know if something undesirable happened when you weren't querying *and* you know what the state just was a small fraction of a second ago.

(Note: you kinda already know the "state" of the sensor as an edge increments a count.  If you count rising edges, the state will be transitioning to high as the count increments.  What you don't know is *when* that transition happened.)

-Kevin P

[jsiegel]

I think a counter to determine any past events and a separate DI to determine the current state is the best way to go for me.  Thanks for your help.

Jeff