DUPLEXE: The Dynamic, User-expandable Physics Laboratory EXperimental
Environment
by Perry A. Tompkins
Associate Professor of Physics
Samford University
Products Used
LabVIEW 5.0
AT-MIO-16E-10
BNC-2090
CB68
The Challenge
Many
academic departments across the country are determining the need for
modernization of their teaching laboratories through computerization. Often efforts are directed at the programming
of discrete vi’s that replace the standard instruments. This virtual instrumentation software
regretfully has little connectivity with the methods of testing and
experimentation in industry.
The Solution
Starting
with an automated test philosophy developed by the author for industry,
software was developed with the intent of making student completed laboratories
comparable with real world testing or experimentation. Through the use of a scripting tool and a simple
test executive, students compose and execute their experiments.
Introduction
In
order to expose physics students to high quality laboratories with significance
beyond the classroom, DUPLEXE was created.
Based from a simple test executive engine used in industry, DUPLEXE
combines computer controlled experiments with the procedural requirements of a
production test. Students create test
scripts with the “Experimental Script Creator(ESCAPE)” and then execute them on
DUPLEXE. The polymorphic experimental
interface changes to display the current data.
There are many included experiments, yet LabVIEW capable instructors or
advanced students can easily append capabilities to the test executive. DUPLEXE
has been initially incorporated into the general physics laboratories at
Huntington College.
1.0 DUPLEXE’s Structure
DUPLEXE
has three main levels of complexity, a simple test executive inside of dual
nested state machines. The outside
state machine controls the student interactions that occur outside of an
experiment. The inside state machine controls
the student interaction that occur during an experiment, including single
stepping through a script, and the test executive, one of the states of the
inside state machine, is a well controlled case structure that includes the
full capabilities of the experimental environment. A block diagram showing the structure of the program is shown in
figure 1.(This figure is an attempt to use LabVIEW to show the structure of a
complete vi. It is not a section of
executable code. As expected, it is
difficult to show the layers of a case structure in 2 dimensions!) In addition to the basic structure of the
software, various utility functions have been created to assist the student
during the experiment. These functions
are available during appropriate phases of execution. Included in these functions are a direct hardware interaction
utility, called the “Hardware Commander”, a data viewer and analyzer, an
automated script logger, an experimental component tracker and full printing
capabilities.
1.1
The Outside State Machine
The
outside state machine allows access to all of the utility functions in addition
to assisting the student to initiate a new experiment, and end the software
execution. When the student requests a
new experiment, a dialog VI assists them in collecting operator
information. This information includes
the type of experiment to be executed and a student specified name, which will
be used to automatically generate file names.
Additionally, the operator can choose to redirect the data from the
default location to any path desired, including mounted network drives. Finally, the software will make a copy of a
specified component list and save it under the new test name. Completion of the operator information will
return control to the outside state machine.
At this point, normal operation would be to load in a specified script
to be executed for the experiment. All
of the available scripts are loaded into a front panel pull-down menu at the
initial execution of DUPLEXE. The
software checks that the loaded script and the operator selected experiment
type are compatible. If they are,
control of the program is passed to the inside state machine.
Figure 1. Block diagram of the internal structure of
the program DUPLEXE.
1.2
The Inside State Machine
The
home state of the inside state machine is shown in figure 2. This state also allows access to all of the
utility functions, however, since the software is in the middle of an
experiment, these functions may operate differently. In order to access the Hardware Commander, a password must be
provided. This limits the operators
ability to modify the state of the hardware outside the scope of the experimental
script. If the script logger or
component tracker are accessed, they will initially provide the student with
the appropriate information for the current test. Finally, the printing capabilities are limited to the current
data being taken, without analysis (unless the data viewer and analyzer is
being used.
Additionally,
the inside state machine controls the flow of the test executive. The “Abort” button, which was previously
disabled, is now available for exiting the experiment. During execution there are three modes of
flow control for an experiment, Manual, Automatic, and Semi-Automatic. The last two are for executing the script in
a more automated way than single stepping.
These modes are more historical than necessary, since most student experiments are best executed with the
thought required when single stepping.
This test executive and the associated scripting tool, ESCAPE, allow for
the nesting of a scrip within a script.
This allows for multiple repetitions of a needed sub-procedure, but is
limited to only one layer deep due to circular logic complexities. Once a sub-script has completed execution,
the inside state machine will query the operator whether to repeat the
sub-schedule or move on to the next step in the main script. Once the main script has completed, control
of the program will return to the outside state machine.
Figure 2. Home state of the inside
state machine. In addition to
controlling the state machine, the home state is responsible for the flow
control of the test executive system.
1.3
The Test Executive
Finally,
the flow control of the test executive will allow the operator to back-up
through the script. If the operator
backs up past the creation of a new data file when unsaved data is available,
the current data is saved under the pseudonym “REDONE” with the appropriate
three character extension. One last
caveat concerning backing up is that the operator cannot back out of a
sub-schedule.
When
the software requests the execution of the next step of the experimental
script, it passes control to the test
executive. The test executive is simply
a case structure that has each case associated with some basic or complex,
discrete function, executable by the experimental station. The software reads the type of the next step
to be executed. It then selects the
case associated with that step and executes the code contained within. Any parameters that are to be used by that
step, such as number of data points, are also extracted from the script and
made available to the code to execute.
Some
basic steps that are available are, to load in a sub-schedule, a text message
to the operator, generation of a new data file name, saving header or data to
file and calling the hardware commander or data viewer functions. More complex functions could include
multiple AC measurements, as used in an RLC circuit laboratory, or a position
vs. voltage measurement as used in a linear magnetic field measurement. These complex steps are where the student
expandability really comes into play.
If a professor or student wishes to add a new capability to the test
executive, they must create a new case
at the end of the structure, and fill it with the desired functionality.
In
addition to the execution of a specific step, the test executive must address
some housekeeping functions. For each step that is executed, an entry into
the script log is made. Also, the test
must allow the script to be aborted in the middle of a step or in a sub-vi, if
the step or sub-vi will take a significant amount of time, like a long data
acquisition. Often aborting in a sub-vi
is enabled throughout the use of a global variable that monitors the abort
button asynchronously with the test executive.
1.4
The Polymorphic Graphical Interface
Real
estate on the front panel is a premium for almost every user interface. There are various solutions available, but
the use of appearing and disappearing, controls and indicators and text
variables was chosen for DUPLEXE.
Admittably, this is not the most efficient solution from a resource
point of view, but it seems to be simpler than the use of a different screen
for each experiment. Approximately
fifty percent of the screen, with the experiment overhead information, never
changes while running an experiment.
This affords a familiarity with the software which can assist the
success of the student. A view of
DUPLEXE’s main screen without any of the controls or indicators showing is
given in figure 3. In a later section,
figure 8 shows the same screen during an experiment.
Figure 3, DUPLEXE’s main screen
without any of the indicators or controls showing.
In
conjunction with the main screen, the data viewer and analyzer and the printing
utility must have a comparable polymorphic interface. They must adapt to display the current data that is being viewed or
printed. For an experiment that
includes additional analysis, like a least-squares-fit to the data, they must
add new indicators which provide the analysis information.
1.5
Hardware Commander
The
Hardware Commander allows access to the basic functionality of the data
acquisition hardware for aliveness checking.
For example, if four probes are connected to a RLC circuit, the operator
can verify that all four probes are measuring reasonable AC voltages. Or, if the voltage offset is needed for a
hall probe, to calibrate the sensor for zero field, this can be
determined. Currently the Hardware
Commander has only been implemented to interface with a data acquisition
board. If a specific experiment needed
a different type of interaction, such as controlling a motion board or
interacting with a serially controlled instrument, it can be easily added. The Hardware Commander is a state machine
that allows control or interaction of one type at a time. Figure 4 shows the Hardware Commander. The empty space in the figure is for future
expansion.
Figure 4. DUPLEXE’s Hardware
Commander.
1.6
Data Viewer and Analyzer
DUPLEXE’s
data viewer and analyzer is compatible with all types of DUPLEXE data. When an operator selects a data file, the
program inspects the data file and determines the type of experiment that the
data is from. It then adjusts its
polymorphic interface to display the type of data required. If there is analysis associated with the
specific experiment, it will complete the analysis and display the data. In some experiments, student interaction may
be required before the analysis is completed.
Data analysis can only be printed from this function. An example of this function is shown in
figure 9 in a later section.
1.7
Script Log
The
Script Log automatically keeps track of the completion of each step in the
script. Each entry will include the name the of the step, a numerical and text
field, and a time stamp. If the script
is aborted prematurely, this will also be noted. This script keeps track of the successful completion of a script
and can be part of the data provided by the student for grading. An example of the script log function is
shown in figure 5. The script log file
is saved in a tabbed-delimited spreadsheet format. Even so, the operator can print the data contained within the
script log.
1.8
Component List
The
Component Lister is a utility that allows tracking of the different components
and equipment used during an experiment
It includes various descriptives such as serial number, model number and
manufacturer. It also allows recording
of calibration dates, but has no warning system to inform the operator that a
calibration is due. The data can be
printed or saved in a tabbed-delimited spreadsheet format. This function is not as useful as many of
DUPLEXE’s other functions for experiments in the classroom.
Figure 5, an example of the Script Log. Notice that the last entry indicates that
the script was aborted prematurely.
2.0 An Example: Measurement of the Magnetic Field of a Long
Straight Wire
In
order to provide a clearer understanding of the operation of DUPLEXE, the
execution of one of its built-in experiments will investigated. A picture of the laboratory set-up for
measuring the magnetic field from a long straight wire is shown in figure 6.
2.1
Theory
The
theory for this experiment is fairly simple.
The magnetic field from a long-straight wire is:
(1)
Where
B is the strength of the magnetic field, I is the current through the wire, R
the radial displacement of the probe from the center of the wire and 
the permeability of free space. If the experimenter measures the magnetic field
strength for many different positions, they can determine a plot of the
magnetic field strength versus the radius.
A line can now be fit to the data if it is represented by B versus 1/R. The slope of this line will be 
If I is measured for the circuit, we can directly
determine the value of 
!
Figure 6, the experimental set-up
to measure the magnetic field from a long straight wire.
2.2
The Hardware Set-Up
The
hardware is also simple. A high current
8-gauge copper wire is used for the long straight wire. It is connected in series to a high-power
0.1W resistor to a 60-A, 5 VDC power supply.
The approximate current in this set-up is 50 A, though by measuring the
voltage drop across the resistor, a very accurate value can be obtained. The magnetic field is measured using a
hall-effect sensor. This sensor has an
approximate 2.4 VDC offset at zero field and must be calibrated before
use. The smallest detectable change in
voltage causes a measurement error of approximately 1 Gauss. This is a few percent error in this
experiment.
2.3
Execution of the Script
Initially
the experimenter selects a new test.
This will bring up the operator information vi. This is shown in figure 7. The test name is automatically generated
using the parameters of the operator information.
When
this is completed, the execution of the experimental script can be
started. After some initial operator
information dialogs, the Hardware
Commander can be used to measure the voltage on the probe, in the absence of a
magnetic field. Then the data can be
collected and displayed. The
polymorphic displays will appear when the specific step is executed that is
used to make the measurement. The main
DUPLEXE screen is shown in
figure
8, with the data from a linear-B measurement.
Figure 7, The Operator Information
interface.
Figure 8, DUPLEXE’s main screen
showing data from the measurement of a magnetic field of a long straight wire.
After
the data has been taken successfully, the script will save the header to the
file and then save the data. From the
outside state machine, the operator can select to analyze the data, and select
the data that was just generated. The
reviewed data and the analysis described above is shown in figure 9. Once again the polymorphic display has
caused the indicators to appear that display the collected and analyzed data.
Figure 9, The Data Viewer and
Analyzer function showing the raw data, the raw data plotted as B vs. 1/R and the
linear least squares fit of the line, and the line fit parameters.
The
slope that was measured was 0.090822.
This corresponds to a measurement of 
of 3.63 p x 10-7 Tm/A. This is an error of 9.2% from the accepted value. This has been a very successful experiment!
3.0 ESCAPE
Up
to this point, this paper has been concerned with the test executive and the
utilities and super-structure associated with it. Now the software that is used to create a script will be
discussed. While a simple spreadsheet
application that essentially assists in the creation of a script could be used,
The Experimental Script Creator or ESCAPE(long for ESC) was created to allow
easy creation and modification of scripts.
This higher functionality has caused ESCAPE to be a fairly complex
software application.
3.1
Test Scripts
All
scripts are made up from a series of steps.
Each step has an associated type which is selected from the available
steps programmed within the test executive.
Each type of step will have associated parameters that are necessary for
the test executive to execute that kind of step. If my step type is “Operator Message” the associated parameter
would be the text string(s) that include the message. There are three basic types of parameters, numeric, Boolean and
string. Additionally, in the special
case where the operator is specifying the loading of a sub-script, the filename
of the sub-script is a parameter(while this is still a string, ESCAPE treats
the entry of this data special by displaying a menu ring that contains all of
the available test scripts.) The
created scripts have these steps, their associated parameters and some header
information. The interface performs the
proper formatting and organization of the information for use by DUPLEXE.
3.2
User Interface
ESCAPE’s
user interface is shown in figure 10.
This shows ESCAPE with a script loaded.
Navigation through the script can be accomplished through a number of
means. Starting at step #0, the
operator can select a step type in the “Step Type” menu. After including any necessary parameters,
and by selecting “Step OK” the step will be loaded into the script. The program will automatically increment for
editing the next step. In this way a
new script can be built. Additional to
single-stepping through the script, the “Go To Next Step” control or simply
pressing the push-button next to the desired step can quickly allow editing of
any step.
Figure
10, ESCAPE’s user interface.
For
editing an existing script, insertion and deletion of individual steps is
available. Since only 40 steps in a
script can be displayed at a time in the step list on the lower half of the
screen, column over and back controls are included. Auto-tracking will force the software to always display the step
currently being edited in the step list.
The
large area above the step list is another polymorphic area that displays the
required parameters for a given step.
Arrays for the numeric, Boolean and string parameters and arrays for
each of the parameter’s labels can appear and resize as necessary. If it is necessary for more than 10 elements
of any given parameter type, that array and the associated label array’s index
display will be displayed. This
polymorphic area allows for clear display of only the needed information for each individual step type.
The
Script Type is an indicator of the use of the script. In the case of a script that is going to be used in DUPLEXE, it
will be the experiment type. DUPLEXE
checks that the experiment type indicated in the script matches the experiment
selected in the operator information.
An error will occur if they do not match. ESCAPE will allow the printing of a script or the saving of the
script in tabbed-delimited spreadsheet format.
Once a script is saved, it is automatically entered into the Script Name
menu ring.
To
assist the operator, built-in help is available. The introduction to this help screen is shown in figure 11.
Figure 11, The introductory help
screen for ESCAPE.
3.3
Expansion
At
first glance of the operation of ESCAPE, one might imaging that a great deal of
the parameters for a specific test executive are hard coded. Many menus have specific information,
parameters and labels are associated with each step. Actually none of the information that ESCAPE uses to build a
script is hard coded. A separate file
that keeps ALL of the test executive specific information is read by ESCAPE at
execution and loaded dynamically.
Modification of all of the behavior of ESCAPE or the addition of a new
capability to an existing test executive can be accomplished in a few
minutes. Any application that needs a
script to control execution could use a script created using ESCAPE. All that would be needed is to copy the
structure (and order!) of the cluster that the scripts are stored in, into that
application.
4.0 Summary, and Future Directions
DUPLEXE
and the associated script creator, ESCAPE have been designed around an
experimental strategy presently being used in industry. This has allowed the students to experience
the processes encountered in taking real-world data, in the classroom. The small sampling of students that have
been exposed to the program were enthusiastic about the laboratory process and
the significance of what they were learning.
DUPLEXE
has been set up to allow appending of additional capabilities without rewriting
the existing code. Familiarity with
LabVIEW is required to do this, but that should be expected with any
application of this complexity. ESCAPE
is simple to modify for new functionality since none of its specificity is
coded in LabVIEW. Additionally, ESCAPE
is a general utility that could be used to generate any test script, for any
test executive that can operate within its limitations.
The
primary future direction will be to expand DUPLEXE, which is structurally
complete, by populating it with a full complement of experiments to support a
complete laboratory curriculum. Beyond
programming, a laboratory manual and hence a full written curriculum must be
developed in order for other institutions to use DUPLEXE. In addition to a curriculum, some level of a
training manual must be prepared for instruction of the laboratory professor.
Beyond
DUPLEXE, the author plans on developing an integrated, computer-based,
laboratory notebook for the students to track and display their data. In some
respects, this laboratory paradigm may be advanced to many of the real-world
situations they might encounter after graduation. It is expected that this notebook would rely heavily on many of
LabVIEW 5.0’s web capabilities.
5.0 Acknowledgments
The
author would like to thank Jerry Smith and Bill Bordeaux at Huntington College,
Huntington, IN for allowing him to use their physics students as guinea pigs,
and for believing in the importance in computerization of teaching
laboratories. He would also like to
thank the guinea pigs themselves for their patience, Tim, Marla, Ann, Chad,
Jose and Nate. Additionally, a great
amount of assistance in reviewing and improving this paper was gratefully
received from Chris Archer.