04-05-2011 03:38 PM
04-06-2011 04:15 PM - edited 04-06-2011 04:16 PM
Hi Lars,
The same binary data is transferred over the PCI bus. If you're reading back the data as DBL the driver has to scale it to the appropriate units in software, so this would technically take a little longer I suppose (although I'm not sure it would be noticeable). Are you running into any specific issues?
Best Regards,
04-07-2011 03:49 AM
04-07-2011 11:28 AM - edited 04-07-2011 11:29 AM
Hi Lars,
Which hardware are you using and on what subsystem? I'm assuming analog input. What is the end goal of your application?
Best Regards,
04-08-2011 08:18 AM
04-08-2011 01:28 PM - edited 04-08-2011 01:29 PM
Hi Lars,
As of DAQmx 9.1 and later (currently on 9.3), the following functions (in the C API) can be used to read back counter data.
The functions that include "Freq", "Ticks", and "Time" are used only with pulse measurements on STC-3 based devices (like X Series) and aren't supported on the 6602. The functions that include "Scalar" are for one sample, whereas the functions that do not can return a user-defined number of samples.
So, that pretty much just leaves U32 and DBL. In your case, for a pulse width measurement (not to be confused with "pulse" measurements mentioned above), DBL will return the scaled data (in seconds by default), whereas U32 will return the number of timebase ticks that were recorded during the input pulse. Unless you specify a maximum pulse width of higher than about 53.69 seconds, the driver will choose the 80 MHz timebase so each tick would correspond to 12.5 ns. Other internal timebases which are available on the 6602 include 20 MHz and 100 kHz. If you'd like you can specify which timebase to use directly with a DAQmx channel property. If you don't specify, the driver will choose the fastest timebase that would not cause the counter to overflow given your maximum pulse width setting when you create the channel.
The data transfers across the bus are always 32-bit (this is the size of the count register). In the DBL case, the driver will scale the returned value to seconds by multiplying the raw value in ticks by the period of your timebase, where as in the U32 case it will just return the value of the count register in ticks.
I'm not sure what you mean by reading in your own threads instead of the DAQ task--to use the DAQmx Read functions you need to pass in a task handle. Also, I'm not sure how you're synchronously reading out the measurement every 2 ms--the 6602 can perform buffered pulse width measurements, but the timing must be set to Implicit meaning that each pulse width is latched into a buffer once it has completed. There is no way to deterministically make a pulse width measurement every 2 ms.
What I think you might be describing is that you are breaking up each read into a parallel thread. This would certainly make sense, especially if you are using On-Demand Timing (i.e. no Implicit Timing configured), since in this case the call to DAQmx read would initiate the start of the pulse width measurement. DAQmx Read blocks until the desired number of samples have become available, so you'd probably rather not call it sequentially for 5 different tasks if you want to maximize your loop rate.
If you're only interested in the most recent pulse width and don't need a buffered array of all pulse widths, I think On Demand timing is probably the best option. The 6602 only has 3 DMA channels anyway, so I suspect trying to run a buffered counter input task at 50 kHz on more than 3 channels will result in errors. It sounds like you are calling the reads in parallel, which is probably what I would recommend for maximizing loop rates. Be sure that you only start your task once outside of the loop, and all the loop is doing is calling DAQmx Read (whichever instance of the function you want to use).
Best Regards,