CPU usage rises in LabVIEW executable

[xavvvv]

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,

[mberetta]

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.

[transfererror]

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

[Yamaeda]

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.

/Y

[xavvvv]

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,

[JonOberg]

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.

[JonOberg]

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

[transfererror]

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

[xavvvv]

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,

[JonOberg]

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?