Life in a global company has some big pluses and big minuses. For those who haven’t done it, international travel may seem like one of the pluses. What’s not to like? Well, a lot, actually. Trips that take 30 hours door-to-door are common. Sitting on a jetliner for 10 hours at a stretch is mind-numbing at best. Then there’s the adventure of global cuisine: Chicken feet or worse are normal in some regions and can be problematic for the typical American stomach.
Overseas travel has been an unwanted fact of life for some test engineers who are responsible for offshore production lines. Whenever things aren’t running correctly and can’t be diagnosed from afar, a visit is usually a must. The “wouldn’t it be nice” fantasy scenario has been to log in remotely and monitor the system from a PC in the office.
With LXI, “wouldn’t it be nice” becomes “what are you waiting for.” This isn’t a glorified version of remote desktop or some similar program that simply shows what’s on the screen of the overseas test system.
All LXI-compatible instruments can serve a web page, and most provide browser-based monitoring of what’s going on inside, even during program execution. At first blush, this may not seem like a technological breakthrough. However, it’s an incredibly powerful tool for troubleshooting and monitoring—and it’s accessible through a company intranet or whatever access path you have into the contract manufacturer’s test network.
When the phone rings at 3:00 a.m. because the system has stopped running, taking a quick look is a simple matter of logging in remotely. Chances are it still will require a remote desktop or remote person to control and monitor the overseas computer. With an LXI instrument-based test system, the individual instrument web pages will provide useful clues about what is or isn’t happening halfway around the world. Being able to do this while the test program is running offers a new level of insight that’s not available with architectures such as GPIB and PXI.
What could go wrong with this approach? With a little advance planning, very little. The biggest initial hurdle typically is connecting to the remote system. Usually getting connected is straightforward unless the remote site is a secure facility.
Often, you need to connect through a virtual private network (VPN). Remote workers have been doing this for years, so often it is just a matter of using the same procedure to get connected inside your company’s intranet. If the remote site is an outside vendor or contract manufacturer, you’ll need access. This could include a VPN connection or opening a port on the remote system that allows access to your computer via its specific IP address.
Once you have a connection to the remote system, make sure you test it before you need it. There’s nothing worse than troubleshooting a connection before you can start working on the test system.
Back to the remote system, if someone at the remote site has accidentally turned off an instrument, it becomes immediately obvious: The instrument’s web page won’t load. You still can pull up any pages that will load, sort out what’s happening, and describe how to fix the problem. It’s an approach that’s much easier on the travel budget—and the stomach.