Virtual Attendance in Real Engineering Labs

Jim Henry

College of Engineering and Computer Science

University of Tennessee at Chattanooga

Chattanooga, TN, 37403 USA

Key Words: Engineering education, laboratories, remote operation

 

 

 

Abstract--Engineering laboratory equipment at UTC has been made available for users via the World Wide Web. Users can conduct systems lab experiments from remote sites, anytime day-or-night, any day of the week. This paper describes the development of these systems, the current situation and future plans.

  1. INTRODUCTION
  2. This paper describes the development of the remotely operated laboratories at UTC. The following sections describe the sequence of the developments and conclude with some observations. The web address (URL) for the lab is http://chem.engr.utc.edu

  3. BACKGROUND

In the early 1990's at UTC, we had developed five laboratory stations for controls systems experiments. These were developed for teaching laboratories for undergraduate engineering. The stations consisted of computerized control and data acquisition connected to a variety of simple, SISO, engineering systems.

The computers consisted of a variety of models of Macintosh computers and the software was National Instrument's LabVIEW. Students operated the equipment through a computer's graphical interface. The software collected the data and saved it on a disk. Subsequently the students analyzed the data with Microsoft Excel.

By 1995, all the computers were networked with Ethernet and had Internet (IP) addresses. In this environment, we began to think of ways that these computers could execute the experiments by receiving directions from remote computers.

The development along these lines is described below. Technical details are given elsewhere [1-2].

  1. Hardware Stations

Initially, there were 5 stations for controls systems experiments:

These are all basically single-input, single output systems. All are inherently stable systems when run in open-loop configuration; that is, if you specify a fixed input value, the system will reach a constant steady-state condition. More complete descriptions of these have been given elsewhere [3-4].

  1. Software
  2. Student operators operated the systems, using LabVIEW software on desktop computers at each station. The software operated the equipment under the conditions of parameters chosen by the student operators.

  3. Experimental procedure

The students ran experiments in real time, watching the systems as they ran. Basically, a student "designs an experiment" by making certain decisions:

At the end of the experiment, the control software wrote the data on the computer's hard drive. Fig. 1 on the next page depicts the connections between the components for this system.

 

Figure 1. Connections for "live" experiments

 

  1. EARLY DEVELOPMENTS

  1. The concept
  2. The early thinking was for controlling batch-run experiments. The user would design an experiment, making the same decisions as listed above for "live" experiments. If this design could be coded and transferred to the laboratory controlling software, the experiment could be completed remotely. We decided to code the experiment design into a text file and transfer the file to the laboratory computer.

  3. FTP (File Transfer Protocol)
  4. One computer was a Macintosh Quadra 950. On that computer we put an FTP server, a shareware program named "FTPd." FTP (for File Transfer Protocol) enabled a user at any other networked computer with FTP capabilities to transfer a file to or from a certain folder on the hard drive of this laboratory computer.

  5. The Laboratory Response

The controlling software was modified to watch for incoming command files. It did this by periodically looking to see if a certain file was present in a certain folder. When the file showed up, the software would read the file, delete it, decode the contents, perform an experiment, collect the data and write a file in that same folder. The file contents looked something like this:

(Since at first, only one station was involved, the choice of stations was not a necessary part of the experimental design.)

After the data file was written, the user could use FTP to download the data to another computer for analysis. In 1995, I did this from home by telephoning from a home computer with a terminal emulator into the university's modem pool and connecting to an IBM mainframe. Fig. 2 below depicts the connections between the components for this system.

This system worked, but we did not ever have students use it. To say the least, it was a bit cumbersome. However, a "proof-of-concept" of remote-access laboratory experimentation had been completed at UTC.

  1. FIRST WEB INTERFACE

  1. The concept
  2. In mid-1995, we began to look into a World Wide Web interface for the system. The idea was planted by a web site that asked the user to enter parameters for a simulation of contaminant transport in ground-water flow; after clicking "Simulate" the site responded with graphs of contaminant concentration in the simulation field.

    I figured that since our control and data acquisition was nothing more that a "program" running on a computer, we could accomplish a similar function with real experiments. I found that Richard Jennings, now at Sandia Labs, had written a Web server in the LabVIEW language. We got a copy of that and used it and are still using it today.

     

    Figure 2. Connections for early remote experiments

  3. Some Internet Details
  4. It turns out that, in a sense, all information transmitted on the Internet is "text" (actually it is just ones and zeroes but it is frequently presented as ASCII text). One difference between FTP and HTTP (the Web protocol) is whether it uses port 23 (for FTP) or port 80 (for HTTP) to communicate. There are 65,535 port numbers on networked computers; the first 4,000 or so have been assigned some specific task. Above port 4000, there are no standard assignments.

    When a Web server receives a request (a "hit") it responds with a string of text in the "html" format. The browser converts that into graphics and text on the user's screen.

  5. The UTC implementation
  6. We wrote a LabVIEW program to add on to Jennings' Web Server that sent web pages back to the requesting user. Fig. 3 below depicts the connections between the components for this system.

    The browser end needed a Web page that asked for the user to enter the experimental design information. The technique for this is a Web "form." These were written to ask for all the information necessary to run an experiment. There was one page, or "form," for each experiment that a student could run. The first experimental station online was the "pressure control system."

    The first response to a Web request was (and is) a Web page that says your experiment is running (or queued to run, if another experiment is now running). On that "first response" page is a button to click on to see the final results. The results are presented graphically and the total set of data is available, also. Additional programs were added to the Jennings' Web Server to make these additional html Web pages, putting in links to the appropriate images of graphical results.

    At first, the images were built in a very roundabout way: the LabVIEW program would ask Excel to read the data, draw the graphs and save them with a specified name in a specified location. This worked for a while until we figured out how to have all that processing done in LabVIEW.

  7. Further Developments

Rather than have a Web Server running on each lab station computer, we added a lab server machine that did all the communicating with the Internet and communicated with the various lab machines via file sharing. Within a few months, additional stations were put online and additional pages were added for the various stations. Fig. 4 on the next page depicts the connections between the components for this system.

Figure 3. Connections for early Web-responding experiments

We added Speed control, Flow control and Position control within a few months. Around a year later, we added the Level control and Temperature control stations. The latter two are somewhat different because the experiments take several minutes to complete rather than several seconds. For the "slower" stations, the Web Server builds results graphs periodically during the experiment so that the student can see the progress of the experiment while it is running.

In the next few years we added some chemical engineering stations, also. We have heat exchange (actually the same equipment as the Temperature control station), packed bed absorber, flow through porous media, dehumidifier, batch drying, gas-fired water heater and pressure swing absorption. We are continuing to add stations in environmental and mechanical engineering.

In addition to operating this equipment, Web users are able to listen to the sounds of the equipment (motors and valve operators) while they operate (with live, RealAudio streaming audio) and one station (Level control) is also viewable on the Web while it operates (with live, RealVideo streaming). We have microphones at most of the stations. The microphones are fed to a mixer that goes into the audio input of a computer running the Real encoder. We now have one video camera operating. We are soon going to add additional video cameras and allow the Web user to select which station to view.

  1. "REAL TIME" INTERFACE

  1. The concept
  2. With the "slower" systems, common among the chemical engineering stations, we came to realize that they could be operated in "real time" interactively by using the fundamental communication protocol of the Internet, TCP/IP. We wrote LabVIEW programs that are "remote control" programs that have graphical user

    Figure 4. Connections for one server, multiple stations.

    interfaces just like the original "hands on" interfaces in the lab.

    In this situation, the remote user runs a LabVIEW program) which sends a very small packet of information which basically telling the system what value of the "input" signal the user wants at that instant. The user can be anywhere in the world on the Internet. The controlling program can be downloaded from our site. The "command" information is on the order of 20 to 30 characters, which is quite quickly transmitted to the lab. The lab station (listening on port 8081), operates the system with this input and returns the values of the output to the user via TCP/IP. Commonly, this round trip of information takes less than a second. Fig. 5 below depicts the connections between the components for this system.

  3. Applications

We have implemented this TCP/IP scheme on four of the slower systems to date. We will have four or more systems implemented soon. The latest version of LabVIEW (6.1) is said to make this kind of control even easier over the Web. We have not yet verified that it offers the same low-bandwidth application.

  1. OBSERVATIONS
  2. These developments have shown that real experiments can be run remotely. Over 50,000 experiments have been run with this equipment since 1995. Users have been from all over the globe. The potential for using these capabilities to help students learn and to help faculty give "learn-by-doing" assignments is now a challenge calling for our response. Some descriptions of these have been given elsewhere [5-8].

    Figure 5. Information flow for "real time" remote operation of laboratory equipment.

    One opportunity for such remotely operated experiments is that it has allowed schools with no labs to have their students complete these lab experiments. We have done this with Pitt, Tech. Univ. of Sydney (Australia) and Univ. of Cologne (Germany).

    We have been asked to help others establish labs like these. We are happy to help others and are working with Creative Engineering in Chattanooga to provide equipment and software (see http://www.RealLabs.net on the web).

     

  3. ACKNOWLEDGEMENTS
  4. The support of the Center for Excellence in Computer Applications and the College of Engineering and Computer Science at UTC is gratefully acknowledged. Additionally, at NSF supported some of this through the ILI program) grant DUE #97-51024. Others assistance is acknowledged from National Instruments Co., Microsoft, Plant Engineering Consultants, Apple Computer and Analog Devices.

     

     

     

  5. BIBLIOGRAPHY

[1] Henry, Jim, "Laboratory Teaching via the World Wide Web," ASEE Southeastern Meeting, Orlando, FL, April, 1998.

[2] Henry, Jim, "Running Laboratory Experiments via the World Wide Web," ASEE Annual Meeting, Seattle, WA, June, 1998.

[3] Henry, Jim, "Engineering Controls Systems with LabVIEW," Scientific and Engineering Applications for Macintosh, Woburn, MA, August, 1993.

[4] Henry, Jim, "LabVIEW Applications in Teaching Controls Systems Laboratories," ASEE Annual Meeting, Anaheim, CA, June, 1995.

[5] Henry, Jim, and Charles Knight, "Improving Laboratories with Internet Controlled Equipment and Internet Student Support," ASEE Southeastern Meeting, Roanoke, NC, April, 2001.

[6] Henry, Jim, "Laboratory Remote Operation: Features and Opportunities," ASEE Annual Meeting, Albuquerque, NM, June, 2001.

[8] Henry, Jim, "Web-Based Laboratories: Technical and Pedagogical Considerations," AIChE Annual Meeting, Reno, NV, 2001.

[7] Masoud Naghedolfeizi, Sanjeev Arora, Henry, Jim, "Remote Laboratory Operation: Web Technology Successes," ASEE Annual Meeting, Albuquerque, NM, June, 2001.

All these are available via Web at

http://chem.engr.utc.edu/Henry-Pub