Control Instruments with a Web Browser
You can set up your "Web-enabled" instruments and PCs to be controlled over a LAN, a WAN, or the Internet. Just expect to work with your network administrator.
Martin Rowe, Senior Technical Editor -- Test & Measurement World, 9/1/2000
| A version of this article appeared in the December-January 2001 issue of Test & Measurement Europe. Download the pdf. |
When embedded Web servers first appeared on the market a few years ago, it seemed clear that the technology would soon find its way into test equipment. Now, you have several options for controlling test instruments over a network.
It’s fairly common to use PCs with Web servers to control traditional test instruments over a network. Many instruments come equipped with an Ethernet port, but you need to write an application program that sends commands to the instruments from a remote PC and retrieves test results. That’s similar to controlling an instrument over a local port such as a serial or IEEE 488 port, since the instrument-control application software resides in the PC.
Some instrument makers have gone a step further by embedding Web servers into their instruments (see “Manufacturers of Web-Enabled Test Products,”). You can use these “Web-enabled” test products on a LAN or on the Internet without needing to write software and without needing a PC to host the Web server.
There are three ways to provide access to a Web-enabled instrument or test system. Your choice will depend on the type of access you need:
• connect the test equipment to your company LAN for use behind the company firewall;
• connect equipment to the company LAN with private, remote access from outside the firewall; or
• connect equipment to the Internet for public use.
| Learn to control your instruments without a Web server |
Within the Firewall
Many Web-enabled test applications simply require instrument access from within a LAN—behind a firewall. The method for connecting a piece of equipment to a LAN depends both on the network configuration and on the instrument itself. To learn some of the steps involved, I decided to connect a WebDAQ/100 from Capital Equipment Corp. (CEC, Billerica, MA, www.cec488.com) to the company LAN at Test & Measurement World. I chose the WebDAQ because it has a built-in Web server that creates and sends HTML documents over a network.
I could have used a traditional instrument, such as a DMM, but that would have involved configuring the instrument using an IEEE 488 port on a spare PC and setting up the PC as a Web server. Then, I would have had to write my own application software to “serve” information from the DMM to the network.
At T&MW, we know instruments and measurements, but computer networks fall outside our expertise. So, I solicited help from our information technology department. With help from Bob Pollard, support engineer at Cahners Business Information (T&MW’s parent company), and from the folks at CEC, I was able to connect the WebDAQ to the network and begin operating it in about 30 minutes.
Every computer or instrument connected to a network needs an address. Most LANs use Internet protocol (IP), so my test equipment needed an IP address. I wanted to use the WebDAQ box in a spare T&MW office, and doing so required me to obtain an unused IP address. I first needed to find the IP address of the network hub that served the empty office. Because the unused office and my office were connected to the same network hub, I could use my PC to find the hub’s IP address. (In many companies, all the PCs in a department may connect to the same network hub, but check with your network administrator.)
If your office PC isn’t on the same hub as your test equipment, your network administrator can connect a PC to the network drop where you want to connect your instrument to find that hub’s IP address.
|
|
| Figure 1. Windows’ winipcfg.exe program shows you a PC’s network settings. |
|
|
| Figure 2. After entering the required network information, I configured a remote instrument over the company LAN. |
|
|
| Figure 3. In path 1, the WebDAQ sends bootp packets over the network. In path 2, a PC responds with the instrument’s IP address. |
|
|
| Figure 4. After wiring each analog output to two analog inputs, I was able to set voltages and read them with my browser. |
To find the hub’s IP address, I ran a program called winipcfg.exe (included in Microsoft Windows since version 3.11). Figure 1 shows the information I obtained from my PC. My hub used IP addresses beginning with 10.35.12.
Once you find the hub’s address, you’ll need to decide whether your computer or instrument needs a reserved address. Most networks use a dynamic host configuration protocol (DHCP) server that dynamically assigns the next available IP address to your PC or instrument whenever you log in. So, if you are connecting a PC or instrument that supports DHCP to the network, you probably won’t need to ask the network administrator to reserve an IP address for you.
I did need a reserved address, because the WebDAQ doesn’t support DHCP. Instead, it uses the bootstrap protocol (bootp), a predecessor of DHCP.2 The instrument broadcasts packets that contain a unique ID number to the network. Every instrument with a network interface and every network interface card produced contains a unique ID. In my case, Pollard found that address 10.35.12.24 was unused, and he reserved it for me.
Next, I needed a way to assign the IP address to the WebDAQ box. I had two methods. One was to use the WebDAQ’s serial port and connect it to a local PC running CEC’s configuration software. I had a PC available next to the WebDAQ, but I wanted to use my other option—configure the WebDAQ box over the LAN.
After logging my office PC into the network, I installed CEC’s WebDAQ network configuration software, which supports bootp. I entered the information shown in Figure 2 into the software. Note that I had to enter the default gateway and subnet mask addresses I obtained from winipcfg. (Read “Connect Instruments to the Corporate Network,”1 for explanations of these and other networking terms.) When the PC received the broadcast packets from the WebDAQ, it identified the instrument and returned the configuration data, assigning the reserved IP address 10.35.12.24 to the instrument. Now, the network knew which network drop contained the instrument and could direct IP packets to and from the WebDAQ box.
Figure 3 shows the hub that sits between my office PC and the WebDAQ box. That hub passed the outgoing bootp packets from the WebDAQ box to all of the computers connected to that hub. But without checking the hub’s configuration settings, Pollard wasn’t sure if the hub could pass those packets to other network components—hubs and switches. If it couldn’t, he would have had to configure the hub to pass the bootp packets to the rest of the network. Therefore, ask your network administrator what’s required to pass packets between your network’s drops.
With the WebDAQ box configured, I was ready to read its measurements from any PC within the company network. Figure 4 shows the screen I saw when I entered 10.35.12.24 into my browser’s URL.
Get Out of the Office
So far, I’ve assumed that you need to connect your instruments to a LAN for internal use only. But what if you need access to the instrument’s measurements when you’re outside the office? If your company has dial-up access to its LAN, then you can dial in and type the IP address of the instrument or PC and get data as though you’re in the office.
Dial-up access is easy, but slow. If you have full-time, high-speed Internet access through a cable modem or digital subscriber line (DSL) modem, then you may be able to connect to your corporate network through your Internet service provider (ISP). To make the connection, you need a virtual private network (VPN). A VPN server is a box that’s connected to your company network, which gives you access to the network from outside the firewall.
Ask your network administrator if your network has VPN capability. If it does, then he or she can supply you with VPN software for your home PC. Then, your network will let you “tunnel” through the firewall, giving you access to mail, network drives, and test equipment.
Even if your network administrator allows you to access your test equipment from outside the firewall, he or she may resist any requests to connect instruments to the Internet for public access. In Figure 5, you see that I placed the WebDAQ box behind a firewall. To give the box Internet access, I’d have to place it between the firewall and the router that separates T&MW’s network from the Internet. The instrument would have to reside at the same level as T&MW’s Web server, FTP server, and domain name system (DNS) server.
Network administrators can be reluctant to place test equipment in the perimeter network, fearing that it could compromise network security. My administrator explained that if I wanted to connect the WebDAQ box in the perimeter network—affectionately known in networking circles as the “demilitarized zone”—I would have to physically place the instrument behind a locked door in the same room as the router and other servers that have Internet access. Once the instrument was in the locked room, I would no longer have access to it—a setup that wouldn’t be acceptable in a real test application. Therefore, if you need to place test equipment on the Internet and still have access to it, prepare your arguments carefully before approaching your network administrator.
Figure 5. To provide access to test equipment from the Internet, you must connect your Web server outside the company firewall.
Add a Web Server
No matter where you connect your test equipment, you need to know what test results to make available. Unless you’re using a single Web-enabled instrument on a network, you’ll need a computer that both controls your instruments—plug-in cards, VXIbus systems, or rack-and stack instruments—and creates and serves HTML pages.
You have several options for creating these pages, and your choice will depend on the programming language you use. Test-development software packages such as LabView, TestPoint, and Agilent VEE either contain a Web server or have Internet toolkits that add one to the base package. If you’re using a general-purpose language such as Visual Basic, you can use Microsoft’s Personal Web Server (www.microsoft.com/windows/ie/pw) to serve Web pages. I’ll briefly describe the capabilities of the Web servers, but you should contact the respective manufacturers for more information.
When you develop your Web-enabled application, you must first decide what information you need the test-system PC to serve. For example, do you simply need to view a software front panel? Do you need to change instrument settings from your browser? Do you need to receive test results in files or in e-mails?
The Web server in Agilent VEE lets you view, but not control, a running VEE program. According to Agilent, the company decided not to give network users control of VEE programs because of security issues. Remember that when you Web-enable your test system, you give many people access to your equipment.
VEE generates an image of a user screen so a browser can display it. You have several options for viewing Web pages. You can call a VEE program’s main program or any VEE diagram or user function from a browser through a URL. You can also specify the update rate of the screen image.
| Manufacturers of Web-Enabled Test Products
Here is a sample of hardware and software test and measurement products that contain Web servers. Hardware 16700 Series Logic Analyzers 4100G Graphic Recorder Software LabView TestPoint |
Like the VEE Web server, TestPoint’s Web server also lets you view any TestPoint screen. TestPoint generates an image of the desired user panel for the Web server to send. You can specify that TestPoint serve a whole screen or just a part of a screen, such as a digital readout. When you enter a URL into your browser, you can specify which TestPoint object you want to see.
You can do more than just view user panels with TestPoint. You can write a JavaScript or VBscript program that a browser can download and run to add control buttons to your application. The script can provide a link between the client browser and the TestPoint program.
TestPoint’s Internet Toolkit also includes an FTP server and an e-mail server. You can program TestPoint to send a data file or generate an e-mail message based upon test results.
The base version of LabView includes a built-in Web server. The Web server lets you publish front panels to the Web. It also includes built-in security to limit the users that can view the image.
To create interactive Web pages in LabView, you can
• use Common Gateway Interface (CGI) tools in the LabView Internet Toolkit. CGI is a technology for creating Web pages that can accept input from the Web and respond
accordingly;
• use an ActiveX control that communicates to your LabView program using the company’s DataSocket technology to pass live measurement data over the Internet. ActiveX controls let you embed the application into Internet Explorer only.
• write a Java applet that communicates with LabView through TCP/IP. Java provides a multiplatform Web page that can run in any Web browser.
Microsoft’s Personal Web Server (PWS), which comes with Windows 98, Windows NT, and Windows 2000, lets you serve Web pages from general-purpose languages such as Visual Basic or Visual C++. If you have Windows 98, Windows NT, or Windows 2000, you can install PWS from your install disk. If you use Windows 95, you can download the PWS from Microsoft. Once you have the PWS running, your PC can serve Web pages to other computers. 3 T&MW
FOOTNOTES
1. Fuller, Bruce “Connect Instruments to the Corporate Network,” Test & Measurement World, May 2000. p. 19. www.tmworld.com/articles/2000/05_network.htm.
2. You can learn more about DHCP from kb.indiana.edu/data/adov.html and about bootp from tns.utk.edu/tech/ip/bootp-dhcp.html and from tns.utk.edu/tech/ip/rfc951.txt.
3. For more information about serving Web pages to other computers, see “Using Personal Web Server 1.0a,” Microsoft, Redmond, WA, April 1997. www.microsoft.com/TechNet/pwebsrv/Tips/etn9734.asp.
FOR FURTHER READING
Edwards, Heather, “Building an Interactive Web Page with DataSocket,” Application Note 127, National Instruments, Austin, TX, June 1999. www.ni.com/pdf/instrupd/appnotes/an127.pdf.
Helsel, Robert, Graphical Programming with HP VEE, 3rd ed., Prentice Hall PTR, Englewood Cliffs, NJ (www.phptr.com), ISBN: 0-13-096005-5, 1998.
Travis, Jeffrey, Internet Applications in LabView, Prentice Hall PTR, Upper Saddle River, NJ (www.phptr.com), ISBN: 0-13-014144-5, 2000.
You can contact Martin Rowe at mrowe@cahners.com.
| Control Without a Web Server
Although this article discusses using Web servers to send test results and control instruments, you don’t need a Web server to get remote control of the computer that’s connected to your test equipment. While researching this article, I found a program called Virtual Network Computing (VNC). Available at no cost from AT&T, VNC lets you view and control one computer’s screen from another computer. I downloaded VNC to my office computer and was able to control, over the LAN, a meter connected to another computer through an IEEE 488 port. You can download VNC at www.uk.research.att.com/vnc. Remember, though, that anyone who downloads the VNC software and knows the IP address of your test equipment will have full control of your equipment.—Martin Rowe |
