How do remote panels work, and what are their limitations?

[MarkCG]

Hi all,

I've been putting remote panels to use recently as user interfaces for control applications running on real-time targets.

Some here have said that remote panels should not really be used for anything other than diagnostic type programs, and that large panels with many controls and indicators is asking for trouble.

Rather the better way is to run a GUI executable on your laptop /desktop and control the remote application via shared variables/ tcp-messaging schemes / network streams.

You need the LV runtime engine to use remote panels. Does host / remote unit send a copy of the front panel to client/web browser upon connecting, then use the run time engine to detect button clicks and send the new control values to the host when changed? And, like wise, update the client front panel image every time an indicator changes?

It seems like that's not too inefficient a scheme. So I'm curious exactly in what way can remote can go wrong. What gains would there be front writing a GUI VI to live on your desktop and send messages via a simple tcp/ip scheme or shared vars whenever a button is pressed to the host, and listen for host indicator changes.

I'm not exactly sure exactly how much gain you get from all that work, and how it's any different from a remote panel. Unless you have lots of data to stream back and need to use network streams,, or want to share data across the whole network, and need to use shared vars.

Seems to me a remote panel is exactly what you need for point-to-point, low update rate, remote user interface, So am I fooling myself here?

Edited February 10, 2012 by Sergeant Manners

[ned]

There are a number of features that don't work properly over a remote front panel. For simple display that's not a major issue, but it becomes a challenge if you want a fully-featured, responsive user interface. Some examples: RT targets don't support events on front panel controls, so all controls need to be polled; property nodes don't update when no front panel is connected; no way to implement a pop-up message box (for errors, confirmation before taking an action, etc). If remote front panels work for you, use them. If your application later grows, you may find that you need more control over the interface and more separation from the logic running on the RT system.