LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

run time engine 100* too slow

Win2000

I have an application that runs using at most 10% CPU time when run either under Labview or as an .exe on a computer with Labview 6.0.2 installed. However, on separate (but similar spec) computers with the run time engine installed (using the installation generated by the same build that compiled the application) the application takes 100% cpu and only runs at about 1/10th the speed. As a general issue I would be interested to know if an application is expected to run differently under the run time engine. It raises significant development issues if it does.

More specifically, I can isolate the code that is running substantially slower under the RTE to a loop writing to the value method of a property nodes (I have reasons for
not using locals/terminals, and it works fine in the development environment). I can't however recreate the problem with a simplified simulation of the same type of code, so it is beyond my resources to track the problem down. Is there anything simple I could try? Is the latest RTE available for download?

My only thought is I went through a stage of getting a few 'insane object' errors, which seemed to resolve themselves. However, if I copy and paste the entire BD to a new vi they reoccur, and I cant save the new version.

Any suggestions, short of re-wiring my code from scratch on the offchance it is a one-off problem?

Steve
0 Kudos
Message 1 of 9
(2,950 Views)
Yes, code does run a little different with the runtime engine--it will execute slightly faster...

Sorry to be the bearer of bad news, but it sure sounds like you have a corrupted VI. You will need to rebuild the VI. One thing to try is to drag pieces of the code to the new diagram and see if you can isolate where the corruption occurs. I had this problem once and it helped.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 9
(2,950 Views)
"Another Steve" wrote in message
news:506500000008000000044A0000-1021771306000@exchange.ni.com...
> Win2000
>
> I have an application that runs using at most 10% CPU time when run
> either under Labview or as an .exe on a computer with Labview 6.0.2
> installed. However, on separate (but similar spec) computers with the
> run time engine installed (using the installation generated by the
> same build that compiled the application) the application takes 100%
> cpu and only runs at about 1/10th the speed. As a general issue I
> would be interested to know if an application is expected to run
> differently under the run time engine. It raises significant
> development issues if it does.
>
> More specifically, I can isolate the code that is running
> s
ubstantially slower under the RTE to a loop writing to the value
> method of a property nodes (I have reasons for not using
> locals/terminals, and it works fine in the development environment). I
> can't however recreate the problem with a simplified simulation of the
> same type of code, so it is beyond my resources to track the problem
> down. Is there anything simple I could try? Is the latest RTE
> available for download?
>
> My only thought is I went through a stage of getting a few 'insane
> object' errors, which seemed to resolve themselves. However, if I copy
> and paste the entire BD to a new vi they reoccur, and I cant save the
> new version.
>
> Any suggestions, short of re-wiring my code from scratch on the
> offchance it is a one-off problem?

Whenever you have a loop that has a possibility of running in close to zero
time put a "wait until next ms multiple" function in it with an input value
of 100. That will prevent the loop from hogging cpu time. This is probably
not
it, but I thought I'd throw it out there.
0 Kudos
Message 3 of 9
(2,950 Views)
OK, A happy ending, but not without a bit of frustration. The insane objects could be solved by selectively cutting and pasting, and then resetting all the front panel controls (quite a substantial job for this particular vi).

This didn't solve the RTE performance problems though. What did solve it is using the latest 6.0.2 RTE windows intall from the NI FTP site.

Steve
0 Kudos
Message 4 of 9
(2,950 Views)
I hate to keep bumping my own posts but I'll put my thoughts down in case it benefits someone else.

I own a copy of Labview 6.0 which I've added the 6.0.2 patch to. The RTE installer generated by the application builder though is still only version 6.0 run time engine, not 6.0.2. Maybe the difference in RTE versions compared to the Labview versions (even though it is just a patch) is the cause of my problems? This is worth noting if it is the case.

Steve
0 Kudos
Message 5 of 9
(2,950 Views)
Hi Steve

You have to remember, that you don't need the newest RTE, but exactly the same version as the LV version you build the application.
Regards,
Luca
0 Kudos
Message 6 of 9
(2,950 Views)
This difference might not be causing the problem outright, but it could be a factor. In any case, you should be running the same version of RTE as you ae in the development system, and there is a 6.0.2 RTE. Download it from NI's site, install it per directions and rebuild your application.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 7 of 9
(2,950 Views)
The download page for the 6.0.2 RTE (windows) does in fact give instructions for replacing the 6.0 install files with the 6.0.2 ones so that the App builder will build a RTE installer with the right version number.

http://digital.ni.com/softlib.nsf/websearch/D5F11A64A905DB27862569EC005E31E2?opendocument&node=132070_US

It's also quite possible that the original 6.0.2 upgrade I did had instructions saying that the App builder needed to be upgraded separately, but I'm notoriously bad at reading all of the upgrade instructions..

Thanks for the comments.
0 Kudos
Message 8 of 9
(2,950 Views)
....

>
> More specifically, I can isolate the code that is running
> substantially slower under the RTE to a loop writing to the value
> method of a property nodes (I have reasons for not using
> locals/terminals, and it works fine in the development environment). I
> can't however recreate the problem with a simplified simulation of the
> same type of code, so it is beyond my resources to track the problem
> down. Is there anything simple I could try? Is the latest RTE
> available for download?
>


My suggestion is to look closely at the panels on the two different
computers. I suspect that different fonts are making the controls or
indicators that are being updated overlap on the slower computer. If
you will update them less often, or better yet, sprea
d them apart, it
will allow for a more efficient displays. I know that you said you want
to use the Value property, but terminals and locals have more
optimizations at this point and are typically faster.

Greg McKaskle
0 Kudos
Message 9 of 9
(2,950 Views)