From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does CPU go to 100% when running my VI?

I have attached my VI to this post. The story is I have taken LabView Basics I & II. Now 9 months later I was given the task of working on this VI and am in over my head. Can someone take a look and see if anything jumps out at you?

 

Thanks,

 

Chris

0 Kudos
Message 1 of 8
(2,632 Views)

First glance observation:

 

You have abour a million property nodes that you rewrite with every iteration of the loops. Properties only need to be written when the property changes and not over and over and over.....

 

NOTE: If you ever want to get a job in the industry, better get used to keep your diagrams to the size of a screen. Your diagram currently fills about 50 screens of mostly duplicate code. Nobody in his right mind will attempt to troubleshoot or debug such a beast.

0 Kudos
Message 2 of 8
(2,626 Views)

I agree with altenbach.


You're code may work fine, however, it is very inefficient (which is why your computer is running at 100%).

The code is very redundent and/or unneccesary.

 

Like altenbach said, property nodes do not need to be rewritten if no change has occured. Especially if there are so many of them.

And if you have the same code, for two objects, don't just repeat the entire block of code, that will make the program slower. 

Cory K
0 Kudos
Message 3 of 8
(2,622 Views)

Chris,

 

The first thing which jumps out is the size of the diagram.  The style guides suggest keeping the diagram to one screen.

 

The next thing (maybe it was first, actually) is the number of indicators and controls on the front panel.  Can the user actually make sense of all that data?

 

There seems to be a a lot of duplicated code. For example the case structures labeled SO1, SO2, ... Appear to be identical except for the controls and indicators.  Making subVIs of such code can simplify the diagram considerably.

 

Generally the use of stacked sequence structures is to be avoided.  Use dataflow. 

 

Similarly, dataflow usually eliminates the need for local variables.

 

Consider the use of the event structure to handle user inputs.

 

Wiring should be from left to right.  Avoid hiding wires behind other objects.

 

Do you have specific problems or are you just trying to clean this up?  Does it work?

 

Good luck.  This looks like a big job for a beginner.

 

 Lynn 

Message 4 of 8
(2,617 Views)

Now that John mentioned that, I think that is a really good idea.

 

If you see a block of code that you seem to be repeating several times,

make a sub-VI. Then, you can use this sub-VI instead of repeating all the code over and over.


Not only will this help with efficiency, it will also clean things up quite a bit. 

Cory K
0 Kudos
Message 5 of 8
(2,612 Views)

Thanks to everyone who has responded so far. I was given this VI as you see it now and am trying to make sense of it. I agree that it is way to big. I will take all the suggestions you all have given me and repost when I have made progress. Would all of you agree that this is a crazy VI for a begineer to be working with?

 

Chris

0 Kudos
Message 6 of 8
(2,598 Views)

I agree that this is very complicated to begin with.
To make sense of it, I would recommend that you take a look at just 1 loop at a time and figure out what it is doing.

 

It appears to me that you have about 5 or so devices. This VI monitors the devices, and triggers alarms based on various events.

Basically, just figure out how 1 device is monitored, then you understand all 5.


This is why we said the code is redundant.
If possible, make a sub-VI.

The input to the sub-Vi would be:

- site active

- # of sites

- comm port

- etc

 

then have the sub-vi run the code provided

 

then have the output of that sub-Vi run to another sub-VI.

 

The second sub-VI will be the code in the case structure to the right.

If you notice, this is identical code, the only difference being which jps controls are being processed

This sub-Vi will have the inputs of :

- Controls in 

- comm port

- etc

 

So when all is said and done, you will have a few inputs for each of the 5 devices.

Each device will only need to run through 3 sub-VIs.

This will make the VI much more efficient.

 

Feel free to ask questions as you are modifying this program. 

Message Edited by Cory K on 09-19-2008 03:22 PM
Message Edited by Cory K on 09-19-2008 03:23 PM
Cory K
0 Kudos
Message 7 of 8
(2,593 Views)

Thanks Cory. I totally understand what you are saying. I am going to get to work and will post some progress soon.

 

Thanks again to everyone!

 

Chris

0 Kudos
Message 8 of 8
(2,587 Views)