Exe consumes much more CPU then development

[Ben]

I only have couple ideas at this time.

1) Log a SR with NI Support and share the code with them.

2) (Not sure) if the Desk Top Execution Trace Toolkit will run in an exe but that may shed some light on the difference.

3) Start whacking away half of the code and rebuild and test the app. If it still does it, whack another half... Until you find the offending code. Then share what you find.

Ben

[JÞB]

DETT is the way to go and it does have hooks into the exe. Or more exactly, it looks lv calls to the OS so, it can offer insight.

One thought I have is "hey, Jeff! I say to myself.  Jeff, what if automatic error handling is turned off or defeated with wire nuts or dead code rather than passed through?  And what if the exe uses some properties or methods that load the Front Panel into memory? And what if those are missing from the exe...." And then I say "Jeff, that would make the OS look all over for the missing panel the toss out the error causing a massive CPU load.

[Balanceman]

I don't have the DETT available, and will not buy it for over EUR 1000,-.

Yes, I use the method open frontpanel, but I have disabled that testwise. Instead, the FP is opened on VI start.

I also use the property "open frontpanel" in read mode, to detect if the user has closed the FP with the X, and if that is the case, I quit the VI. There seems to be no other way to detect a closed FP and react on this.

Will follow the advise to check for dead end error wires.

Thanks for your input.

Gerd

[aptivo]

You could use a trial version of the toolkit and uninstall it afterwards if not needed any further.

[Intaris]

Maybe a sprinking of THIS?

[JÞB]

---

@Balanceman wrote:

I don't have the DETT available, and will not buy it for over EUR 1000,-.

Yes, I use the method open frontpanel, but I have disabled that testwise. Instead, the FP is opened on VI start.

I also use the property "open frontpanel" in read mode, to detect if the user has closed the FP with the X, and if that is the case, I quit the VI. There seems to be no other way to detect a closed FP and react on this.

Will follow the advise to check for dead end error wires.

Thanks for your input.

Gerd

---

Well, did you include the FP of tha vi in the build? .... What are you doing with the error out of the invoke node? SHOW some CODE!

[Balanceman]

Yes, for sure the FP is included. It shows up when the VI or EXE ist started.

I can't send the VI, as there are way too many dependencies / SubVIs.

But I send a snippet of the BD. Please understand that the VI just does the initialization part, and then sits in the big loop waiting for user action. The wait in that loop is now set to 103 ms.

[GerdW]

Hi Balanceman,

the case structure around that "FP.Öffnen" method is wired to a FALSE constant. The shown "True" case will NEVER execute…

(This applies to both case structures in your image!)

From what can be seen you REALLY should cleanup and refactor the whole project!

Just to name some problems:

• Lots of (stacked!) sequence structures…
• Lots of unlabelled terminals…
• No error handling…
• One loop iterating with a Wait time of 1 hour (!) effectively prohibiting to stop the VI in a clean way…

[Balanceman]

Hi GerdW

Yes, I know that those cases set to false never execute. I did that testwise to see if it has any influence on the CPU usage. There was a post, telling that the open frontpanel method or property could perhaps cause the high CPU usage. As far as I know, code in a case set to a permanent false will not be included in the EXE. That was the plan as a test.

The stacked sequence structures were written years ago, when the flat sequence struct was not yet existing.

The error handling is done in the subVIs.

There was never a problem to quit the VI even with that long wait. The exit is done with the Quit Labview function and kills those loop immedeately (and all the others).

I appeceate your input, but it seems to me that none of these points are the root cause of the high CPU use.

I wish everybody a nice easter weekend!

[GerdW]

Hi Balanceman,

The exit is done with the Quit Labview function and kills those loop immedeately (and all the others).

Someone here in the forum once wrote "that is like using a tree to stop your car…"

The stacked sequence structures were written years ago, when the flat sequence struct was not yet existing.

But there is no need to keep that structure for even more years when all you need is provided by DATAFLOW…

(I used stacked sequences too - with LabVIEW3.1 on a computer with just a 640×480 pixel screen. When I upgraded that tool to LabVIEW7.1 (on 1024×768 screen) I got rid of stacked sequences!)

The error handling is done in the subVIs.

But not in the shown (main) VI block diagram…

it seems to me that none of these points are the root cause of the high CPU use.

Yes, I agree. But you don't show the full code (like many parts being hidden in stacked sequences)…

One more "feature":

It seems you really delete the label of some controls as there is also an unlabelled property node: you really should not do that!