LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Increasing the acquisition speed for my application

Solved!
Go to solution

Hello,

[Application explanation] I am trying to write a code that performs delayed-feedback control. To do so, I need to measure data produced by a very fast system (the system operates in the range of tens of kHz). The control scheme requires me to subtract the input control signal at time (t) from the output of my system at a previous time (t-tau), all the time.

 

To do this, I need to acquire the system's output at a very fast rate. However, because of the nature of my application, I cannot rely on acquiring multiple samples at the same time using the DAQmx Read vi. 

 

[Current system] By acquiring 1 sample per loop, I am only restricted to around 1000 samples per second. Is there a way for me to increase this rate to 10,000 or even 100,000 samples per second?

 

 

0 Kudos
Message 1 of 6
(2,054 Views)

Download more than 1 point at a time. Do your processing on an array of data.

 

mcduff

0 Kudos
Message 2 of 6
(2,031 Views)

Thanks for the suggestion. That would be great if the array would be generated in real time. But since the array is generated at the end of each loop will not help. This is because data acquisition needs to be in real time and long loop time will limit the amount of delay period I can aim for (I am hoping for a loop delay of only 1 microsecond but I cannot get less than 100 microseconds at this point)

0 Kudos
Message 3 of 6
(2,024 Views)

You have set up your Analog Input to sample read 10 points at 100 kHz.  You then proceed to read those points in one at a time, and find you can't read faster than 1 kHz.  However, if you configured your DAQ Read to be 1 Channel N samples and wired 10 into the number of samples to read, you'd (probably, I hope) find that you get all 10 samples in 10/100 kHz = 100 microseconds.  If this is too long a delay, try a combination of faster sampling time or shorter (but not 1!) sample size.  For example, if you sampled at 500 kHz and took 5 samples, you'd get 5 samples every 5/500 kHz = 10 microseconds.

 

Bob Schor

Message 4 of 6
(2,019 Views)

@HHasan wrote:

Hello,

[Application explanation] I am trying to write a code that performs delayed-feedback control. To do so, I need to measure data produced by a very fast system (the system operates in the range of tens of kHz). The control scheme requires me to subtract the input control signal at time (t) from the output of my system at a previous time (t-tau), all the time.

 

To do this, I need to acquire the system's output at a very fast rate. However, because of the nature of my application, I cannot rely on acquiring multiple samples at the same time using the DAQmx Read vi. 

 

[Current system] By acquiring 1 sample per loop, I am only restricted to around 1000 samples per second. Is there a way for me to increase this rate to 10,000 or even 100,000 samples per second?

 

 


The data acquisition will NEVER be in real time if you are using a Windows box. If you need to operate on the data in real time you need a FPGA. Your latency and jitter with taking a single point is going to be much worse than if you download a bunch of points.

 

mcduff

0 Kudos
Message 5 of 6
(2,004 Views)
Solution
Accepted by topic author HHasan

Here's a brief preliminary response to the brief, preliminary code you showed a picture of:

 

1. You seem to be using a cDAQ device which is definitely *NOT* a good choice for the low latency you want to achieve.  Neither USB nor Ethernet cDAQ are nearly as good for low latency as a simple desktop PCIe device.

 

2. Your use of "RelativeTo=Most Recent Sample" seems likely to be incomplete.  You probably should also set "Offset= -N" and then read N samples.  That approach will try to immediately give you the most recently converted N samples without waiting for new ones.  On a desktop board it would be really fast.  On cDAQ, well, not quite so much.  The latency thing.

    Note: if/when you make this change, you may have further complications.  Reading "most recent" samples no longer gives you a lossless stream.  And it doesn't help give you regular-ish timing (it's *never* truly regular under Windows).  So you may need to compensate for these things.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 6
(2,002 Views)