Paper

Paper
Session 3226
Using Automated Instrumentation and Available Software
to Provide Interactive Laboratory Instruction
to Distance Education Students on the Internet
Jason Dutcher, Baber Raza, Robert Rippy, Jang Yi, Herbert Hess
Department of Electrical Engineering
University of Idaho, Moscow, ID
Abstract
Technical aspects for developing a Remote Laboratory Data Gathering System for the
University of Idaho Electrical Power Laboratory are presented. The proposed system is a proofof-concept to support videotaped engineering extension courses, providing an interactive
laboratory setup students may control from a remote site. LabView provides the
instrumentation display and command interface. The Internet provides access and real time
display of audio and video display features. Prototype is complete and operating on the Internet.
Introduction
The University of Idaho provides off-campus students with courses on videotapes
supplemented with access to an instructor by telephone, fax, and email. These students can take
classes for a quite attractive price. Though unable to attend in person, by videotape they sit
alongside their peers on campus. Now in its twenty-third year, Engineering Video Outreach
keeps each of three studios booked for over fifty hours a week.
G P IB b o ard
S erv er
WWW
G P IB
cab le s
R em o te U ser
O -S C O P E
P -S U P P L Y
25 V
V o ltage
Iso lato r
C u rren t
A m p lifier
6 V
A C m o to r
3φ R elays
A C D riv e
Fig. 1. Block Diagram of the Proposed Remote Laboratory Experiment
Page 3.607.1
Providing laboratory instruction for such distance education students poses a difficult
problem. The appropriate equipment is usually too expensive to provide each student with a
laboratory setup. Supervision and safety remain problematic in a distance learning environment,
even if the student has the equipment. Consequently, most on-campus courses with laboratory
work drop the requirement to perform that work when serving the distance education student.
This is unfortunate because the laboratory remains the best vehicle to teach such skills as
troubleshooting and circuit assembly.
This project addresses that problem by using the World Wide Web interactively. With
equipment, software, and methods described in this paper, a distance education student may
observe a machine in operation in an on-campus lab, send commands to influence that operation,
and acquire and record data as well. Video students may now experimentally test the theories
presented in class using this system, greatly aiding their educational experience.
Project Objectives and Description
For this project, the objective is to design and build a prototype experiment, using automated,
interactive instrumentation, accessible and controllable through the Internet. In other words, this
project should enable a distance education student to have a real time, graphical interface to a
working laboratory experiment. The interface must be accessible, observable, and controllable
from the student's remote location.
Fig. 1 is a block diagram illustrating how the system operates. Information flows in both
directions. The experiment itself is an induction motor powered through an Adjustable Speed
Drive (ASD). Appropriate instruments, in this case, an oscilloscope and a power supply, gather
the data. Through a General Purpose Interface Bus (GPIB), the instruments send their data to a
Personal Computer (PC)-based server running LabView software. The server processes the
data and formats it for transmission over the Internet and display on the remote user's monitor.
The remote user may also send commands over the Internet to the server. The server translates
these commands using LabView and sends appropriate instructions through the GPIB for the
power supply and oscilloscope. The power supply then generates relay signals to energize the
experiment and also creates appropriate speed signals for the ASD.
This prototype system was designed in three phases, as described in the next section.
Design Methodology
Meeting the design objective proceeded in three phases.
Phase 1:
Real time display of experimental voltage and current waveforms at a remote site
Phase 2:
Real time audio and video display of the experiment at the remote site.
Phase 3:
Real time control of the experiment: power on/off and motor speed adjustment.
The following three sections give the details of that design.
Page 3.607.2
Phase 1: Waveform Display Using LabView
For this experiment, LabView performs two major tasks. First, LabView processes
commands to control the instruments. Second, LabView gathers the data and processes it for
display in a graphical format on a computer monitor.
LabView uses a pictorial solution to the programming problem. It creates programs called
Virtual Instruments (VI) in block diagram format using a graphical programming language, ‘G’.
Each VI, being based on an icon-based modular programming approach, can be run by itself or
can be a part of another VI called a subVI.
GPIB, a bus interface system, enables LabView to interact with the instruments. This project
employs the GPIB features of LabView, including a library of applicable functions through
which the server and instruments communicate. GPIB is the platform for communication for
instrument I/O operations. The LabView VI does the control and the data displays. The
LabView front panel is analogous to a physical instrument panel, representing in graphical form
a convenient user interface to the LabView VIs.
For this project, the first task is to design and build appropriate VIs to control and operate the
instruments, the oscilloscope and the power supply. Controlling the experiment from the
computer using LabView in its ordinary local operating mode, just as an on-campus student
might be expected to do, is the first milestone. Procedures to do this, including the use of library
functions and user-generated VIs, are documented in the LabView manuals.[2]
LabView versions 4.0 and higher include Internet interface software. Among this software is
a server package that can receive an input from the Internet at the server and then directly convert
that input directly into a LabView command for the measurement instruments. In addition to
the server software, the server also must have a Hypertext Markup Language (HTML) file that is
a locally generated "webpage." . This HTML file contains the LabView VI front panel along
with other information pertinent to the experiment at hand. The remote user downloads this
"webpage" to gain an interface to the server, both to enter commands and to receive measurement
data. The portion of this "webpage's" display that presents the measured waveforms is shown in
Fig. 2.
Page 3.607.3
Fig. 2. Webpage with CUSeeMe
The system works as follows: the remote user enters a command on a web browser display for
the experiment at hand. The remote user's browser sends the command to the server. Upon
receipt of a LabView command from the server, LabView commands a reading of the
waveforms of channels 1 and 4 on the oscilloscope. These waveforms are then read sequentially.
The readings are return through the GPIB to the host computer which, with the LabView server
software, converts the readings into graphics and sends the graphics to the remote user. Upon
receipt of these graphics, the remote user's web browser displays them.
Merely displaying the waveforms of the motor is similar to a computer simulation. It is not
yet a realistic laboratory experience, which is the aim of this project. In order to implement a
more practical lab, it is important to physically see and hear what goes on in the lab. The design
of such interactive video and audio is addressed in the next section.
Phase 2: Audio/Video
Videoconferencing provides a convenient means of audio and video communication over the
Internet. Individuals and businesses already use videoconferencing to communicate between
several locations simultaneously. At present, audio (voice) of excellent quality is available for
Internet communication. Video of up to about ten frames per second is also available now,
though the quality of the compression algorithms varies widely.
This systems uses videoconferencing to show the remote user the experiment in operation,
including its unique video and audio. With videoconferencing, the remote user can actually see
and hear the experiment in operation in real time.
This requires videoconferencing software, camera, microphone, and speakers. For this
purpose, the CUSeeMe videoconferencing software [5] is chosen for four reasons:
1) It is able to transmit the audio/video required for the project.
2) It can be investigated from Cornell University as freeware before proceeding.
3) The student can receive the audio and video through a 28.8k modem.
4) Installation and setup is easy and few modifications are required.
A camera for this project, brand name Quickcam, is chosen for its cost: It is an inexpensive
black and white model [8]. The camera plugs directly into the parallel port of a computer and
does not require the use of a video capture board, as some other video cameras do. The camera
draws its power from the keyboard, which is not affected by the power drain. Fig. 3 shows the
setup used for the audio/video.
Keyboard
Parallel Port
Computer
QuickCam
Sound Card
Microphone
Page 3.607.4
Fig. 3. Computer for Videoconferencing
Fig. 2 also shows the Enhanced CUSeeMe [5] screen that the user sees. The optional,
movable side windows show the video image on the right, and the audio control below it. In Fig.
2, the general control panel for the videoconferencing software has been minimized, but it
includes controls for specifying the maximum and minimum settings for sending and receiving
information and for turning audio or video on and off.
The audio/video system enables the video student to see and hear the machines as they
operate. Receiving video pictures of the lab and the equipment gives the student a more
complete experience, comparable to the on-campus students. This system requires someone in
the laboratory to set up the equipment on-site, but requires less monitoring after everything is set
up. The time commitment then would be minimal for the instructor or lab assistant.
Now that the data collection and control thereof is complete, the remaining task is to control
the experiment itself from the "webpage." The next section describes how this is done.
Phase 3: Motor Control from Web Page
To implement phase 3, an AC motor drive is chosen to serve two functions: to provide a
compatible remote interface for external control motor speed and to provide three-phase power in
a location having only single-phase power. In the drive chosen, a Baldor Series 15 Inverter [1],
there is a selection of control interfaces for external control of the motor speed: 0-5 V, 0-10 V,
or 4-20 mA. An appropriate GPIB card should be selected for this interface. However, due to
limits on available time to complete the project, the convenience of a 0-6V GPIB-based power
supply is preferred. In practice, the GPIB card would be a far less expensive and more capable
alternative.
LabView controls this interface voltage by a command to the function generator through the
GPIB interface. To accomplish this, the remote user first selects and enters a speed at an
appropriate place on the "webpage." Upon receiving a command from the remote user, the server
translates it into a corresponding LabView command to set the speed to that requested value.
LabView converts this command to an instruction to the power supply to provide an analog 05V output to the ASD. LabView limits the power supply output to 5V, providing necessary
circuit protection and an overall speed range from zero to the preset maximum of 60 Hz or about
1800 rpm.
Another power supply output provides the necessary on-off control for the ASD. The power
supply output provides the coil current for a three-phase relay with contacts in series with ASD
input. Signal processing for the on-off command is identical to the speed signal's processing.
Another feature added to the measurement system at this point is the capability to save
waveform data at the remote user's site. Each set of measured data is saved at the server location
directly from LabView. The format is an MS Excel spreadsheet. The user has an option on
the "webpage" to download that data (the SAVE WAVEFORM button shown in Fig. 2).
Page 3.607.5
"Webpage" Design
The webpages are HTML-based. The user accesses the Laboratory Home page, shown in Fig.
5, by entering the IP address of the project. The home page introduces the site, gives the sponsor,
and provides two links: access to audio and video software and access to the lab interface itself.
To enable the video and audio capability, the student must either already possess a copy of the
appropriate version of CUSeeMe or must go to the link provided to download the CUSeeMe
software. The student follows the instructions at the CUSeeMe site for installing the program
and configuring their browser.
Power Supply
0-5 volts External Control
+25V
+6V
Relay
Board
3φ AC motor
AC Drive
120 V
240 V Transformer
Fig. 4 Motor Control Topology
Fig. 6. Entering Password
Page 3.607.6
Fig. 5. Home Page
After installing CUSeeMe, the student goes back to the home page and accesses the link
labelled "Laboratory," which takes the student to the laboratory. The laboratory is password
protected; See Fig. 6. Upon successful password entry, the next page automatically appears. On
this page, the student activates CUSeeMe audio/video through the link provided. The student
then moves on to the motor start page through the link provided.
At the motor start page, shown in Fig. 7, the student starts the motor by selecting the "Start
Motor" button. When the next page appears automatically, the student enters the desired
frequency in the block shown in Fig. 8. The student sees the motor start on the CUSeeMe 
screen and hears the motor. To change frequencies, he or she enters a new value. At the bottom
of the page, there is an option for student to save the waveform data to a file.
Fig. 7. Motor Control Page
Fig. 8. Frequency Control
The G Webserver supplied with the Internet Developers Toolkit provides interface to these
"webpages." The G Webserver allows the front panel of LabView to be shown and controlled
on the "webpage". Standard CGI script cannot be used with the G server, so each element must
instead be written as a LabView VI. The LabView InternetToolkit provides VIs for writing to
forms, executing files, and other standard CGI scripts.
Page 3.607.7
Results
The motor, shown in Fig. 9, may be both turned on and speed controlled through the
"webpage." The "webpage" password access provides modest security. Only one user at a time
may access the experiment. The voltage and current waveforms of the motor are displayed sideby-side in separate graphs with numerical frequency measurement as shown in Fig. 8. Typical
oscilloscope adjustment commands are not yet included on the VI front panel, though this is
quite easy to do in LabView. The system gathers data as expected and can save it in MS Excel
spreadsheet format. Commands to change the speed are accurately processed, though it does take
about a few seconds to do so, primarily due to the Internet delay.
CUSeeMe software for videoconferencing met the audio and video requirements. Picture
quality is good with a frame transmission rate of 2-10 frames per second. The variance in frame
rate is caused by the software's video compression algorithm. The CUSeeMe picture is quite
small, however.
The audio/video was placed in a separate program to allow the user the option of shutting off
the video, audio, or both in order to conserve bandwidth. Deleting the video did improve
command response remarkably, but at the obvious cost of loss of video.
Performance was not significantly different, except for Internet delays, for having a remote
site in the same building or having the remote site across campus.
Limitations
There are some significant limitations to the use of the system. First, the video/audio
transmission rate relies heavily on the speed of the user’s modem. Even a fast modem facility
does not guarantee satisfactory results, depending on the transmission/reception route and the
traffic level on the Internet. Second, only one user may control the motor at a time, as more users
would be sending conflicting signals. This means that, for more users, either more experiments
must be built or a method must be developed to permit users to share data and control. No
attempt to share access or data is attempted in this prototype.
Implementing a more complicated, but practical laboratory would require extensive resource
management and include much more complex software, hardware, and interfaces. An attendant
may be necessary to set up the lab, and monitor the equipment, in case of problems that the
remote lab user can not control, such as a faulty wires, fire, or tripping a breaker.
Fig. 9. The Relays, AC Drive, and Motor
Fig. 10. The Current Amplifier, Power
Supply and Voltage Isolator
Page 3.607.8
Recommendations
The project obviously is not yet in a form usable for a complete experiment for an off-campus
course. To do so was not an objective. The following should be addressed at a minimum to
make this possible.
One important item is to design a program where the remote student has to correctly match
and wire the machines lab. A student should not be able to start the lab until he or she has
demonstrated knowledge of three phase wires, variacs, ammeters, voltmeters, and where to get
the supply voltages, whether 120v, 240v, and AC or DC. Circuit assembly and troubleshooting
are among the most important and the most difficult parts of any machines lab. Hence,
developing these skills is important for a full laboratory experience comparable to that provided
to on-campus students. Designing this interface is the subject of a small ongoing research grant.
Since all the labs require slightly different connections and lab equipment, a major task will be
making the interfaces for each and every lab or else designing one general interface. The design
must be streamlined far better than the hardware configuration shown in Fig. 9 and Fig. 10.
Some of the basic concepts are already shown, so it will just be a matter of expanding on
them. However, this system and the ideas proposed are not limited to a machines lab.
Suggestions for topics range microcontrollers to electronics to circuits. The University of Idaho
recently received another research grant, this one being nearly $200,000, to extend this project's
results to a Mechanical Engineering Dynamics Laboratory.
The competition for this system is the well-designed simulation. This system must provide
the realism of actual hardware in a learning environment if it is to hope to succeed against those
simulations. The advantage of this system is that the users know that the results and lab data that
they obtain are in fact real and not simulated. In other words, the data is indeed experimental
data, warts and all, gathered in real time. Whether such a system is or could be better than a
simulation is beyond the scope of this investigation.
Conclusions
This project demonstrated some possibilities of a remote laboratory system through the
Internet. A system was set up that can measure voltages and currents, and also control motors
and loads. While doing this, the user can also use videoconferencing and see and hear the
machines and machine lab equipment. This system is based on an ordinary application of
LabView software and the Internet Tools contained in versions 4.0 thereof and higher.
The system performs as expected, providing experimental data to the remote user in response
to user commands. The may change experimental inputs in accordance with reasonable
experimental procedures and may expect appropriate data in return. Speed of response, both due
to Internet delays and due to local processing delays, is significant. The videoconferencing
option contributes greatly to these delays.
The capabilities must be greatly expanded for this system to be useful to lab students and to
teach all the basic concepts of the machines laboratory. The system should incorporate circuit
assembly and troubleshooting. The competition for this system is a simulation of the same
experiment. The system in its present state holds promise of being comparable or better than a
corresponding simulation, but there is much development to do before that may be realized. It is
important to remember that the remote lab user needs a comparable experience to on-campus
students, not an easy, routine matter of hooking up to a Web page and pressing ‘Start’.
Acknowledgments
Dr. James Peterson, Professor of Electrical Engineering, and John Jacksha, Computer System
Administrator, contributed valuable advice and support to this project. Baldor Electric Company
of Fort Smith, Arkansas, provided a 2 hp AC motor and ASD. Hewlett-Packard Corporation of
Boise, Idaho, provided the oscilloscope and power supplies. National Instruments Corporation of
Austin, Texas, provided a discount on LabView 4.01 upgrade, the Internet Tools Kit with G
Web Server, and technical support. White Pine Software (CUSeeMe) and Cornell University,
both of Cornell, New York, provided a demonstration version of the videoconferencing software
and followed up with their Enhanced version on a trial basis.
Page 3.607.9
References
[1] Baldor Electric Company, Series 15 Inverter Control Installation & Operating Manual.
[2] National Instruments LabView Reference and User’s manual, Version 4.01, Jan. 1996.
[3] M. Brown, Mark and J. Jung, Using HTML, Que Corp., 1996.
[4] National Instruments Corporation Webpage (http:// www.natinst.com).
[5] White Pine Software, CU-SeeMe Webpage (http:// www. CUSeeMe.com).
[6] A Beginner’s Guide to HTML (http:// www.ncsa.uiuc.edu / General / WWW /
HTMLPrimerAll.html#GS).
[7] Reviews of Videoconferencing Software, News.Com (http:// www.news.com / News / Item/
0,4,1334,00.html).
[8] Connectix QuickCam Website (http:// www.quickcam.com / connect / qcdata.html).
[9] CNET Reviews on Software Website (http:// www.cnet.com / Content / Reviews /Compare/
Video / ss04.html).
HERB HESS received the BS degree in 1977 from the US Military Academy, the SM degree in
1982 from the Massachusetts Institute of Technology, and the PhD degree in 1993 from the
University of Wisconsin-Madison. He is Assistant Professor of Electrical Engineering at the
University of Idaho. His interests are in power electronic converters and electric machine drives.
Page 3.607.10
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement