VI's of a RT executable load to the memory?

[Daniel Faria]

Hello.

OK... I built a RT executable for my FieldPoint, deployed it, and checked that the .rtexe appeared inside "c:\ni-rt\startup". So, it seemed that everything was working fine.

My problem is that I want to visualize one of the VI's front panels (included in the executable) as a remote panel. When I go to "Operate -> Connect to Remote Panel..." and try to connect to the VI, it says: "Requested VI is not loaded into memory on the server computer". Why is that? Shouldn't all the VI's be in memory (I put included of them in the "Startup VI's" list when configuring the application).

Also, when I go to the System Manager and check "Track VI States" the main VI's that comprise the executable are not shown there... Shouldn't they be there? Is there anything wrong?

Thanks!

Daniel

[JR_A.]

It sounds like the Startup.rtexe is not actually starting up. My guess is that the problem lies with selecting "Set as startup" and deploying that setting which is different from deploying the application. Right-clicking on the build spec. and selecting deploy transfers the application to the target's file system. You also need to right-click on a Real-Time build specification and select "Set as startup" to mark that application to load and run when the system boots, but that is a target setting, not a setting of the specific build specification. The "Set as startup" setting also needs to be deployed and since it is actually a property of the target, you need to right-click on the target item (not the build specification) and deploy it. The reason it is a target setting is that you could have multiple build specifications with different settings (i.e. release vs. debug) and only one of them can be set as the startup executable.This is similar to what you would have to do if you were connected to a target and changed its Web server properties; you would need to deploy the target to send the new settings to the target. BTW, you will need to have the web server enabled and that VI marked as allowed to be able to connect to it as a remote panel.

If all goes well, you should see your VIs in the Real-Time System Manager. Otherwise, another good test is to drop in a simple loop which blinks an LED on the FP so you can visibly see if your code is running or if it started and then hit and error and stopped.

-JR A.

[Daniel Faria]

You got it, JR A.! Thank you so much!

Now I can find my "top-level" VI's on the System Manager and connect to any of them using the "Connect to Remote Panel...". However, there still are somethings that do not seem right:

1) The system seems to be extremelly slower than when it was running on the host computer. For example, when I open the System Manager and click on "Track VI States" the tool becomes so slow that the memory and the cpu usage trends practically stop updating... (although the update interval is set to 1 second, it seems to update only at each minute!) Is that really expected depending on the complexity of my VI's? The strange part is that the memory usage shown is only around 50% and the CPU usage is pretty much the same as when there is nothing running (around 90% maybe). I included a screen shot of that so that you can easily evaluate if I should expect such a slow operation...

2) When I open one of the VIs' front panel and try to do anything (like clicking on a button or change a switch position), it does not respond. Can't I control the VI's operation by these remote panels? If not, how can I do it then?

Thanks again for your great help!

Daniel

[JR_A.]

System response slowing down when code is running on the target would be expected behavior. It should be about the same as if you connected to the target and then deployed the VI and ran it from the LabVIEW development environment. If you are running a code at priority higher than normal, such as a time-critical VI or Timed Loops, that would increase the effect since the network communication is going to be at normal priority. CPU usage usually shows this but it's more difficult to see with FieldPoint since high CPU usage is expected due to background processes, see KB 378FPGPK.

For #2, it sounds like you need to right-click and request control on the VI. Check out Controlling an Application or Front Panel Remotely Using LabVIEW.

-JR A.