USE THE POWER OF 'C' TO DEVELOP
FUNCTIONAL AND DIAGNOSTIC TEST PROGRAMS
COPYRIGHT TESTniques Inc. June 1991
Written by Mr. Tom Keely, President TESTniques Inc.
ABSTRACT
While instrument and software vendors work to define market needs and
balance their resources to write software instrument drivers, a more
comprehensive approach is required to provide useful software for
functional and diagnostic test programs. Instrument manufacturers
have made progress by introducing the SCPI standard, but this does
not address the need for a common approach to high level language
interface. By developing high level language interfaces, test
executive functions and modular instrument drivers, the overall
readability, maintainability, and portability of the software can be
enhanced.
ATLAS and C
For high end test applications you could use the ATLAS (Abbreviated
Test Language for All Systems) test language to construct your test
programs. If you have the budget and ATLAS trained personnel this is
a viable approach. Another option would be to emulate some of the
principles of ATLAS into the C language and be running structured,
supportable and readable test programs using low cost off the shelf
products with a minimum of effort.
Although you wouldn't think of C as a "test language", many of it's
features can be tailored provide a great deal of functionality and
flexibility to the user. Using the wide range of C tools, you can
construct a test oriented high level programming syntax for functional
test programs.
APPLICATION
Functional and diagnostic test programs are usually stimulus-response
oriented. In a very simple test setup, a stimulus is applied to the
Unit Under Test (UUT), the measurement system then measures the
response of the UUT and evaluates the result. In terms of a language
interface, this process consists of an application of a stimulus, the
measurement of a response and the management of test resources.
RESOURCES, NOUNS, VERBS and SIGNALS
In ATLAS programs this process is repeated over and over using
programming constructs known as Nouns and Verbs. To jazz things up
ATLAS brings along the concept of single and multiple action verbs,
plus nouns and noun modifiers. (yes Virginia...this sounds like your
8th grade English teacher).
With this in mind, let's use this as a starting place for constructing
an instrument oriented syntax from C. First, use a noun to define a
resource followed by verb which describes what you want the resource
to perform.
For example: let dmm (Digital MultiMeter) be the resource and let
setup be the verb, we now have the beginning of a instrument function
call.
dmm_setup(.....)
resource------| | |-----instrument parameters
verb-----------|
For your application you can define your own set of resources and
verbs. Resources generally relate to some test station resource or
virtual resource (dmm, counter, dc_power, matrix_switch...)
Verbs are a little more dependant upon the application, but some
suggestions are read, write, setup, connect, configure, open, close,
apply, measure, or remove. Verbs can be either single action or
multiple action. A single action verb would be configure because it
configures the instrument without taking a reading. The verb measure
would be a multiple action verb since it would configure the
instrument, take a reading and return that reading from the bus.
A special case exists for the verb measure. When using measure it's
not clearly stated what we intend to measure. To overcome this
limitation, we'll introduce the measured characteristic. Dependent
upon how you construct your instrument driver, the syntax could be
either:
dmm_measure_dc_volts(....)
resource--| | | |
verb------------| | |
measured characteristic-| |-Instrument Parameters
or
dmm_measure(DC_VOLTS....)
resource--| | | |
verb------------| | |
measured characteristic-| |-Instrument Parameters
In this case, the measured characteristic would be passed as a
function parameter to the software instrument driver.
On the stimulus side, a similar syntax can apply:
function_gen_apply(AC_SIGNAL....)
resource---------| | | |
verb--------------------| | |
stimulus characteristic----------| |-Instrument Parameters
You have probably recognized signals are also nouns but are rather
referred to as measured characteristics or stimulus characteristics.
DEFINED CONSTANTS
Some instrument drivers already follow this sort of syntax but when
the they get down to passing instrument parameters they become
unreadable. Typically, a call might look like:
tek2430_config(0, 2, 1, -1);
Shortly after you write this code , you'll have no idea of what those
parameters relate to or what they mean. A better idea is to use a
set of defines through the #define construct.
#define AC_COUPLING 11
#define 50_OHMS 50
#define CH2 62
#define AUTORANGE 70
Using defined constants, the statement becomes:
digitizer_setup(AC_COUPLING, 50_OHMS, CH2, AUTORANGE);
which is much more readable.
If you're building a test system, you will develop standardized header
file(s) which will contain all the system's defined constants. The
defined constants should be unique numbers since a casual
misplacement could cause some unexpected results. You would not want
to allow two names have the same constants. A well constructed
instrument driver will incorporate range checks on the parameters as
they are passed into the driver routine.
Other uses for defined constants are to put in hooks for code which
apply to development environment but not to the production floor.
#ifdef (PRODUCTION)
/* do the production code */
#ifndef (PRODUCTION)
/* do the full development code */
INSTRUMENT DRIVERS
We've talked about instrument drivers, but what is an instrument
driver? The simple way to describe an instrument driver is a piece
of software which translates function calls to the control strings
which the instrument understands. If you wanted to talk to your GPIB
dmm and the control string is "F1A2T4" this in nearly
non-intelligible, so you build a high level software interface which
reads:
dmm_measure(AC_VOLTS, AUTORANGE, INT_TRIGGER);
Now that I can understand! That is an instrument driver. Extensions
to the driver easily can incorporate connection fields. For example
the dmm call can be expanded into:
dmm_measure(AC_VOLTS, AUTORANGE, INT_TRIGGER, J1_1, GND);
When the instrument driver gets to the connection fields (the last two
parameters), these will be passed again to the relay or switching
interface controller.
Building an instrument driver with SCPI commands is even easier since
the commands have a readable form and some of the function call
parameters may be parsed directly into the SCPI command string.
STRUCTURE AND CONTROL CONSTRUCTS:
Because we're using C as our parent language, we have the full set of
C constructs to choose from (i.e. do, while, if, else, for, break,
continue, switch, and goto). Since C is structured language, the use
of gotos occurs infrequently. A preferred method is to make each
test a function and call that function or use pointers and point to
that function.
ATLAS offers some interesting protection when it comes to branching
through what are known as the "B" and "E" flags. An E flag defines
an "entry" point for the test program (a legal point to start the test
program without doing damage to the UUT or the instrument system).
The other flag, the "B" flag, defines authorized points the program
may branch to.
You can incorporate these concepts into your C programs by declaring
some global variables, known as ENTRY and BRANCH and then letting the
your test executive decide if these are valid tests to run.
WHAT ABOUT DIGITAL TESTING?
Well, what about digital testing? Using C, you have such a wide range
of options, you will be able to tailor the solution you need. On the
highest level, you could use bus instruments to perform static and
dynamic stimulus-response-compare operations. Or at the other extreme
you could build your own digital test board and use in-line assembly
code to read and compare data. Either way, you can have high level
language drivers call and invoke the routines which perform the
digital testing.
If you have a requirement to linking test vectors from another source
C can give you the low level constructs to link the test vectors with
you program. Although this may require considerable programming on
your part, the results will be worthwhile since because you have
integrated functional and combinational testing in a single test
program.
PORTABILITY and MODULARITY
Portability can be enhanced by naming resources according to their
function rather than their instrument name. Consider if your test
stand supports multiple UUTs and you have written many test programs.
One day your digital multimeter will become obsolete. Now you are
faced with editing all those test programs since all the instrument
calls referenced a single model of DMM. It is far simpler to have a
software compatible driver module and relink the test program rather
than edit every instrument call.
A similar situation could occur if you are in between GPIB test
stations and VXI test stations. Using resource names would you allow
to relink the test programs with new VXI software drivers modules
rather than recode the test programs. The modularity of software
instrument drivers is shown in Figure 1.
TEST EXECUTIVE FUNCTIONS
Test programs should be run under the control of a test executive. A
test executive is the software manager of a test program. The test
executive will control the flow and sequencing of tests, manage the
logging of test data to output files, the printer, and the screen.
The test executive will also trap bus errors or fault conditions.
Since you are running automated tests, you've already written the
instrument control routines and this means you normally don't require
software instrument control panels. This is why a test executive can
be applied over a wide range of test programs and test stations. The
test executive serves as the standardized interface between the
automated tests and the operator.
Figure 2. Test Executive Control Panel for LabWindows 2.0
Our firm markets a general purpose test executive which is designed to
be used with Microsoft C or the National Instruments LabWindows
tool. In the latest software release of the executive for LabWindows
2.0 we have built a series of routines which provides a powerful
graphical interface. Besides the graphical interface, the test
executive has functions to import PCX files, import text files to
scrollable windows, and display software strip charts to monitor test
points. Figure 2 illustrates the test executive control panel for
LabWindows 2.0.
Our test executives have followed a slightly different philosophy than
they very robust test executives for ATLAS. In our implementation,
the test executive serves as the run-time interface between the
operator and the instrumentation system. It has limited debug
capabilities and just a few controls to keep operator confusion to a
minimum. For powerful debugging environments tools, use products
like LabWindows, QuickC and Microsoft CodeView (in other words, use
off the shelf products rather than re-invent them).
FUNCTION POINTERS
The first time you look at the syntax for a function pointer it will
send shivers down your back. Behind the asterisks and parenthesis
there is a very powerful tool. Conventional wisdom says to use a
function pointer to point to the instrument code for each test. In
other words, you can develop the code to run the instrument for each
test using your favorite tool like LabWindows or ITG DOS, and
preserve it as a function. When it comes time to build your test
program all you will have to do is pull that function in to the test
executive structure through the function pointer.
In an almost extreme example, Listing 1 shows a program with nearly no
program structure. Just start it up and it keeps going until it hits
an exit routine! To see how this works, consider that each test has
a data structure which consists contains information about the test,
test limits, a function pointer to the code for the instrument
commands and three pointers which point to the tests to be executed in
the event of 1) the test passes, 2) the test failed high, and 3) the
test failed low. This sort of program doesn't do much for a visible
flow but it lends itself to being built with an automated database
tool. For the test developer, things are easy since every new test
is thrown in the hopper with all the other tests; you won't have to
worry about where to put the test in a structured program.
CONCLUSION:
These ideas use concepts from ATLAS and apply them to off the shelf C
language products to turn out functional, readable and supportable
test programs written in the C language.
The syntax concepts presented here are not rigid; they doesn't require
the approval of an engineering committee or the review of a industry
standard working group. Use these concepts as a prototype for your
system.
