LabVIEW
CPU load when application is minimized is reduce 50% ?
@PasiSalminen wrote:
Hi,
I have similar observation/problem. The effect is same (VI CPU load drops when minimized), but result is unwanted.
I made a VI to demonstrate this. On the FP you can see that the time between while loop iterations is 2ms when the VI is frontmost application on windows. But when I switch e.g. to web browser, then after a short while the delay between while loops jumps to 15ms. Then I change back to labview and the delay drops back to 2ms.
How to fix this? I have a feeling this has something to do with the wait(ms).vi, how I can replace it? I think operating system is altering the 1ms ticks.
I have windows 11 and LabVIEW 2017.
Would everyone else please allow me a minute.
First, there is a single thread in your OS devoted to updating the user interface. It is called the UIThread. That SINGLE operation thread is responsible for every thing the USER may be exposed to.
Graphs , charts and every other Front panel object need a buffer between the data and how the data is displayed to the user. Are you with me so far? That buffer is known as a transfer buffer and it does catch everything that the dataspace from your program needs to present to the user. That takes some time and a switch to the Single 'Ui' thread.
I don't want to risk a "tldr" here. Let us know what you think the OS should be doing differently.
You(THE DEVELOPER) need to be aware That the the OS proirtizes the USER. Often, the USER is not around the data display, or even worthy of evaluating the current dataspace values!
@PasiSalminen wrote:
How to fix this? I have a feeling this has something to do with the wait(ms).vi, how I can replace it? I think operating system is altering the 1ms ticks.
I have windows 11 and LabVIEW 2017.
We cannot debug images, especially if we need to guess what's in the other cases of the case structures. Please attach your VI instead.
Also be aware that LabVIEW 2017 is not officially supported under Windows 11 , so all bets are off anyway. I would be happy to test under a newer version.
If you really need more precise timing, use a timed loop. It will even tell you if it cannot keep up.
Does the same happen if you use less convoluted code?
For example....
Another consideration:
The same effect of the timer changing its resolution is observed is seen with the Timeout case of an Event Structure. When you hover over the LabVIEW icon in the taskbar to display small windows, the resolution dynamically changes to its smaller value back as seen in the plot.
@PasiSalminen wrote:
I solved the matter. The solution related information is below:
Source:
Disable background throttling (need admin on command prompt):
powercfg /powerthrottling disable /path "C:\Program Files (x86)\National Instruments\LabVIEW 2017\LabVIEW.exe"
LabVIEW.exe will have 1ms system timer even if on background
Enable background throttling:
powercfg /powerthrottling reset /path "C:\Program Files (x86)\National Instruments\LabVIEW 2017\LabVIEW.exe"
Now LabVIEW.exe will have ~15.6ms system timer on background and will save a lot of energy...
Check configuration:
powercfg /powerthrottling LIST
Thanks, good to know. Though you shouldn't rely on Waits.
