topic Re: CPU usage rises in LabVIEW executable in LabVIEW

CPU usage rises in LabVIEW executable

Benjaminateur — Mon, 22 Oct 2012 13:43:16 GMT

Multiple people have been having the same problem with LabVIEW execultables at my company. We just found out the root cause for this problem. I therefore would want to share our solution on the forum.

The problem appears as follows:

Running our application in source code, we have a normal CPU usage (as seen on the Windows task manager). When we run the built version of the application, after some random action, the CPU usage rises to about 50% and stays that way until we shut down the application. The funny thing is, if we click on the a windows titles bar or on the menu bar, the CPU usage returns to normal then, when we unclick the title bar or leave the menu bar, the CPU usage goes back to 50%.

This problem was seen on LV version 8.5.1 and 2012. It turns out the problem was with the Front Panel -> Open property node (no longer supported in LV2012). Replacing the property node with the equivalent invoke nodes (Front Panel -> Open and Front Panel -> Close) resolved our issue. This was a tricky issue to solve so I hope this helps others having the same issue and not having any luck finding solutions on the forum!

Thank you,

Benjamin

Re: CPU usage rises in LabVIEW executable

Jeff-P — Mon, 20 Apr 2026 00:46:07 GMT

Hi Benjamin,

Thank you for sharing your solution! A few resources I would like to point out which can hopefully prevent this from happening in the future during the upgrade process. First is the LabVIEW Upgrade Notes which itemizes all changes being made in the new version of LabVIEW, including deprecated functions. The front panel open property is deprecated so it shows on the block diagram in red and the context help indicates it is deprecated. The only way to get it on the block diagram is to upgrade code from a previous version of LabVIEW.

The second resource I would like to share is the LabVIEW 2012 VI Analyzer Upgrade Tests. You can download these VI Analyzer tests and run them on any code that you are migrating between LabVIEW versions to quickly see if any parts of your code are using deprecated functions etc. This means you don't have to poke through every VI you are upgrading. More information and the full set of tests can be found at this developer zone white paper. Hopefully this will save you a headache in the future!

Re: CPU usage rises in LabVIEW executable

Ben — Tue, 30 Oct 2012 15:26:58 GMT

That is a realy nice attempt at recovering Jeff.

Of course people like me are thinking "fix the bug on the degraded running slow, break the code, or do the VI morphing thing to fix it."

Again nice try!

Ben

Re: CPU usage rises in LabVIEW executable

Benjaminateur — Tue, 30 Oct 2012 16:06:30 GMT

Ben,

I would tend to agree with your thinking. We spent a whole lot of time investigating this issue here in multiple applications. Having no warnings, errors nor broken code in the VIs using deprecated code from previous versions, we did not suspect that there could be a serious issues coming out of that usage.

Nevertheless, in the future, I will use the utility mentionned above to get rid of all deprecated code from my projects after migrating to a new LabVIEW version.

Thank you,

Benjamin

Re: CPU usage rises in LabVIEW executable

Jeff-P — Tue, 30 Oct 2012 16:06:48 GMT

Hi Ben,

I did file a CAR on this behavior since I agree that if the deprecated property has an issue with it (like this) then it should break the run arrow. CAR 376575

I mainly wanted to inform other users who are looking in this thread that there are tools available for use during the upgrade process which help to find things like this.

Thanks again!

Re: CPU usage rises in LabVIEW executable

Ben — Tue, 30 Oct 2012 16:20:14 GMT

@Jeff-P wrote:

Hi Ben,

I did file a CAR on this behavior since I agree that if the deprecated property has an issue with it (like this) then it should break the run arrow. CAR 376575

I mainly wanted to inform other users who are looking in this thread that there are tools available for use during the upgrade process which help to find things like this.

Thanks again!

Not knocking you Jeff!

Now that NI is aware of this situaion, your assocaiates have a chance to include a bug-fix/ptach to correct this situation.

We don't want people getting the impresion "upgrade at your own risk".

Ben

Re: CPU usage rises in LabVIEW executable

Jeff-P — Tue, 30 Oct 2012 20:55:35 GMT

Hi Benjamin,

I have been unsuccessfully trying to reproduce this. I re-read your post and I have a few additional questions for you

1) Do you see the same behavior in 8.5.1 and in 2012 with that property node? Or is this a new behavior that appeared when you upgraded 2012? I am trying to determine if this is something that changed when the VI was deprecated or if the behavior always existed.

2) Do you have a simple project that can recreate the behavior? I have been making executables with that property node in 2012 and have not been able to reproduce this.

Regards,

Re: CPU usage rises in LabVIEW executable

Benjaminateur — Tue, 30 Oct 2012 21:42:27 GMT

Hi Jeff-P,

I only first experienced the problem myself in LabVIEW 2012, but one of my collegue got the exact same problem in LabVIEW 8.5.1. Back in 2009, my collegue was not able to solve his issue directly. It turns out the issue disappeared when he redid a vi from scrath that was using the front panel property node and used the method instead. At that time, he did not understand how the problem disappeared, but we were later able to corrolate the problem with the use of the front panel property.

I don't have a simple projet that can generate the problem. I can try to create one. However, I can be a little more specific on the architecture generating the issue. Funny thing is that the problematic VI was performing a similar function and was called in the same way in both of our problematic applications (one in 8.5.1 and one in 2012).

Both application were data acquisition applications. In both cases, the problematic VI was a loading screen called from a thread that is not the main thread. The loading screen front panel opened using the front panel open property to TRUE and closed using the front panel open property to FALSE. The CPU went to 50% when the loading screen front panel opened and remained there until we close the application.

I hope this helps,

Thank you,

Benjamin

Re: CPU usage rises in LabVIEW executable

mberetta — Mon, 25 Feb 2013 14:27:24 GMT

Hi,

I'm facing this issue (unexpected cpu stuck at 50%) even using the suggested invoke node.

Based on my finding, the issue is detected when closing the "remote connection" (more frequent using "remote desktop" but also detected using vnc) at pc unning Labview 2012 executable.

Issue was not detected instead using Labview 2011.

Hope this help to lead to a solution.

Best Regards,

Marco.

Re: CPU usage rises in LabVIEW executable

transfererror — Tue, 29 Oct 2013 13:09:55 GMT

I've the same problem here using Labview 2012. For me it also seems that the problem is correlated to closing a remote connection ("remote desktop" or "teamviewer")

Re: CPU usage rises in LabVIEW executable

xavvvv — Wed, 30 Oct 2013 18:45:37 GMT

Hi,

Would it be possible to give a little more details as to how that connection is related to the application? Are you saying the CPU usage goes back to normal when you close the already-open remote connection? I'll need a little more information to try to recreate the issuee. Could you include a screenshot/snippet of your implementation in LabVIEW 2012?

Thanks,

Re: CPU usage rises in LabVIEW executable

mberetta — Wed, 30 Oct 2013 18:56:50 GMT

I can 100% replicate this failure just changing the Windows 7 screen resolution while Labview 2012 is open.

This also apply to ALL windows's remote desktop connection which set the remote client size accordling.

Re: CPU usage rises in LabVIEW executable

transfererror — Thu, 31 Oct 2013 07:21:50 GMT

Hello xaww,

unfortunately I can't give you a snippet or a screenshot. I also couldn't figure out a method to reproduce this error in any cases. But I also recognized (just as mberetta) that the error also occurs when changing the resolution.

In my case the CPU usage increases to 50% (dual core). After that I can stop and close my (two) running vis. But the CPU usage remains on the 50% level. I can not close Labview itself. I have to use the task manager for that.

Btw:

1. both vis have been originally written in Labview 7.1

2. up till now the error only occured when both vis ran simultaneously

3. Profiling "Performance and Memory" didn't show abnormalities

transfererror

Re: CPU usage rises in LabVIEW executable

Yamaeda — Thu, 31 Oct 2013 07:50:56 GMT

I've also had some issue with depradated(?) functions, it should atleast give warnings, and preferrably broken errors if used. In my case it was get/set control value that simply didn't function.

I cant pinpoint how to reproduce more than saying: Make a vi with functions in 8.0 that's been scrapped in newer versions, then use those vi's in 2011+ and see if it still works.

Re: CPU usage rises in LabVIEW executable

xavvvv — Thu, 31 Oct 2013 23:29:15 GMT

Hello all,

As far as the remote desktop connection spiking the CPU, I have not been able to reproduce it as of now (changing the screen resolution in LabVIEW 2012, Windows 7 using a LabVIEW 8-built VI with a deprecated function). If anyone can provide a screenshot/snipped or a basic VI that replicates the same issue, I would be able to work off of that.

Can you also try, if you have LabVIEW 2013 installed, to replicate the behavior in 2013?

As for the depracated functions not generating errors, I will discuss this with colleagues and determine if this is a wanted functionality or not.

Regards,

Re: CPU usage rises in LabVIEW executable

JonOberg — Thu, 07 Nov 2013 10:10:38 GMT

I've also been struggling with exactly the same issue. It seems like all which experience the same problem, have upgraded from an older version, or am I wrong?

Can LabVIEW have missed to compile properly when the project was upgraded? Would a "Mass Compile" before building be a solution? In my case I've upgraded code from 8.6 to 2012.

I can add that the system has been running partly on LV2012 runtime.. one application ran on 8.6 before. Now I've built all applications in 2012 SP1 and for the moment CPU usage is normal.. so I can't really tell if it made any difference.

This is a system which is accessed by Remote Desktop.

Re: CPU usage rises in LabVIEW executable

JonOberg — Thu, 07 Nov 2013 11:00:28 GMT

I'm near a solution, it's has to do with the Remote Desktop settings, when you connect. It may differ from one computer to another.. don't know if it's the screen resolution or if it's 32/64-bit dependant or something else. Under the tab "Performance" I selected all available visual options (highest bandwidth req), and then the CPU usage dropped. Now I'm not able to get it high again, even when I log in and out with the computer that made the CPU go up, at first. Maybe you have to do something special.. open windows, maximize, minimize a.s.o.

We're connecting from W7 to a system with XP.

The computer that made CPU go up has an 32-bit OS, all other are x64. (the architecture may no be te reason why it happened, just informing).

Re: CPU usage rises in LabVIEW executable

transfererror — Thu, 21 Nov 2013 09:30:42 GMT

The Problem still remains here.

I found another thread (no solution either) dealing with a similar problem.

http://forums.ni.com/t5/LabVIEW/Remote-front-panel-close-client-makes-CPU-go-100/td-p/2575697

I still have the feeling, that it depends on changing desktop settings (resolution, Labview front panel/block diagram maximized/minimized/closed, etc.)

Any help would be greatly appreaciated, since I want to run my monitoring vi 24/7 and don't want to restart it every now and then.

transfererror

btw: I'm using the latest Intel HD graphics driver (9.17.10.2932) on my Windows 8.1 system

Re: CPU usage rises in LabVIEW executable

xavvvv — Fri, 22 Nov 2013 19:09:04 GMT

Hi transfererror,

Could you try mass compiling your VI in LabVIEW 2012, as suggested by JonOberg? Do you also have access to LabVIEW 2013 and can you replicate it in that version?Also, just to better understand, is the CPU spike happening on the machine running the VI or the on the monitoring machine (the one opening the remote desktop connection)? I have again tried to replicate the CPU spike and am still unable to have the same behavior. Again, if you can attach a simplified VI that displays the same behavior, it would be very helpful. There is not much more I can do.

Thanks,

Re: CPU usage rises in LabVIEW executable

JonOberg — Mon, 25 Nov 2013 07:50:25 GMT

I solved it by uninstalling every NI-product and installed LV2012 SP1. Now everything seems to work just fine. There were many runtimes installed on that system.

I think that problem has to do with Windows and LV, that gets caught in a loop where LV thinks the user or the OS wants it to "refresh the front panel". Remote Desktop seems to trig this by "stripping" visual effects for better performance when accessed with a slow connection. Maybe the display resolution has to do with it?