daq pad counting

[Jockeyjim]

I am currently experiencing poor performace with my Daq Pad 6020E when counting over 333Hz.

The counter doesn't appear to loose a count from the source signal but it does have a problem in telling me when an event has occured within an acceptable period of time.

I am using the GPCTR_Watch() function to read in the count value but according to my system clock it takes at least 30 mSecs to execute and return the count value. This is a big problem for me because I need to know much quicker than this and i was expecting a usb connection to be able to send this data much faster.

Is there an alternative method using my current hardware or can anybody suggest a more suitable Daq device???

Please Help!

[SachaE]

Hi,

 what version of LabVIEW are you using (I'm assuming LabVIEW since you've posted on the LabVIEW forum even though you've said you're using a traditional daq function call that looks pretty 'C' styled), and what version of the data acquisition driver?

I'm assuming you're going directly to the DLL since you said GPCTR_Watch(devNumber,gpctrNum,entityID). Can you please post your code back here?
Which entityID are you looking for - I'm assuming the COUNT?

Depending on the code set up / architecture you're using, there may be another way of handling this (using a timed loop with the clock coming from a particular source can't be done since that would involve DAQmx)

Is it software timed retrieval of the count, and since it's taking 30mS that limits the rate you can poll it at? You could set up for buffered event counting instead, providing a clock signal, of whatever rate you need, to the gate input (this could come from another counter set for continuous pulse generation) and then do  a GPCTR Read Buffer instead, so you'd pull back a series of values rather than just one.

Unfortunately, the DAQPad 6020E isn't supported by DAQmx as this driver set usually runs a little faster.
http://www.ni.com/support/daq/versions_portable.htm#du

What was your reason for choosing to go with USB connectivity? (If you're on a laptop for instance, then that would limit the choice of other bus technologies) This may not be an issue with the USB per se, but related to what else is going on with the laptop and your code at the same time.

Thanks

Sacha Emery
National Instruments (UK)

Message Edited by SachaE on 08-30-2006 10:28 AM