Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

usb-6501 digital input sample rate/timing (cant catch a signal, DAQ too slow)

I have a USB-6501 that I am trying to use to capture and record a series of digital signals to see if one goes missing under load.  The signal that I am interested in persists for about 500microseconds and happens every half second.  I am trying to use the LV example code for digital input on this device, but it is not catching the signal reliably.  I want to increase the sample rate, but when i add the DAQmx timing vi and try to set a rate for the sample clock, i get error -200077 at DAQmx Timing: 

 

Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property.

Property: SampTimingType
Requested Value: Sample Clock
Possible Values: On Demand

 

I have read some other articles that explain that the timing module is not necessary for 'on demand' tasks.  So then how can i increase the speed of the digital input sampling?  I have also tried to configure the timing VI for edge trigger, but i get the same error.  Is there any way for me to speed up the sampling rate of the digital input?  I feel like im just missing something simple here... any help would be greatly appreciated.

0 Kudos
Message 1 of 4
(2,818 Views)

As the error message states, your device doesn't support acquisition timing based on a hw sample clock.  It *can* support "on demand" timing, a.k.a. software timing.  To implement, simply remove any call to DAQmx Timing.vi from your task config chain. 

 

However, the combination of Windows and the use of a USB-connected device will further limit both your best-case and typical polling speed.  I'm doubtful you can poll fast enough and reliably enough to count on catching a 500 usec pulse with your (or *any*) USB device.

 

Reacting to a single signal via a counter task can sometimes be a better alternative to a polling-based digital task.  Your 6501 has very limited counter support that can only count falling edges.  Any chance that can be useful?

 

Do you have any other data acq devices available to use?

 

 

-Kevin P

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 2 of 4
(2,748 Views)

It is starting to look more and more like i have just selected the wrong DAQ device.  I do not have any others handy, but am looking at possibly moving to the USB-6001.  It advertises 20Ks/s, non simultaneous.  I have 4 channels to look at, so the 5Ks/s should be enough.  I think that by moving to the analog device that supports the timing VI and sample clock input, i can implement my own level trigger to mimic a digital signal and call it macaroni. Your comment about being doubtful about catching this 500usec pulse on a USB device does have me a bit worried, but this project doesnt have the budget to go with anything much better than the USB-6001.  If i can't get that to work in my current program, i'll have to mess about with the counter.  Thanks for the reply, Kevin.

0 Kudos
Message 3 of 4
(2,743 Views)

I think you'll be able to make things work.  Standard Nyquist theory would say you need to sample at >= 4 kHz per channel to catch all the transitions of a signal that pulses at 2 kHz.  But it sounds to me like you have a special case where you only need to know that you won't *miss* an occasional single pulse with a pulsewidth of 500 usec.  You can assure *that* more limited goal by sampling at anything > 2 kHz .   Take that, Nyquist!

 

In any event, you already know your device is capable of 5 kHz/channel for the 4 channels of interest, so you're more than covered.

 

The earlier concern about catching the pulse over USB was based on the need to do software polling of a digital line.  *That* probably wouldn't work.  But a buffered hw-clocked AI task should handle things just fine.  Just be aware that there will be some latency between the instant when the pulse happens and when you retrieve and recognize the event in the buffer of data.  You still won't have *awareness* of the pulse in sub-millisec time.  If need be, you can probably get latency between pulse and awareness to be typically down under 10 millisec.  But under Windows and over USB, you won't be able to guarantee it.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 4
(2,729 Views)