NI VB-8012 Data aquisition speed

[MathLabLer]

Hello again everyone,

I recently got a NI VirtualBench 8012 as new "Frequency Counter" and started writing a suitable VI this week. I checked the "general workflow" of the sub-VIs needed to access the VB according to the NI support website and came up with the VI attached.

My goal: measure the frequency of the signal on both analoge channels by making an average of 10k single measurements.

My problems so far: it is waaay too slow. According to product specifications the VB is capable of aquiring 500 MS/s (which is 500 fold the number I want to aquire), but the attached VI needs almost 4 seconds to take 10 measurements. Why?
I know that the hardware and software would be able to aquire sufficient datapoints in less than a second, because I can make the implemented software (also called VirtualBench) measure the mean of 4096 single measurements in less than a second.

The comments in the VI are in German and just describing my problem and what the VI is doing at which point.

And another question on the side:
How does the filter-VI work exactly? If I choose "moving average" as filter mode and 5k points as halflife, it averages everything by dividing it by 10k until it reaches 10k data points, right? So the first 10k output values of the filter would be worthless?

Settings: VirtualBench 8012, LabVIEW 2018 32bit, Windows10 Pro; applied signals: frequency generator on Channel 1, external frequency generator on Channel 2, ~10 MHz frequency.

Thanks for helping me out on this one 🙂

P.S.: I know that the VB is no frequency counter, but the NI salesman promised us, that it could be used as one..

[PatrikKaranNI]

Hi MathLabLer,

As this is outdated post a little bit - do you still encounter the problem with waaaay to slow measurements? 🙂 

If yes - after first look at you vi - separate subVIs for initializing, configuring your measurement before you enter the loop and close all of the them after you finish the execution of the loop. Inside, you will just read values. 

Another tip could be to have these two measurements not connected with error cluster 'in series' but more likely 'in parallel'. (this however does not significantly change the speed of execution).

Hope this helps!

Regards,