Developing Remote Front Panel LabVIEW Applications

Publish Date: Dec 05, 2007 | 57 Ratings | 3.91 out of 5 |  PDF

Overview

The Web already has changed the way companies do business; they can quickly share information and communicate with their customers. They also can sell their products and visually present information in a way that never was possible before. With LabVIEW 6.0, National Instruments showed how you can use the Web to improve the way engineers design, manufacture, and test products, and to decrease design time. The effect that Web-enabled distributed applications have had on the measurement and automation industry has made implementation not merely an advantage, but a necessity for any company that wants to remain competitive.

In the realm of test and measurement, distributed applications offer numerous advantages over conventional applications. Distributed applications can harness the power of networking so you can perform different aspects of your application in the location where it is most appropriate. The platform is fundamentally the same, but the deployment capabilities of the platform are enhanced radically. By using network technologies in your measurement solutions, you can perform I/O on the production floor, deploy additional processing power for in-depth analysis in the control center, log and store postanalysis information to a corporate database, and display key information to clients around the world in a Web browser. The essential tool that you need to tie all of these pieces together is the software. LabVIEW provides a platform for designing your test system to take advantage of all the latest technologies while providing an environment that still is focused on quickly developing your application.

LabVIEW 6.1 introduces remote front panels, which you can use to view or control a VI in any Web browser. This feature greatly expands the application because an operator can run an application from anywhere. In addition, several users at different locations all can access the VI simultaneously.

When developing a distributed application for the Web, you must consider several factors involving bandwidth and network traffic. An application that will be controlled by many remote computers must be able to provide up-to-date information to all connected clients. This requirement is easy to meet if that information is simply a pass/fail status indicator, an output temperature level, or current engine speed. However, when the information required evolves into real-time charts, intensity graphs, and other data, you must have high bandwidth. These types of data require that more data must be sent on each update and that the same amount of data must be sent to all connected clients. The easiest way to distribute large amounts of data on the Web is to use a high-end server with a large amount of bandwidth at its disposal. Because these resources are not always available, it is useful to examine other ways to optimize data transfer, such as the following:
  • Reduce the amount of data sent.
  • Reduce the update rate of the data.
  • Minimize the amount of advanced communication, such as Property Nodes.

Table of Contents

  1. Reducing the Amount of Data Sent
  2. Reducing the Update Rate of the Data
  3. Minimizing the Amount of Advanced Communication
  4. Functionality to Avoid with Web Applications
  5. Security Issues

1. Reducing the Amount of Data Sent

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

Back to Top

2. Reducing the Update Rate of the Data

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

Back to Top

3. Minimizing the Amount of Advanced Communication

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.

Back to Top

4. Functionality to Avoid with Web Applications


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).

Back to Top

5. Security Issues


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

Back to Top

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit