Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Background influences performance while doing frequency measurement using NI 9401 module

Hi All,

As a part of a bigger VI i've had some performance problems and did a teardown trying to solve it.

I discovered that the reading of frequency pulses, using a counter with NI9401 (slot 5) + cDAQ9178 was suddenly interrupted and slowed down. It had worked perfectly before.

So i started to teardown my big program, and tried to discover the part that was causing this.

(the total program has 2 analog inputs (NI-9221), 2 loadcells (NI-9237), reading RPM + generating 3 PWM signals (NI-9401) and optional 4 temp readings (NI-9211) )

 

But finally i ended up with only the rpm part, and it was still running bad.

I started a new VI and did a copy of the blockdiagram and pasted into the new VI.

Now it runs perfectly. ???

After some more deleting to find the differences, i discovered that placing a background on the frontpanel causes this problem.

But, also strange, when i add a background to the new VI, it doesn't influences it ??

I have attached the bad VI with background.

Can somebody find something that's causing this ?

PS. I'm using LV2017....

 

Many frustated thanks....

 

Tom

0 Kudos
Message 1 of 5
(2,518 Views)

Hello Tom,

  1. Can you spot any difference between your old VI and the new one? Maybe the background setting differs, Stretch vs. Tile?
  2. When talking about performance problems, do you mean that your loop rate was slow? How big was the difference you saw, how many milliseconds with the background, and how many without?

If the difference is in the order of milliseconds, then I'd say LabVIEW has to redraw the background image on every loop iteration due to some kind of windows item overlap, causing the slow-down due to the image itself. Drawing an image is slower than just a plain-color background.


Ingo – LabVIEW 2013, 2014, 2015, 2016, 2017, 2018, NXG 2.0, 2.1, 3.0
CLADMSD
0 Kudos
Message 2 of 5
(2,490 Views)

Hi Ikaiser,

1. I don't see differences between both VI's. All settings are the same.

2. loop time does not change when adding/removing background. I only see that the gauge is not updating with the same speed.

 

I did some extra tests, and saw that instead of taking only 1 sample/ch, taking multiple samples/ch and calculate the mean of it, does improve the gauge speed. Now adding a background does not vusually effect the gauge.... ???

Only disadvantage is that @ low speeds (frequencies) the loop time increases up to 1000ms (10Hz, 10samples), while when running at 500Hz, the loop time is about 20ms..

But still, in the other case when taking only 1sample/ch, the background does have an influence. You can easily reproduce it,

 

0 Kudos
Message 3 of 5
(2,476 Views)

Hello Rockyenco,

I did some testing. Attached you can find a simplified version of your VI. I removed everything except the loop, the background, the benchmarking code, and the indicators.

 

Executing it full-screen with background image, I can see the indicators updating maybe 10 times per second. Resizing the window to be smaller I can see the indicators updating faster.

Removing the background image and executing again at full-screen, the indicators update at a much higher pace. It's faster than my vision so I cannot tell how fast exactly, must be somewhere between 20x and 60x (my screen's fps) per second.

 

I'd say this is expected behavior. Why? LabVIEW applications are executed in multiple threads, see e.g. the picture taken from here (ignore the Real-Time part):

 

All Front Panel items are handled in the User Interface (UI) thread. This uncouples your (more important) code from front panel item updates. This is important, because Front Panel refreshing is very slow compared to normal code execution. You noticed this in your VI. A simplified explanation is that Front Panel items are drawn through the Windows API, which is also comparably slow. "Comparably", because a simple code loop can execute million times per second, but drawing something on screen is more complicated, and it also does not make sense to update a screen more than maybe 100x per second.

 

Please not that displaying buttons of mainly one color is quite quick, whereas drawing images with a potentially different color on every pixel is slow. This is also the reason that games and graphics-intense applications use dedicated, and highly optimized graphics drivers and frameworks like DirectX and OpenGL.


Ingo – LabVIEW 2013, 2014, 2015, 2016, 2017, 2018, NXG 2.0, 2.1, 3.0
CLADMSD
Download All
0 Kudos
Message 4 of 5
(2,473 Views)

Hello Ikaiser,

Thanks for the "extended" explanation.

I was not realizing that it would be as normal as that.. 🙂

It's good to know for future projects.

Always trying to make the frontpanel with a unique look, but this seems not always the best solution.

Tom

0 Kudos
Message 5 of 5
(2,465 Views)