10-12-2011 04:09 PM
I have a RT machine that needs to do its job and also port the front panel to an external machine over the network. What is the most efficient way to do it? Using as little of the RT time as possible but providing full functionality to the RT front panel.
So far I have been using it directly from Labview - running the VI on a remote (RT) and have the front panel on local Labview (WINDOWS). I know I can do it with also through WWW (not very happy with that though).
LV2009 SP1.
Thanks
10-12-2011 05:30 PM
The most efficient approach, in terms of RT processor use, is to write a separate host application that runs on your PC and communicates with the RT system over TCP/IP. It's up to you to determine if this is an efficient use of your time. It requires a substantial effort. You might be able to use shared variables for communication and save some time, I haven't tried that approach. If you're not willing to write your own communications, then your options are limited to the two you've mentioned - running remotely in the development environment, or running in a web browser with the NI plug-in.
10-12-2011 05:47 PM
Well , I have done that for my 2nd system that is controlled by the system I have manual control over. Unfortunately, I don't have time to do that again, and if I did nobody would appreciate it 🙂 Hence, I am looking for a less elegant yet, efficient solution. It might be just my imagination that there was a sort of LV feature only to access a remote RT front panel but I might be wrong.
If it exists or not it would be nice to know which one is the most efficient (in terms of CPU usage).
Thanks for the answer.
10-12-2011 06:32 PM
Running a compiled executable on the RT target, rather than running it within the development environment, is probably slightly more efficient but limits you to the web interface. If you're running within the LabVIEW environment, I doubt there's a noticeable difference in efficiency from the RT perspective between the web server and the LabVIEW front panel, although that's mostly a guess (I would expect the RT system to send identical data in each case, once the front panel is loaded). Those are your only options in modern LabVIEW versions. In LabVIEW 7.1 you could build an executable that acted as the front panel for an RT system, but that feature does not exist in recent versions. However, a quick search turned up this document with code to approximately duplicate that behavior, perhaps it will work for you?
10-13-2011 11:57 AM
Can someone front NI actually confirm that www is more efficient? I tried it in the past and the whole panel loads and seem to work with the controls, etc but... it does not do anything to the hardware at all. In other words the control acts like it enables an output but the output is not changed in reality. It seems like a parallel universe for some kind
10-13-2011 12:16 PM
I tried using a Remote Panel once for this same thing, but it wouldn't work for my needs. Because a FP is non-deterministic the RT controller puts it as the lowest priority. I had about a dozen items, mostly scalars and 2 arrays. Even at a 1Hz update rate this was too much info to pass and my controller would crash anywhere from immediately to 10 minutes after start.
Probably not what you want to hear, but in my limited experience with RT the only real option is a Host VI and communication. I used Shared Variables with no problem. I think they are a little less efficient than pure TCP/IP but much easier to use.
10-13-2011 03:11 PM
If that is the case, then what is the WWW panel functionality for?
10-13-2011 03:45 PM
Well, I was able to run it properly with what seems to be all the functionality (I/O DAQs etc).
Long story short, using the system manager the webserver was loading the remote host CPU at 22-25%, while when run under LV it was 19-22%.
Seems that actually, the front panel run from within LV is more efficient... No point in changing.