LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Simple labview program uses 100% CPU after some days?

Solved!
Go to solution

A minor but annoying problem I see from time to time is that a few of my really small compiled Labview programs seems to use 1 full CPU core after a few days of running. In short:

Labview 2015

Windows 10

Compiled exe-file of program with 60s loop time, see below.

At start uses 0% CPU in task manager

After a few days (a week) it uses 16% CPU on a 8 core PC, I assume this is one full core.

CPU load stays even if I stop the exe and keep it open. If i close the exe window and open it again I am back at 0% CPU again.

Just noticed that the idle Labview development system also uses 16% CPU?

I am not sure if the CPU load is real, or some kind of a artifact,so far I've not noticed the PC slowing down.

 

Task mananger shows heavy CPU load from simple program running for a week:

Task manager after a week

 

After closing the app Kör datorn and opening it again I get 0% CPU:

0% CPU after restart of program

 

Code, the program just writes to a file every minute:

Code

0 Kudos
Message 1 of 11
(5,148 Views)

my guess would be that labview has to allocate new memory for your ever growing Events-Array.

 

<edit>

but that can't be everything, because your ram usage isn't all that high

 

sorry should have started my brain first before typing

</edit>


If Tetris has taught me anything, it's errors pile up and accomplishments disappear.
0 Kudos
Message 2 of 11
(5,142 Views)

@jwscs wrote:

my guess would be that labview has to allocate new memory for your ever growing Events-Array.


You might still be on to something.  Another thing that could be happening is the redraw of the front panel that is being forced every time the array value is read and written (yes, Value Property Nodes force redraws of the front panel in a synchronous manor).

 

Of course, there is still a subVI in there that we have not been given access to.  Something could be hiding in there, possibly a reference that is left open.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 3 of 11
(5,087 Views)
Solution
Accepted by topic author Ola_A

I remember an old thread mentioning that just leavning the LV start open for a day could cause it to spin wildly, i wonder if that's connected to this.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 4 of 11
(5,069 Views)

@crossrulz, the only non standard vi, the Error logger2.vi should be included in the zip, but not in the correct path.

 

@Yamaeda, I really think the Labview development can be the source of this, I have a vague feeling that I have seen Labview dev system at 16%=1 core a few times when I also noted my small programs using much CPU. I will do a simple test, run my program on a pc with labview dev at idle, and another pc, and we will see after a few days!

0 Kudos
Message 5 of 11
(5,025 Views)

@Ola_A wrote:

@crossrulz, the only non standard vi, the Error logger2.vi should be included in the zip, but not in the correct path.


Except for the "Write To Spreadsheet File (string) w error handling.vi" that is missing from Error logger2.vi.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 11
(5,013 Views)

Oh, of course! Here it is. Smiley HappyThe earlier version of Write to spreadsheet did not have an error out connector, I just added that.

 

When finding this vi I suddenly remember a strange bug, probably back at Labview 2012. Compiled code run fine in Sweden, but in Japan, on a japanese windows (7?) the exe did not start. It turned out that the file path for one of the vi's source had swedish caracters (åäö ÅÄÖ) in it. When I removed them all was fine. How the source codes file paths could influence the compiled code I never understood, and I have not tested it in later versions of Labview.

0 Kudos
Message 7 of 11
(5,005 Views)

As a general rule, never use special characters in file names. This was more serious in the past, but still applies today. Just use plain English.

0 Kudos
Message 8 of 11
(5,001 Views)

Yamaeda, now I've tested some more with leaving with Labview development system on for two weeks. Now the Labview dev system uses 17% CPU (about 1 core) and a small exe I wrote also uses 17% CPU (normally 0%).

 

Task manager showing heavy CPU load from Labview development system and small LV exe after about two weeks

2017-06-08 10_44_25-Foton.png

 

I pressed Stop on the "Kör datorn.exe", and that program still uses 17% when the program is stopped!

 

Stopped labview program still uses 17% CPU!

2017-06-08 10_54_09-Foton.png

If I load a project in Labview dev system CPU load get lower during load process, and then goes back to 17% again.

I close Labview dev. "Kör datorn" at off state still uses 17% CPU.

If I close the app window also for "Kör datorn" and open it again CPU is back at 0%.

Starting Labview 15.0.1f7 again, that settles on a few percent CPU after a minute.

 

My guess is that some support code (Labview Runtime?) used by both the development system and exe files are causing this.

 

I've only seen it on a development machine, so it should not be a big problem in reality.

/Ola

 

0 Kudos
Message 9 of 11
(4,888 Views)

Hi Ola!

I've not really heard of it in executables, in that case it'd be a big bug. It's annoying enough in the IDE but not critical.

 

As to the swedish characters it makes sense as the exe keeps the internal file structure. It was pure luck that my program in Japan worked flawlessly from that perspective, though it's mostly french remnants within VI's in this case.

 

Skönt det ordnade sig.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 10 of 11
(4,857 Views)