Exe consumes much more CPU then development

[Ben]

That code looks like is was developed with what was current practice for about LV 6 since it uses the polling of button presses and search for the first true after building an array.

Is there any difference between the development and exe as far as how much info is in that global that is repeatedly passed to the property node?

Do you have any "wait" inside the loop that handles the button punching?

If that loop is just looking for a button punch there is no reason that let it just spin un-throttled.

Property nodes execute in the UI thread and require a context switch to same and back from. You did not show enough of that loop with all of the buttons to speculate much more. There was a version of LV (not sure which) that had issues with property nodes repeatedly switch back and forth in and out of the UI thread.

Let me repeat my previous suggestion and just start tossing parts of the code until the anomaly goes away. What ever you toss just before the issues goes away is where the problem is.

Just my two cents worth,

Ben

[JÞB]

---

@Ben wrote:

That code looks ....

Let me repeat my previous suggestion and just start tossing parts of the code until the anomaly goes away. What ever you toss just before the issues goes away is where the problem is.

Just my two cents worth,

Ben

---

And when the block diagram is empty you will be 90 percent of the way to a solution. 

[Balanceman]

Hi Ben,

the early beginning of that code was during LV 6, so it really is an old beast.

There is a wait in the big loop, presently set to 100 ms.

There is a property node in there lokking if the FP is still open. When somebody uses the Windows X, it terminates the loop and cleans up some things, and finally exits LV.

I am using the same data in the development environment and in the EXE, so the content of the globals is the same.

I see your point tossing parts of the code and see when the problem goes away. However, that will cause hours, if not days to go through that.

[GerdW]

Hi Balanceman,

There is a property node in there lokking if the FP is still open. When somebody uses the Windows X, it terminates the loop and cleans up some things, and finally exits LV.

Replace that code by an event structure waiting for a "Panel close" event: no need for polling!

code was during LV 6, so it really is an old beast.

However, that will cause hours, if not days to go through that.

Taking some hours (or even some days) is not much for a tool developed/used over more than 10 years!

When this tool is so important after all that time you really should invest some manpower on improving it…

[Ben]

---

@Balanceman wrote:

Hi Ben,

the early beginning of that code was during LV 6, so it really is an old beast.

...

I see your point tossing parts of the code and see when the problem goes away. However, that will cause hours, if not days to go through that.

---

I do not follow you there.

Does it take a while to ramp up the CPU load?

I propose you toss half of the code, try it out and then decided if the tossed code is the culprit.

If not put that code back and toss the other half.

Old joke time!

I used to be an Field Service Engineer (FSE) at Digital Equipment Corporation...

Q: How does a DEC FSE fix a flat tire"

A: He keeps swapping them until he finds the one that is flat.

Keep whacking away until you find that CPU hog!

Ben

[alexderjuengere]

---

@Balanceman wrote:

I have replaced the WUNmsM with Wait.

I don't have any Timed Loops in that project.

I have disabled (False Cases) several functions testwise.

Have checked the compile logfile. No warnings.

The main VI just sits there and waits for user input / clicking any button which would then call a subVI. The main loop has now a 100 ms wait.

CPU load is still about 30% when running the EXE.

Somehow I get the feeling that the EXE builder does something weird...

---

have you forced labview to fully recompile the whole .lvproj / .vi before running and seeing the 4% CPU ?

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P82uSAC&l=de-DE

[JÞB]

---

@Balanceman y. However, that will cause hours, if not days to go through that.

---

As opposed to the days and hours we keep guessing?  

I suppose that you can keep expecting us to fire a silver bullet or, do some digging for gold.