Developing Remote Front Panel LabVIEW Applications

To reduce the amount of data sent, eliminate unnecessary aspects of your application. Use the Remote Panel Connection Manager to manage remote front panels. In LabVIEW, select Tools»Remote Panel Connection Manager to open this tool. You can use the Remote Panel Connection Manager to perform a variety of tasks including viewing how many computers are connected to the Web Server, tracking how much data is transferred across each connection, and displaying whether the connection is viewing or controlling the VI. Use this tool to see how your bandwidth requirements change as you change your VI. For example, if you have a temperature monitoring application, and you publish the current temperature to only one client with a thermometer indicator, your application requires only 1 or 2 kbytes/s of bandwidth (Figure 1). If you use a graph that displays 1000 points at a time on the front panel, the required bandwidth grows to more than 8 kbytes/s (Figure 2). The waveform graph requires more data to be sent from the server to each client than a simple digital control. Therefore, it is more efficient to publish a single-point indicator instead of a multiple-point indicator such as a waveform graph, unless your application requires 1000 data points to be displayed simultaneously.

 
Figure 1. Bandwidth Required to Serve a VI Using Digital Controls Connected to One Subscriber


 
Figure 2. Bandwidth Required to Serve a VI Using a Waveform Graph Control Connected to One Subscriber

Another way you can reduce the bandwidth required by your application is to reduce the update rate of your data. If you add a 1 s delay to the VI, the required bandwidth drops from the 1 or 2 kbytes/s seen in Figure 1 to 60 bytes/s (Figure 3). Reducing the update rate of front panel objects reduces the total bandwidth required by your application.

Figure 3. Bandwidth Required to Serve the VI in Figure 1 to One Subscriber with a Reduced Update Rate

Before the introduction of remote front panels, you could control a LabVIEW application in other ways. For example, you could use VI Server to control VIs on another computer. This control is made possible through a server/client architecture similar to the one used by remote front panels -- the client requests action from the server, and the server responds to the request. Many aspects of LabVIEW use this architecture, including Property Nodes and events. Each instance of a Property Node or event requires a round trip between the server and client. One trip is from the client to server requesting the property or event, and the other trip is from the server to the client sending the result of the request.

Because of the nature of Property Nodes and events, using several Property Nodes or events in your VI results in several messages sent between the client and server. If you control a VI containing several Property Nodes or events remotely, the message queue on the server side runs the risk of overflowing. When the message buffer fills, the remote front panel server disconnects all clients connected to it, and you can lose control of your application. Therefore, you should keep your application simple and use Property Nodes or events sparingly -- only when necessary -- to reduce the bandwidth required for your application.

It is important to note that not all standard application features translate well into distributed applications. Application features that are localized to the computer on which they run are the biggest potential pitfalls, because they are computer specific, and do not transmit on the Web. Two good examples of localized application features are ActiveX and system dialog boxes.

ActiveX is a powerful, useful communication and control technology. Any Web browser can download and execute ActiveX controls, after which they have full control of the Windows operating system. This full control yields great functionality but also presents a considerable security risk. To control this risk, Microsoft developed a registration system so browsers can identify and authenticate an ActiveX control before downloading it. After the browser downloads it, you must register the control on the local system before you can run it. While it is not necessarily a problem to register an ActiveX control on a single computer, it can be difficult to ensure that the control is validated and registered by every computer that might view your application on the Web.

Another common component of most applications is a system dialog box. System dialog boxes are a good way to notify a user of a problem, communicate important results, or solicit input from the user. The Simple Error Handler VI even makes use of the system dialog box to manage errors. System dialog boxes are great tools, but they do not work well with distributed applications. The system dialog box remains on the local computer instead of being distributed with the application. In the following example, the VI is simple. It uses an Event structure to monitor the status of a Boolean control. When the user clicks a button, the VI displays a one-button system dialog box with the message Button Pressed.

 
Figure 4. Front Panel and Block Diagram of a Simple VI Calling a System Dialog Box

If you distribute this VI remotely and a user on the Web clicks the button, a dialog box appears on the host computer only. Because that dialog box is a local system box, it does not appear to the user on the Web, but it prevents anyone from using the VI until it is closed. So the user on the Web cannot use the VI but is unaware that the problem is the open dialog box. Because of the localized nature of ActiveX and system dialog boxes, you should not use these technologies in applications designed to be viewed and controlled remotely.

For remote front panels, you can accomplish the tasks of system dialog boxes without any of the drawbacks. For example, you can use a subVI for a dialog box instead of a system dialog box. Customize the Window Appearance settings in the VI Properties dialog box of the subVI to make the subVI behave identically to the system dialog box. Because the subVI is part of the LabVIEW application, the Web Server can serve it to remote clients (Figure 5).

 
Figure 5. Displaying a SubVI Dialog Box Instead of a System Dialog Box

For Web applications, consider eliminating dialog boxes completely, because they can distract the user. An alternative way to present a user with information that you might display in a dialog box is to use a tab control. Design your application to run on one page of a tab control, and switch to another page when an error occurs or the user must make a decision. You can use Property Nodes to disable the other pages of the tab control until the user acknowledges the error or makes the decision (Figure 6).

 
Figure 6. Front Panel and Block Diagram of a VI Using a Tab Control to Handle Warnings

In LabVIEW 7.1 or earlier, refer to the LabVIEW User Manual (linked below) for more information about functionality not supported in viewing and controlling remote front panels. In LabVIEW 8.0 or later, refer to the Functionality Not Supported in Viewing and Controlling Remote Front Panels topic in the LabVIEW Help (linked below).

Besides bandwidth considerations, publishing a front panel on the Web presents some security concerns. If a VI is in edit mode, you cannot view it remotely. Therefore, you cannot modify a VI on the Web. However, anyone who requests control can control the VI. While the VI cannot be modified or damaged, the systems with which it interacts might be affected. To prevent a user from gaining control of a VI, click the lower left corner of the front panel and select Lock Control from the shortcut menu. This option prevents a viewer from requesting control of the VI on the Web until you unlock it. Similarly, you can regain control of a VI from any Web client.

To configure more Web Server security options, select Tools»Options, select Web Server: Configuration from the top pull-down menu, and enter the Root Directory. After you enter a root directory, Web clients have access only to files in that directory and its subdirectories. All other files on your computer are not accessible on the Web. Select Web Server: Browser Access to grant or deny viewing and/or controlling access to different IP addresses, so only known clients can view or run your application. Select Web Server: Visible VIs for control over which VIs in your Web Server directory are visible to a client, and to limit the time that a client can maintain control of a VI. Refer to the LabVIEW Help, which you can access by selecting Help»VI, Function, & How-To Help, for more information about configuring the Web Server.

Alternatively, you can program security into the VI itself. For example, you can require a user to log in when the VI first runs, and disable all other aspects of the VI until you verify the login. To do so, place a login field on one page of a tab control, the other controls on subsequent pages, and enable the other pages after the user successfully logs in.
Related Links:
Find Related Knowledge Bases: Remote Front Panels
LabVIEW User Manual
LabVIEW Help: Functionality Not Supported in Viewing and Controlling Remote Front Panels