Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

ReadMultiSampleDouble vs ReadMultiSampleInt32

Hi,
is there a difference in the time spent calling ReadMultiSampleDouble vs ReadMultiSampleInt32 - that is, is less data copied over the PCI bus?
Cheers,
Lars
0 Kudos
Message 1 of 6
(3,105 Views)

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,

John Passiak
0 Kudos
Message 2 of 6
(3,096 Views)

 

Hi John,
I'm really pushing my system, so I'm trying to eliminate all the unnecessary stuff.
What is the precision of the binary data?
Is no scaling/conversion performed if I call ReadMultiSampleUInt32?
Cheers,
Lars

 

0 Kudos
Message 3 of 6
(3,081 Views)

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,

John Passiak
0 Kudos
Message 4 of 6
(3,070 Views)

 

Hi John,
The computer is an Intel Core 2 Duo 2.26Ghz 2GB Ram Win 7 32bit, 
and I'm doing 5 x 50kHz pulse width measurements distributed on two 6602 cards.
The measurements are read out synchronously every 2 ms.
(I found that reading synchronously from my own threads instead of the Daq tasks gives me a better control of priority and performance).
I want to minimize any delays so that I'm as up to date as possible on the incoming data.
Cheers,
Lars

 

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

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.

 

        2011-04-08_125654.png

 

 

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,

John Passiak
0 Kudos
Message 6 of 6
(3,047 Views)