How to speed up DAQmx operations?

[MichaGue_01]

Hello,

at the moment I do a little benchmarkig of some labview code. I try to improve some DAQmx operations to get the best performance out of the code. Later I will use this code in an application. In this application Part 1 and Part 2 will work in prallel followed by Part 3.

At the moment I use a PCI-6259, a Computer with a Pentium D 945 @ 3.4GHz, Windows XP SP3, LabVIEW 8.2.1 and DAQmx 8.6.

The system in future will run a PCI-6115, a Computer with a Pentium E8400 (faster then the Pentium D), Windows XP SP3, LabVIEW 8.2.1 and the latest DAQmx drivers.

At the moment the sample rate is about 600kS/s for each channel (limit on the PCI-6259 is 1,25MS/s). Later, this will be increased up to 10MS/s for each channel on the PCI-6115. I am not sure how this will slowdown the system, but that is not the question at the moment.

I think the fastest code on the actual configuration will also be the fastest on the future configuration.

Maybe anyone has some ideas to improve the following code. The was written with labview 8.2.1 and is attached.

Thanks a lot for your help and ideas!

Best regards,

Michael

Part 1.) Frequency measurement with one counter

I use a counter for frequency measurements, because I have a very clean signal out of the sync output of an Agilent 33220A. With the following code I benchmarked the code. The frequencys will range between 15kHz ... 150kHz. The speed of the measurement depends on the number of samples and the real frequency. For one sample and between 15kHz - 150kHz real frequency, the tooks about 2ms. CPU usage is around 5%.

For my surprise, this is much longer then one cycle of the sync signal (15kHz = 66,67µs and 150kHz = 6,67µs). In my understanding, if I only measure one sample, the longest time for data aquisition is 2 times the frequency, if I missed the edge for triggering. With a frequency of 15kHz the maximum time would be around 133µs.

Is there a chance to speed up the measurement with some change in labview code, to be faster then 2ms?

 

 

Part 2.) Triggered analog input of two channels

The analog input is triggered with the same sync signal the counter uses for frquency measurements. I was really surprised about the speed I reached, so I think this code is nearly at the optimum.

Maybe anyone sees some points for improvements?

3.) Analog output of two channels, one sample each

After the aquisition of the frequency (Part 1) and the analog inputs (Part 2) two correction values will be calculated and written as a output-voltage on two channels. At the moment, I do not have another solution than writing the values with a simple "DAQmx Write" in a loop. This needs a lot of time (around 1.5ms for just one value on two channel) and a lot of CPU usage (abround 70% o my computer).

Is there a chance to speed this up with less CPU usage by changing some labview code?

[Guruthilak]

Part 1.) Frequency measurement with one counter

1) remove the control "Anzahl sample per Kanal" from the while loop and put it outside (if the value does not change for every iteration)

2) remove the sequence structure

3) remove unwanted indicators.

4) remove the shift register that carries the Daqmax refnum

Part 2.) Triggered analog input of two channels

1) Take off the boolean connected to the shift register and the Case structure

2) remove the sequence structure
3) remove unwanted indicators
4) remove the shift register that carries the Daqmax refnum
 

 3.) Analog output of two channels, one sample each

1) Use "Spannung Output" control to build the array outside the loop
2) remove unwanted indicators
3)remove the sequence structure

4) remove the shift register that carries the Daqmax refnum

[MichaGue_01]

Hello Guru,

thanks a lot for your reply and ideas. But I see I haven't told enough. My mistake!

> Part 1.) Frequency measurement with one counter

> 1) remove the control "Anzahl sample per Kanal" from the while loop and put it outside (if the value does not change for every iteration)

The control "Anzahl sample per Kanal" is needed, because the value could change every loop.

> 2) remove the sequence structure

The sequence structure in this code is necessary to measure the iteration time of the loop. Later, it will be removed. 

> 3) remove unwanted indicators.

They will be removed.

> 4) remove the shift register that carries the Daqmax refnum

Is this really faster? I always thougth a shift register is the fastest.

> Part 2.) Triggered analog input of two channels

> 1) Take off the boolean connected to the shift register and the Case structure

That was just to test the different speed in trigger/untriggered mode. It will be removed later.

> 2) remove the sequence structure

The sequence structure in this code is necessary to measure the iteration time of the loop. Later, it will be removed.

3) remove unwanted indicators

They will be removed.

4) remove the shift register that carries the Daqmax refnum
Is this really faster? I always thougth a shift register is the fastest. 

> 3.) Analog output of two channels, one sample each

> 1) Use "Spannung Output" control to build the array outside the loop

The control "Spannung Output" is needed, because the value could change every loop.

> 2) remove unwanted indicators

They will be removed.

> 3) remove the sequence structure

The sequence structure in this code is necessary to measure the iteration time of the loop. Later, it will be removed.

> 4) remove the shift register that carries the Daqmax refnum

Is this really faster? I always thougth a shift register is the fastest.

------------------------------------------------------

The main question is, if the DAQmx code is optimized, or are there any options to speed the operations up.

Thanks a lot for your help and best regards,

Michael

[Guruthilak]

I agree that the shift registers are faster

But whats the use of using them in your code... since each for iteration of the while loop the value of the Daqmx refnum is going to the same..So instead use a tunnel...

Guru

[Norbert_B]

Michael,

this is not really a LabVIEW issue. The reason is the hardware interfacing. In your code, you always read/write only single values per channel (where computing mean values makes no sense at all). Ok, you already stated that you will increase the number of samples per channel with a rising frequency.

But currently, you are working with single point IO. Therefore, please read this link. Please note that Real-Time OS is most often better in single point IO than Windows OS.

Rule of thumb:

Finite operations (single point is somehow "finite" as well 🙂 ) add quite an overhead to the IO. The overhead depends a bit on the driver, only a little on the IDE you are using, a little bit on the OS you are using, but the main dependency is on the hardware itself. If you want/have to increase the performance for single point operation, you should take a look into the X-Series devices.

Is there a special reason why you need the loop to run that fast? Most often, you can collect the data in the DAQmx (continuous IO) and then work on sets of data....

hope this helps,

Norbert

[MichaGue_01]

---

@Norbert B wrote:

Is there a special reason why you need the loop to run that fast? Most often, you can collect the data in the DAQmx (continuous IO) and then work on sets of data....

---

Hi Norbert,

thanks a lot for your reply. Yes, there is a reason about the speed. The hole loop will be a controller. I know, the best way for building up a controller is the use of a real time system. But I need to save some money and it is no problem if the controller sometimes hangs - so there is no problem using a windows platform.

Best regards,

Michael

[F._Schubert]

Some comments on your benchmarking:

* CPU usage is a bad indicator. Some of the DAQmx functions use polling, so you can be close to 100% CPU usage and still increase speed.

* Set the priority of the VI to time critical. I'm not sure if you will experience issues in the benchmarking, but you should see a drop in performance without this setting if doing something else on the PC (Ope/Close a window).

* Try to use a timed loop.

Generally, your hardware is much faster than the software/OS. So you need to get most tasks done on the card instead of the PC. This is the case when you aquire 250 samples in Part 2, the transfer overhead is 'invisible' as the device already aquires the next 250 samples.

Felix

[Norbert_B]

If you are going into those settings, you'd probably want to disable debugging as well. But to be honest: I expect those optimizations to not tweak the application in such a way that you are going to celebrate......

Norbert

[Brad_K]

Hi Michael,

Here are some more suggestions.

In all cases, start or commit the task outside the loop whenever possible (like you did for AI), so that DAQmx doesn't have to reserve and program the DAQ hardware for each iteration. If you must use on-demand timing, starting the task outside the loop should speed it up by a measureable amount, even if it will never be as fast as hardware timing.

Analog in: This VI already uses hardware timed, buffered input, and it commits the task outside the loop, so this is almost as good as it gets. However, it can miss triggers, because re-arming the DAQ hardware for the next trigger is done by the VI, not by the DAQ hardware. M Series only supports hardware retriggering for counter output tasks, so doing analog input retriggering on M Series requires using the counter/timers to generate a sample clock. (Example: Retriggerable Analog Input with Analog Trigger.) The new X Series  devices support analog input retriggering natively in hardware.

Analog output: Starting the task outside the loop will help. You may be able to improve this further, depending on whether you're trying to optimize for low latency or for high throughput.

• Low latency: Use hardware timed single point mode. This enables hardware timing, eliminates buffering, and is optimized for control loops. One shipping example demonstrating an AI/AO control loop is in LabVIEW\examples\DAQmx\Control\Control.llb\PID Control-Single Channel.vi.
• High throughput: Use hardware timed, buffered output, such as that demonstrated by LabVIEW\examples\DAQmx\Analog Out\Generate Voltage.llb\Cont Gen Voltage Wfm-Int Clk-Non Regeneration.vi. However, buffered output requires you to write data well ahead of time, so it's not good for low latency control loops.

Counter frequency: Starting the task outside the loop will help. M Series doesn't support hardware timed single point for frequency measurement tasks, but you can maximize throughput by enabling hardware timed, buffered input using DAQmx Timing (Implicit).vi. Look at LabVIEW\examples\DAQmx\Counter\Measure Digital Frequency.llb for buffered frequency measurement examples. 

Note about the NI 6115: this device has deep onboard memory and is not designed for low latency. It doesn't support hardware timed single point for analog input tasks.

Brad

[MichaGue_01]

Hi Brad,

thanks a lot for your reply. I will have a look at your suggestions.

---

Brad K wrote:

Note about the NI 6115: this device has deep onboard memory and is not designed for low latency. It doesn't support hardware timed single point for analog input tasks.

Brad

---

I will use the NI PCI-6115 for the analog acquisition. In this case (later application) I have to sample 4 channels with up to 10MS/s. In each loop between 300 ... 3000 samples for each channel has to be sampled (depending on the freqeuency of the sampled signal). After the aquisition I will do some calculations and generate some single correction values, which are outputed with the 6115 or the 6259.

If I understand you right, the 6115 is not suitable for single point tasks.

So would it be the right way, to use the 6115 for acquisition (4 channels, multipoint, 10MS/s) and the 6259 for the analog output / counter measurements?

Best regards,

Michael