Print
PDF
The VI Server is a collection of functions introduced in LabVIEW 5.0 that allows programmatic access to LabVIEW objects and functionalities. The VI Server is superior to previous attempts at programmatic control for several reasons:
1. The VI Server provides broader programmatic access to LabVIEW functionality than was previously available, and this access continues to expand.
2. The VI Server uses a refnum-based architecture, which is more consistent with other common LabVIEW architectures such as file I/O, DAQ, and VISA.
3. The VI Server allows remote access using TCP/IP, with full control over security on the server side.
4. The VI Server allows alternate client interfaces, such as ActiveX.
1. The VI Server provides broader programmatic access to LabVIEW functionality than was previously available, and this access continues to expand.
2. The VI Server uses a refnum-based architecture, which is more consistent with other common LabVIEW architectures such as file I/O, DAQ, and VISA.
3. The VI Server allows remote access using TCP/IP, with full control over security on the server side.
4. The VI Server allows alternate client interfaces, such as ActiveX.
This document shows four examples of how the VI Server can be used:
1. Process Monitoring—Allow multiple clients to monitor a VI running on a remote machine.
2. Dynamic loading and running—Load VIs in memory programmatically and run them when necessary.
3. Splash Screen—Display an opening banner for your application while VIs load.
4. Web Posting —Print a VI panel to an HTML file and view the panel on the Internet.
2. Dynamic loading and running—Load VIs in memory programmatically and run them when necessary.
3. Splash Screen—Display an opening banner for your application while VIs load.
4. Web Posting —Print a VI panel to an HTML file and view the panel on the Internet.
LabVIEW provides two classes of objects that may be manipulated by the VI Server: the application class and the virtual instrument class. The application class refers to LabVIEW, running on either a local or a remote computer. The virtual instrument class refers to either local or remote VIs. You can currently access objects in both of these classes by using ActiveX or LabVIEW block diagram functions.
1. ActiveX—On 32-bit Windows operating systems, you have access to both classes from ActiveX client applications such as Microsoft Visual Basic.
2. LabVIEW block diagram functions—You have access to both classes, regardless of operating system, using block diagram functions. LabVIEW uses its own TCP/IP protocol for network communication.
This document discusses only the second method, although the techniques may be extended to applications using ActiveX.
Each class of objects, application and virtual instrument, exposes properties and methods.
Each class of objects, application and virtual instrument, exposes properties and methods.
A property is some characteristic of the object that may be either read, written, or both, depending on the property. An example of a virtual instrument class property is VI Type. VI Type informs you whether the VI is a standard VI, a global variable VI, or a custom control VI. An example of an application class property is OS Name. OS Name is useful if you need to programmatically determine the operating system on which LabVIEW is running.
A method is an action that is performed on an object. For example, the Run VI method is available for the virtual instrument class. Run VI is used to programmatically run a VI in the same way as manually pressing the run button. Some methods have associated parameters that may be optional or required. The Run VI method provides an optional parameter that specifies whether the VI runs synchronously or asynchronously.
Figure 1a shows the sequence of VI server operations. The corresponding block diagram functions used to perform these operations are shown in Figure 1b.
Figure 1a: Typical VI Server Sequence
Figure 1b: Block Diagram of Typical VI Server Sequence
These functions are found in the Application Control palette.
The Open Application Reference and Open VI Reference functions, shown in Figure 1b, create refnums to the LabVIEW application or to a particular VI, respectively. The refnum is passed to Property Nodes and Invoke Nodes, which are responsible for retrieving or setting properties, and invoking methods on the objects that the refnums represent. Although only one of each node is shown here, the number of these nodes is not limited. You can use the Close Application or VI Reference function to close the reference and release its associated resources.
Figure 2 shows an example of retrieving property values. This example reads the Application:Kind property to determine whether you are running in the development system or in an executable.
Figure 2: Example of retrieving properties using the Application:Kind property
The power and versatility of the VI Server can best be demonstrated by showing four different examples of how the VI Server block diagram functions might be used. A simple application of the VI Server is process monitoring. Typically our application would include one computer acting as a server and performing the actual I/O operation. An arbitrary number of other computers act as clients that retrieve information from the server. The server might be a computer in the field that is in continuous operation, while the client might be a computer at an office.
Figure 3: Process Monitor Example (Server VI)
Figure 3 shows the front panel of a VI monitoring temperature on one channel. This is the server side VI, which we call AcquireTemp.vi. There are controls for the DAQ device number, channel, and scan rate. Here we have configured a channel called Temp1 using the DAQ Channel Wizard. We have a thermometer indicator that displays the temperature. This VI runs on the computer with the DAQ hardware.
Figure 4 below shows the block diagram of this VI. We use the AI Read One Scan VI to configure the hardware on the first iteration of the while loop and read one scan from the DAQ device on each subsequent iteration. Note that the loop is software-timed.
Figure 4: Process Monitor block diagram (Server VI)
In some situations we would like to monitor the temperature from another location. In this case, we want a simple client interface that displays the temperature and perhaps varies the scan rate. Figure 5 shows the front panel of this client VI, which we call ProcMonitor.vi.
Figure 5: Process Monitor Example (Client VI)
We also provide a control that specifies the network name of the server computer. In this case, the stop button stops only the client VI, but we can also program the VI to stop the server VI.
Figure 6 illustrates the block diagram of ProcMonitor.vi, the client VI. The first thing we must do is open references to both the server side LabVIEW and AcquireTemp.vi using the Open Application Reference and Open VI Reference functions. Several operations take place in the while loop. The while loop is timed using the client side scan rate. The default value of this scan rate should match that of the server side so that one VI is not looping faster than the other. During each iteration of the while loop, we use the Get Control Value method on our VI reference to retrieve the value of the indicator labeled Temperature Data (Server) on the server. Recall that this is the name of the thermometer indicator on the server. Control values are passed as flat binary strings, so we use the Unflatten from String function to convert the data to a single-precision floating-point value. We then pass this value to the Temperature Data (Client) indicator, which is the client's thermometer indicator.
We also monitor the client's desired scan rate. If it changes, we invoke the Set Control Value method in order to change the value of the control labeled Scan Rate (Server) on the server. In effect, this changes the acquisition rate on the server. We use the Flatten to String function to pass our scan rate into the parameters of the Invoke Node.
When the user on the client-side presses the Stop Button, we stop the while loop and close the open references to the VI and the server's LabVIEW. At this point, we could also stop the server VI using the Abort VI method or other programmatic method (preferred). A nice feature of this VI is that it can be used on more than one client, so multiple users can monitor the process simultaneously.
The server machine controls access from outside clients. In many cases, you will want to restrict which clients may access your VIs, and also the types of actions they are permitted. Three dialogs in the Edit»Preferences menu are used to control access to the server. These dialogs are:Server: Configuration, Server: TCP/IP Access, and Server: Exported VIs. Using these dialogs, you may configure your server to allow specific users access to your VIs, and you may control the types of access they have. The G Programming Reference Manual contains more information on these preference dialogs.
Reader Comments | Submit a comment »
'via Blog this'
This example is completely useless and mostly false. It does not work in a Run Time environment.
- Randall Dannemann,Axometrics. randall.dannemann@gmail.com - May 25, 2012
This kind og programming style is criticised in "Programmatically Controlling LabVIEW"
- Nov 17, 2003