 How
Process Automation Scripting
Cuts Test Development Time From
Days To Minutes
by Dave Bonnett
ScanWorks Technical Marketing Manager
ASSET has always provided ScanWorks
with powerful APIs for developing boundary scan tests
and migrating them from a development environment to
manufacturing and subsequently to field service. We
began with the Scan Function Library which is based
on C++ and continued with ScanPort and later with ScanWorksAPI.
Each of these APIs has unique features that are needed
for specific applications. Now, Process Automation Scripting
combines all of the features of these APIs into one
and offers additional capabilities as well.
Process Automation Scripting grew out
of a customer request, which was, “I want to write
a Tcl program to automate the process of creating all
of the ScanWorks Actions needed to test my board.”
This board included more than 40 memory devices and
each device required its own Memory Access Verification
(MAV) action. Process Automation Scripting reduced MAV
test generation time from 1½ days to about 24
minutes (15 minutes to create the Tcl program and 9
minutes to run it.)
Process Automation Scripting makes
ScanWorks features available through some of the most
common languages that are familiar to test engineers.
Whether using an interpreted language like Tcl, Perl,
of Visual Basic, or a compiled language like C# or C++,
you can create and control software objects through
the Process Automation Scripting interface. Process
Automation Scripting uses Microsoft’s Component
Object Model (COM) to make objects available to any
language that supports COM.
The process automation scripting feature
consists of a set of objects, each encapsulating both
data and functionality. The way these objects are organized,
together with the way the data and functionality is
allocated to each object, is called the ScanWorks object
model.
The object model is a hierarchy of
objects rooted in a single top-level object called the
API object. The API object contains all the other objects
in the object model. Objects in the ScanWorks object
model are named according to the portion of the ScanWorks
application they represent. For example, the Project
object represents a ScanWorks project. You can access
objects in the ScanWorks object model only when the
API object exists (that is, when ScanWorks is running).
The ScanWorks object model provides
high-level access to your projects, design descriptions,
and actions. For ScanWorks manufacturing stations, a
subset of the object properties and methods is available.
The ScanWorks object model contains
a number of collection objects. Similar objects are
grouped into collections. By convention, all collection
objects are given the plural form of the name of the
object it contains. For example, the Projects collection
object contains Project objects, one for each project
currently known to ScanWorks. Similarly, the Designs
collection contains Design objects, one for each design
description in a project.
To access the data contained in an
object, you use the properties of that object. In all
instances, properties can be used to get data from an
object. In some instances, properties can also be used
to change (or set) data in an object. Properties are
referred to as read-only if they only support getting
the data. Properties that allow data to be changed are
referred to as read-write properties. For example, the
Count property of the Projects object is read-only (you
can’t create new projects or delete existing projects
simply by changing the number of known projects). On
the other hand, the Name property of the Project object
is read-write. You can use this property to get a project’s
name, but you can also use it to change the project’s
name (rename it).
To access functionality contained in
an object, you use the methods of that object. Methods
initiate some kind of action on an object. For example,
the Run method of the Action object causes ScanWorks
to run the action.
Process automation scripting allows
you to use an .INI file to specify more than one action
at once using the CreateActions method of the Projects
object. You can check the creation results using the
CreateActionsResult object.
For example, the following .INI file
includes one project (AGDM), one design description
(GDM), one scan path verify action (SPV), and three
Memory Access Verification Actions MAV1, MAV2, MAV3).
|
