Creating a Windows NT Service Using LabVIEW

Sometimes you need to have an application automatically start when a computer boots up and then continue running until the computer is shut down. You can have an application automatically start whenever a user logs in by placing a link to the application in the StartUp folder of the Windows Start menu. However, using the StartUp folder has the following limitations:

• The application does not run until someone logs in.
• The application stops when the person logs out.
• The application does not start when the computer is rebooted until someone logs in.

A Windows NT service has none of these limitations. A Windows NT service is an application managed by the operating system instead of the user. You can create a Windows NT service that automatically starts an application when the computer boots, even before anyone logs in, and keeps the application running until the computer shuts down. A service runs in the background unattended and does not disrupt user work. A user who is logged in on the computer does not even know that a service is active unless he or she tries to use it. Even though it runs in the background, you can interact with a service.

You can combine services with the LabVIEW VI Server to create distributed systems, which help access databases on non-Windows platforms.

Service Requirements

A service has the following requirements:

• The computer operating system must be Windows NT, Windows 2000, or Windows XP.
• The service must run without a user interface.
• The service must have the ability to communicate with another application for configuration or control. The other application can reside on the same computer as the service or on a network with the computer hosting the service.

A service typically works with a counterpart user interface application that sends commands to control the service. The companion application can open or close the service, change the mode of the service, command the service to do something, or query the status of the service. Having to work with the user interface application means the service and the interface application must be able to communicate with each other. The service and the interface application have to use a communication protocol that each understands.

A Web server is a good example of a service. The service runs in the background with no user interface. If a user wants to use the Web server, he or she opens a Web browser application to talk to the Web server. The communication between the Web server service and the Web browser is a protocol that is specifically designed for communication between Web servers and Web browsers. Some Web servers have additional administrator applications that only run on the computer running the Web server service. Communication between the administration application and the Web server service occurs by another method.

Services in LabVIEW

You can create a service in LabVIEW as long as you observe the requirements outlined in the Service Requirements section of this document.

Every application created with LabVIEW has at least one front panel which serves as the user interface. Having a front panel seems to pose a problem since the service must run without a user interface. However, the tool used to turn the application into a service eliminates the front panel. When you create your service, do not put any controls on the front panel. You do not need a Start button because the VI starts by itself when your built application runs. However, because there is no Quit button to gracefully shut down your service, the service is halted right in the middle of what it is doing. This is similar to clicking the Abort button in the toolbar of a VI and is something you should keep in mind when designing your service.

You can use any of the following LabVIEW-supported protocols to communicate between the service and a client application:

• TCP/IP
• DataSocket
• VI Server

The VI Server protocol is easy to implement in both the service and the client application. Because of its ease of implementation, the VI Server protocol is the recommended protocol when creating a service in LabVIEW. Refer to the Example Service section of this document for more information about using VI Server to create a service.

Creating the Service

srvany.exe is a program that turns a standard Windows application into an NT service. This application is part of the Microsoft NT Resource Kit. You can download the Microsoft NT Resource Kit from ftp://ftp.microsoft.com/bussys/winnt/winnt-public/reskit/nt35/i386/i386.exe and install it to get srvany.exe. To decompress this file to srvany.exe, use expand from the command prompt. After you use LabVIEW to build an application, use srvany.exe to turn the application into a Windows NT service.

Example Service

For this example, you want everyone in your work group to see a nice, happy message whenever they log in on their machines in the morning. Furthermore, you want that message to change randomly so users don't always get the same message. You want to be able to change the messages as you wish without having to update software on each machine every time you make a change. You can make a service that resides on a central computer and provides the messages. You also can make a client that resides on each computer in the work group. The client asks the service for a message each time the client runs.

The Server-Side Application

First, create a VI that generates the message. In this case, you only need one VI because it performs a simple task. Each time you execute the VI, it reads a file named cookiefile.txt and picks a random line to return in the indicator. Figure 1 shows the block diagram for the GetCookie VI.
The GetCookie VI must be made available in the service. To create the service VI, make a VI with an empty front panel and a block diagram. The block diagram, shown in Figure 2, has the following purposes only:

• It contains a loop so that it runs until the service is halted.
• It loads into memory all of the VIs you are exposing from the service. The easiest way to do this is to place those VIs on the diagram as subVIs but put them inside a Case Structure that is never executed.
  

The following illustration shows the block diagram for the CookieServerService VI.

Figure 2: CookieServerService Block Diagram



Now that you have finished the code for your service VI, build it into an application by using the Build Application or Shared Library (DLL) dialog box in LabVIEW. Select Tools»Build Application or Shared Library (DLL) to open the Build Application or Shared Library (DLL) dialog box, shown in Figures 3 and 4.

Now that you have built your application, you need to configure it so the VI Server interface is activated. Run the application once and quit it. The application creates an empty file with an .ini extension in the same directory as the application. For this example, it is called CookieService.ini. Open the file with a text editor. Place the following lines in the file and save it:

[CookieService]
server.tcp.enabled=True
server.tcp.access="+*.ni.com;+*.natinst.com"
server.tcp.port=8363
runAsService=TRUE

The following list explains the elements of the code you entered in the .ini file.

• [CookieService] is required to set up the configuration. You set it to the same name as the application but without the extension. Since the program is called CookieService.exe, you set the line to [CookieService].
• server.tcp.enabled=True enables the TCP/IP interface of the VI Server.
• server.tcp.access="+*.ni.com;+*.natinst.com" sets the access permission for the server. The + signifies that access is allowed. In this example, all hosts that end with .ni.com or .natinst.com are allowed to connect to the VI Server. If you wish to allow everyone to connect to the service, you can change the line to server.tcp.access="+*". If you only want certain computers to access the server, you can put specific computer names on that line. You can experiment with this by setting the VI Server access permissions in your version of LabVIEW and then looking in the LabVIEW.INI file to see how the permissions come out.
• server.tcp.port=8363 specifies the port listened to by the VI Server for this application. The default port is 3363. However, you cannot have two applications listening on the same port. In this example, port 3363 is assumed to be already in use by another application. So, the VI Server for the cookie service is set to use a different port number. Because all port numbers below 8000 are reserved, you should choose a port number greater than 8000. 8363 is just an arbitrary number. You can use any port you want as long as the port is not already used by another application on your computer.
• runAsService=TRUE tells the LabVIEW Run-Time Engine to ignore the Windows WM_ENDSESSION message that is sent when a user logs off.

  Creating the Client
  

Now that your application exists, you can create the client application. The client application is responsible for connecting to the server and calling the GetCookie VI to get the selected message. Use the VI Server functions located on the Functions»Application Control palette and the Simple Error Handler VI located on the Functions»Time & Dialog palette to enable the client application to perform the following communication tasks:

• Open a connection to the server
• Open a reference to the VI being called, which is the GetCookie VI for this example
• Call the VI and get the result, or message for this example
• Close the VI reference
• Close the server reference

Figure 5 shows the completed block diagram for the client application, the GetCookieClient VI.


Now that the client exists, you can test it. Complete the following steps to test the client application.

1. Run your CookieService.exe application. The front panel appears because you have not actually changed the application into a service, yet.
2. Create the cookiefile.txt file in the same directory as the CookieService.exe file. Add a few lines of message text to the file and save it.
3. Run the GetCookieClient VI a few times. It displays a random text line from cookiefile.txt each time you run it.
4. Quit the CookieService.exe application by closing the front panel with the Close button.

If your test fails, open the CookieServerService VI in LabVIEW and set a breakpoint inside the GetCookie VI. This lets you step through the VI and see what is happening. If you step through the VI, delete the mysever.natinst.com and 8363 constants from the GetCookieClient block diagram to properly make the connection to the CookieServerService VI.

Turning the Application into a Service

Complete the following steps to turn the application into a service.

1. Copy the files instsrv.exe and srvany.exe from the Windows NT Resource Kit into the same folder as CookieService.exe.
2. Open a command prompt and navigate to the directory containing CookieService.exe.
3. Type the command INSTSRV CookieService c:\<path>\srvany.exe. Replace <path> with the full path to the srvany.exe application.This creates a new service called CookieService and links it to the srvany.exe application.
4. Select Start»Run to start the application regedit.
5. Navigate to the key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CookieService.
6. Right click the CookieService entry and select New»Key.
7. Set the key name to Parameters.
8. Right click the Parameters folder and select New»String from the shortcut menu.
9. Type the name Application.
10. Double click the Application string to open the Editing dialog box.
11. Type the full path to the CookieService.exe application and click OK.

Now that the service is configured, you can start it. You can start the service in the following ways:

• Use the Services control panel in the Control Panel area of Windows NT or the Control Panel»Adminstrative Tools area of Windows 2000.
• Open a command prompt and type net start CookieService.
• Reboot the computer.

Once the service is started, you can see it in the NT Task Manager. You see one entry in the Processes tab for srvany.exe and another for CookieService.exe.

To stop the service, either use the Services control panel or open a command prompt and type net stop CookieService.

To verify that your service actually works, run the GetCookieClient VI a few times. It should work in the same manner as your test in the Creating the Client section of this document.

Load the GetCookieClient VI on another computer with LabVIEW and test it from that computer. It should work just fine because you are using the VI Server protocol which allows inter-computer communication. You can even do it from another platform, such as Mac or Linux. To verify that the service is working properly, log out from your server machine and run the VI again on your other client machine. It should still succeed.

Congratulations, you now have a robust system service.

Conclusion and References

Service technology is fairly general and can be used in numerous places. One of the most helpful uses is to have LabVIEW applications on Mac or Unix access commercial databases. You can create a Windows NT service using LabVIEW and the LabVIEW Database Connectivity Toolset to access an Oracle or Microsoft SQL database. You expose a VI Server interface through the Windows NT service. Then, any Mac or Unix machine can run VIs that communicate with the Windows NT service using the VI Server communication protocol.

Search Google for more information about srvany.exe.

See Also:
Running a LabVIEW Application as a Windows NT/2000/XP Service

Reader Comments | Submit a comment »

Include instructions for installing srvany.exe
Include instructions for installing srvany.exe, because the FTP site does not have them.
- Douglas Femec, MKS Instruments, ENI Products Group. doug_femec@mksinst.com - Mar 29, 2006