CPU usage rises in LabVIEW executable

[Benjaminateur]

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

[Jeff-P]

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!

[Ben]

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

[Benjaminateur]

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

[Jeff-P]

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!

[Ben]

---

@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

[Jeff-P]

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,

[Benjaminateur]

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

[mberetta]

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.

[transfererror]

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")