網頁與LV的搭配問題

8flXb8RoiRQE · 2008年10月22日06:14

請問各位，我將一隻程式放在公司網頁的某個地方，但是我的程式要如何知道使用者按下了網頁的哪個按鈕呢?

舉個例，辟如網頁上有"人事公告"、"製造公告"、"品質會議紀議"等，當使用者點選任一個選項時，會連結到我的程式，但因為我的程式須判斷使用者是按了這三個當中的哪一個按鍵，才能做相對應的執行;所以我該如何得知這個網頁上的三個按鈕是哪一個被觸發了呢?(網頁是用PHP寫的)...

Benjamin · 2008年10月22日14:49

這張圖有提到一個「terminal inputs(optional)」看來是傳入參數的東西。應該有符合您的需要。但是因為我沒有真正使用過，所以只好請你自己研究一下了。

原文網址是：http://zone.ni.com/devzone/cda/tut/p/id/7350

Web Services in LabVIEW

1 評分 | 5.00 之 5

![|18x13](upload://6uZaAvnInudwHU2IbijTgHKJrK9.gif) 列印

概觀

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.

Advantages of LabVIEW Web Services

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:

Communicate with embedded LabVIEW applications from any Web-enabled device
Establish machine-to-machine communication using standard HTTP protocols
Remotely monitor and control LabVIEW applications using custom thin clients
Stream any standard MIME data types, such as text, images, and videos
Deploy Web service VIs on a Windows or LabVIEW Real-Time target

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.

What Is a Web Service?

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:

Server – An application responsible for parsing a request, executing the appropriate method or action, and sending a response to the client
Client – An application that sends a request to the server and waits to receive a response, which is then interpreted by the client
Standard protocols – Web-based protocols such as HTTP route data over physical networks from the client to the appropriate server method and then back to the client
Network – The physical layer, such as Ethernet or IEEE 802.11, over which data is transmitted

With the new LabVIEW Web server, you can deploy VIs as Web services, which you invoke via a request from a client using standard HTTP. Unlike options such as LabVIEW remote panels and shared variables, the clients you build to communicate with a deployed VI do not require the LabVIEW run-time engine, which means you can use any Web-based client technology, including common languages such as HTML, JavaScript, and Adobe Flash.

Request/Response Model

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 Service Layers

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.

LabVIEW Web Server

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.

Architecting Web Services

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.

Sending Data from Web Service VIs

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:

Data streaming
Server-side scripting (ESP)
User sessions (cookies)

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.

Deploying Your VI as a Web Service

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.

Communication Methods

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.

Designing Web-Based User Interfaces

There are numerous ways to develop a Web user interface that displays content in a visually appealing manner. Since the early days of the Internet, Web pages have relied predominately on HTML and JavaScript, which remain widely used and ideal for simple layouts, user input forms, and static content. They require minimal overhead, which means that they can be served up easily and quickly over today’s high-speed Web.

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.

Example Application

Download an example project containing a thin-client interface developed in Adobe Flex here.

Summary

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.