Applications often require networking interfaces for machine-to-machine communication, remote monitoring, or remote control of an embedded device. The proliferation of the Internet and networking infrastructure simplifies the task of connecting distributed hardware over existing physical networks. NI LabVIEW software offers you a variety of options for establishing communication between software applications. This article explains LabVIEW Web services, a new option in LabVIEW 8.6 added in response to customer requests for a more open and standard way to communicate with VIs over the Web.
Consider a LabVIEW application deployed across a distributed system. LabVIEW provides features such as shared variables for establishing communication, but many developers need a way to communicate with these applications from devices that do not have LabVIEW using standard Web-based communication. With LabVIEW Web services, you can:
Figure 1. This screen is an example of a thin-client application developed using Adobe Flex, which can bind data received from a LabVIEW VI to a Web-based user interface.
Using Web services, you now can deploy LabVIEW VIs in a distributed application, such as the one described above, for communication over the Web. You can easily configure the LabVIEW Web server to receive requests from thin clients running on any Web-capable device to remotely run and control VIs. However, understand that creating a thin-client interface requires expertise in a text-based language to develop a user interface to interpret and display information.
Web services enable the invocation of a method on a remote target using standard Web-based protocols. A client sends a request to a remote server, which processes the request and replies with a response, which is then interpreted and displayed by the client application. You rely on this communication method for everyday activities such as browsing the Web, checking e-mails, and even reading this article online.
The following bullets are all components of a Web service:
To understand how communication with a Web service works, consider the experience of browsing an online store. Any time you click on a link or type in a URL, your browser (the client) is sending a request to a remote server, which processes the information and sends a response. Your browser does not need to know anything about the server’s infrastructure or the databases used by the online store; rather, it just interprets the response and displays it to the user.
Figure 2. Standard thin-client interfaces can invoke LabVIEW VIs.
When communicating with an embedded target, you may find it helpful to relate it to the experience of configuring a router. Routers provide Web client interfaces you can access to configure and set up parameters such as wireless encryption and port forwarding. These stand-alone devices host an onboard server for deploying the interface. You can use LabVIEW in the same manner on embedded devices to deploy a VI as a Web service, which can be communicated from a client such as a Web browser.
This networking method is not ideal for high-speed streaming data applications. The client needs to make a new request any time it wants updated data. Therefore, it is impossible to guarantee how fast data can be returned due to factors such as the quality of the connection, available bandwidth, and the proximity to the server location.
Web-based communication is actually composed of several protocol layers, which range from the physical layer the data is actually sent over to the layers used to encode the message and route it to the appropriate method. LabVIEW abstracts any concern regarding how these layers work, though low-level TCP and UDP VIs are available if you want to develop an application on top of the transport layer.
Figure 3. This diagram demonstrates the standard protocol layers used to communicate from a client application with a LabVIEW Web Service.
The various protocol layers used in Web-based communication are shown in Figure 3. LabVIEW Web services use a RESTful architecture on top of protocols that are ubiquitous across the Web, such as TCP/IP and HTTP, to provide standard, firewall-friendly communication. NI chose a RESTful architecture because it is particularly useful for software that requires lightweight solutions because it involves minimal additional markup.
The Web server in LabVIEW 8.6 has been replaced with a third-party Appweb HTTP Server from Embedthis Software LLC. This new Web server is now used to serve remote panels and Web services. Embedthis is a leading provider of embedded Web servers and was selected based upon its history of providing robust and lightweight solutions ideal for embedded hardware such as NI CompactRIO and Compact FieldPoint.
You can use Web services to provide a Web-based interface for communicating with existing LabVIEW applications. Note that the top-level VI of an application is not typically deployed as a Web service; rather, an additional set of VIs is responsible for communicating with the application and returning data to Web requests, as demonstrated in Figure 4. Information can easily pass between the application context and the Web server context by using shared variables or by writing data to a shared memory location, such as a TDMS file.
Figure 4. Web services can communicate with existing applications via shared variables and shared memory to pass data and configuration parameters to a remote Web interface.
There are several technologies for sending and receiving data between a client application and LabVIEW. The simplest way is to pass data through the connector pane, which yields either standard XML data or plain text. This returned information can easily be parsed by a client that can bind the data to more useful displays, such as tables and graphs. For more advanced communication, a new palette of VIs in LabVIEW 8.6 facilitates the following:
You can find detailed information on how to use these advanced methods in the Advanced Reading section below, or you can consult the Example Finder in LabVIEW 8.6.
A Web service VI must be configured, deployed, and managed from the Build Specifications section of the LabVIEW Project Explorer. Right-click on “Build Specifications” and select New»Web Service (RESTful) to get started and configure your VI.
Figure 5. Configure, build, and deploy Web service VIs from the Build Specifications menu.
The settings in the Build Specifications dialog for Web services determine how a remote user calls and interacts with the VI once it has been deployed. The following is an overview of the information and steps required to communicate with a VI that has been deployed as a Web Service.
Figure 6. HTTP directs the request to the correct server, followed by the server and the actual VI to invoke.
1. Physical location of server – HTTP uses URLs to send a request from a client to a specific server interface. The first part of the HTTP address you need to specify in this dialog is the physical location of the Web server. This is commonly specified using an IP address, or domain. If you are accessing the Web server from a client on the same computer as the server, you can type “localhost” to indicate that you intend to communicate with a server that is hosted locally.
2. Name of Web service – Because you can configure multiple services for a single LabVIEW application, the next parameter you need to send in your URL is the service name, which is specified in the dialog window shown in Figure 7.
Figure 7. The service name is specified from the Information category of the Build Specification.
3. Mapping to a VI – In the URL mappings dialog, you now can define custom routes for each service that map to VIs or folders containing static content. After selecting the VIs to run as a Web service, enter the URL extension you want to point to each VI.
Figure 8. In the URL mappings dialog, you can customize routes to specific VIs and terminal inputs.
4. Terminal inputs – Inputs can be passed to the invoked VI through the VI’s connector pane. You can map inputs from the URL to the terminal input by adding “:terminal name” at the end of a URL.
To send data to a VI, such as a terminal input, you need to determine how to pass the data. GET and POST are the most commonly used HTTP methods; however, you also have the option of PUT and DELETE using the LabVIEW Web server. GET allows data to be passed in via variables that extend the URL. POST is most commonly used for reading data from an HTML form that contains a large amount of user input.
Static content refers to any document other than a VI that you want to make available to a client communicating with the LabVIEW Web server. In most cases, static content includes a user interface designed to invoke the VI methods and interpret the response. Static content needs to be placed in a destination directory, which is linked by name in the URL mapping dialog.
Figure 9. The thin-client interface developed in Adobe Flex calls a URL to run the deployed VI, which programmatically generates and streams XML data in response.
Rich user interfaces, such as those shown in Figure 9, can be developed to provide you with dynamic graphics and an application-like feel within a Web page yet still offer lightweight solutions to minimize the amount of data sent from the server. Some of the more common languages for developing these applications include Adobe Flex, Adobe Flash, AJAX, Microsoft Silverlight, and Java applets. These all require unique expertise in the language used to write and script behaviors.
Download an example project containing a thin-client interface developed in Adobe Flex here.
New Web services in LabVIEW 8.6 address the growing need for an open and standard way to interact with LabVIEW applications over the Web. By selecting the Embedthis Web server and the lightweight RESTful protocol, NI is addressing the need for a robust Web server that you can embedded into applications running in LabVIEW Real-Time systems.
Learn more about features and changes in LabVIEW 8.5 in the LabVIEW 8.6 Web Portal.
Launch LabVIEW online to use the latest features.