Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

SAE TECHNICAL
PAPER SERIES 950703

An Adaptable, Multitest, Multichannel

Fatigue Test System

J. J. F. Bonnen, and F. A. Conle

Ford Motor Co.

SAE

mA=For
The Engineering Society
Advancing Mobility
and Sea Air and Space,
International Congress and Exposition
Detroit, Michigan
-
February 27 March 2,1995
400 CommonwealthDrive,Warrendale, PA 15096-0001 U.S.A. Tel: (412)776-4841 Fax:(412)776-5760
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

The appearance of the ISSNcode at the bottomof this page indicatesSAE's consent
that copies of the paper may be made for personal or internal use of specific clients.
Thisconsent isgivenon thecondition, however, thatthe copier paya$5.00 per article
copy fee through the Copyright Clearance Center, lnc. Operations Center, 222
RosewoodDrive, Danvers, MA 01923 for copying beyondthat permittedby Sections
107 or 108 of the U.S. Copyright Law. This consent does not extend to other kinds
of copying such as copying for general distribution, for advertising or promotional
purposes, for creating new collective works, or for resale.

SAE routinely stocks printed papers for a period of three years following date of
publication. Direct your orders to SAE Customer Sales and Satisfaction
Department.

Quantity reprint rates can be obtained from the Customer Sales and Satisfaction
Department.

To request permission to reprint a technical paper or permissionto use copyrighted

SAE publications in other works, contact the SAE Publications Group.

GLOBAL MOBlUlY D A T M E
All SAE papers, standards, and selected
books are abstracted and indexed in the
Global Mobilrty Database.

No part of this publication may by reproduced in any form, in an electronic retrieval

system or otherwise, without the prior written permission of the publisher.

ISSN 0148-7191
Copyright 1995 Society of Automotive Engineers, Inc.

Positions and opinions advanced in this paper are those of the author(s) and not
necessarily those of SAE. The author is solely responsible for the content of the
paper. A process is available by which discussions will be printed with the paper if
it is published in SAE transactions. For permission to publish this paper in full or in
part, contact the SAE Publications Group.

Persons wishing to submit papers to be considered for presentation or publication

through SAE should send the manuscript or a 300 word abstract of a proposed
manuscript to: Secretary, Engineering Activity Board, SAE.

Printed in USA 90-1ZO~DIPG

 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018
An Adaptable, Multitest, Multichannel
Fatigue Test System
Abstract
A highly adaptable fatigue testing computer sys-
tem is presented for controlling single or multichannel
test machines. The system imposes most common
varieties of waveforms and also provides time syn-
chronization between channels, such as in the case of
variable amplitude biaxial load histories, and moni-
tors various feedback signals for both data acquisi-
tion and alarm purposes. The program operates in
a real-time Unix system as a separate stand-alone
process. Communication with other users or the op-
erator is done only through a reserved common block
of shared memory. This feature allows control and
monitoring of all tests over the computer network. A
user can simply login remotely and check the test or
start a data acquisition task from any workstation in
the company, and then take the data files and analyze
them on other computers. This paper describes the
operation of the software, the methodology behind
the hardware selection and the software structure.
Introduction
The advent of inexpensive computing equipment
has made the laboratory test control computer com-
monplace. Recent advances in networking office com-
puters has demonstrated the advantage of company
wide data exchange and program communication.
Test control computers have generally excluded ex-
ternal links during test execution, primarily because
of loss of real time system response. It is rapidly
becoming apparent, however, that the need to iso-
late the test computer is disappearing. The increased
power of small machines and the drive for networked
computing environments have ensured this change.
In many ground vehicle industry fatigue test and re-
search laboratories, there is generally a mixture of a
large amount of simple testing - i.e. constant am-
plitude stress or strain controlled axial fatigue tests
which require basic data logging - and a limited
amount of complex testing such as variable ampli-
tude loading on one or more control channels. Occa-
sionally, additional environmental equipment may be
monitored and controlled.
1
J. J. F. Bonnen, and F. A. Conle
Ford Motor Co.
Experience has determined that the following
system features and functions would be "ideal" for
the fatigue laboratory:
o data logging 500 channels at 1000 (sam-
ples/sec.)/channel.
synchronously control up to 20 (D/A and
TTL) control channels per test station.
simultaneous control of multiple test sta-
tions.
flexible monitor and control points: open
to a user network.
highly flexible time based test history
control.
high quality graphic data presentation.
Ezisting Solutions
Systems which employ one or more of the above
techniques are reasonably common, but there appear
to be no systems which meet all of them.
Continuous data logging at 500Khz constitutes a
serious challenge for even the most modern systems.
The principle problem with acquisition at these rates
is the bottleneck caused by poor data transfer band-
width (especially disk transfer rates). As high per-
formance techniques such as high speed double-width
buses and disk striping migrate down from high per-
formance computers, this problem will dissipate. To
date there is no fatigue control equipment, includ-
ing that described in this article, which has achieved
these kind of sustained performance numbers.
Another important capability is the ability to as-
sign multiple synchronous control channels (channels
on a single test which work in concert) dynamically to
any test station - a capability which allows both great
testing flexibility within the laboratory and complex
tests including environmental control and multiaxial
tests. Many ~ ~ s t e can m scontrol
~ ~ ~multiple
~ ~ chan-
nels in a synchronous manner, but these systems are
generally dedicated to a single structural, component,
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018
or biaxial fatigue test. Only Nowack, et. aL4 men-
tions software with ability to flexibly assign control
channels.
Starting as early as the mid 1970's the cost of
laboratory computers were defrayed by using a single
unit to control multiple test stations - several authors
have used this technique. Minicomputers (primarily
PDP-11) have been used predominantly in multista-
tion test control. Several worker^^^^^^ have developed
software/hardware which variously allowed control of
bet ween two to six servohydraulic test stations, but
newer multistation systems7~*,while using a mini-
computer in a supervisory role, employ a smaller local
satellite computer on each test frame. Other types of
computers have been used in this application: one
group of researchersg relied on a remote main frame
computer (IBM 1800) to provide control for three fa-
tigue stands, and, surprisingly, two instancesl0>l1ex-
ist s of microcomputer managed multistation test con-
trol. The advantages of this technique are centralized
data storage and software development/storage.
In many cases it is convenient to be able to in-
spect the progress of a test remotely and perhaps
modify its operation. If the acquisition and test con-
trol process can interrupt and "reportn to the control
terminal, typically the system console, in case of crit-
ical errors, then that terminal can be used for other
work while the test is going on. Other secondary con-
trol functions, such as data acquisition, test speed
changes etc, are at the discretion of the user. To date
two researchers7p8 have taken advantage of this ap-
proach, and, although neither claims to have remote
control capability, one has the ability to monitor test
progress remotely.
The three frequently used methods to input
variable amplitude histories into test control chan-
nels are the peak-time, peak-valley, and block for-
mats. Older systems typically rely on a digital
function generator10112 to supply the waveform, but
newer systems generate waveforms internally7~8~11.
~ e d i c a t e d l 7 land
~ multistation4p5 systems both ac-
cept the peak-time format where the waveform is de-
fined by a series of ramps and holds. These waveform
"building blocks" can be used to generate any arbi-
trary waveform. An alternate history format is the
peak-valley which consists of a list of ramp end point
values with no timebase, and the systems which em-
ploy this format either control the ramp rate14 or use
adaptive control algorithms15 to ensure proper hy-
draulic performance. The final common input form
is the block loading method which is akin to the peak
valley, but for each closed excursion between two end-
points a repetition count is added. Markov matrices4
are frequently used, and are similar to the peak-
valley, but define excursions by a start-level/end-
level sequence or a "from-to matrix" form. Typi-
cally markov matrices are converted into peak-valley
or block loading waveforms before being used in test-
ing. The greatest drawback with markov matrix and
block loading schemes is that the original cycle order
2
is usually lost. It is very convenient to have a system
which can accept all of the above formats so that load
histories developed by differing organizations can be
applied to specimens/structures with little modifica-
tion. The majority of fatigue testing systems take
only a single format and this renders them less useful
in the automotive fatigue testing environment.
Hardware Selection
Although each laboratory has different testing
requirements, the hardware platform has been usu-
ally selected from either mini-computers such as the
PDP-11 and Eclipse, or, more recently, from rnicro-
computers, usually the PC clone.
Minicomputers still retain certain advantages
over less expensive microcomputers. Although
the initial costs associated with minicomputers are
greater, their use for data acquisition on multiple test
stations can reduce the cost per test station to be-
low that of dedicated microcomputers. Other advan-
tages of the minicomputer are the ability to access
the system from locations other than the system con-
sole and prioritized scheduling which allows simulta-
neous independent data analysis and data acquisition
as well as leaving any excess processing time available
for other uses. Finally, the sophistication of modern
multiuser-multitasking operating systems allow pro-
gramming complexity not yet available on microcom-
puters.
Many test control/acquisition computers (PC
type) are single process oriented. Most minicomputer
test controllers are also limited to a single process
or background/foreground process. The newer work-
stations, on the other hand, are multi process ma-
chines, with potentially many users and logins possi-
ble. A test computer that is integrated in this type of
distributed environment has many more advantages.
Test waveforms, and control programs can be trans-
mitted to it, control can be done from remote loca-
tions, and data processing/display can be systemati-
cally off-loaded to more convenient locations or ma-
chines. Many of these functions are very difficult, at
best, to implement on a microcomputer but easily
implemented on a minicomputer.
Further, hardware requirements in our fatigue
laboratory substantially limited the available plat-
form choices. The wide range of experiment types
necessitated that the computer have very high data
acquisition throughput, especially if multiple test sta-
tions are involved. In the mid 1980's there were no
high throughput data acquisition boards available for
microcomputers, but minicomputer equipment did
exist which provided sufficient capabilities. Thus the
platform selected for use (MassComp 5450t) was a
Motorola 68020 Unix* based minicomputer.
t Registered trademark of Concurrent Computer
Corp.
* Registered trademark of Novel1 Corporation.
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018
Clearly demonstrated by its architecture, shown
in Figure 1, this machine was designed specifically
for high data throughput and short latencies (the
time between the occurence of an event and the com-
puter's reaction t o it); hence a data acquisition com-
puter. The processing Yoad" on the primary proces-
sor is reduced by the addition of an interrupt driven
dedicated data acquisition control processor (DACP)
which handles direct communication with the vari-
ous converters, clocks, and parallel communication
lines attached t o the STD bus. The DACP commu-
nicates with the primary processor via direct memory
access (DMA) through first the Multibus, and finally
through the Host-Memory Interconnect Bus (HMIB).
In this arrangement the hardware is capable of ana-
log to digital (a/d) conversion rates of lMHz - a limit
imposed by the performance of the DACP. Hardware
for graphics and extra terminals are placed on the
Multibus, while RAM, disk i/o, Ethernet, and float-
ing point array processors are placed on the HMIB.
Only in the last couple of years have microcomputer
manufacturers begun to incorporate similar design
philosophies into their hardware.
The computer's external signal section contains
all of the necessary primary data acquisition hard-
ware. There are two configurations currently being
used in the laboratory. The first contains: 16 single
ended, 12 bit, 330KHz a/d converters; two 275KHz,
12 bit digital t o analog (d/a) converters; 16 bit par-
allel digital i/o capable of a 250K words/sec bidirec-
tional transfer; and 5 clocks with a frequency range
from O.01Hz to 3MHz. The second configuration con-
tains: 16 single ended, 12 bit, 1MHz a/d converters;
four 500KHz, 12 bit d/a converters; 16 bit parallel
digital i/o capable of 350K words/sec bidirectional
transfer; 10 clocks with the same frequency range as
above; and an IEEE-488 interface which can control
up to 14 GPIB devices.
For interactive data analysis/display the graphi-
cal capabilities of the system include a 1152x910 pixel
color display with dedicated graphics processor with
12 planes of memory and a Tektronix 4014 graphics
terminal. Other equipment includes a 1Gb of disk
space, 8Mb of RAM, four RS-232 ports, a 150Mb
cartridge tape, and an ethernet connection.
Software Platform
The operating system incorporates both AT&T
System V Unix and Berkeley Software Distribution
(BSD) 4.2 Unix into a real-time unix platform. Users
determine which "universe" they want to operate in
- easily switching between universes, and programs
compiled in either universe can be executed in both.
This allows the programmer to incorporate the best
features of both flavors of Unix into their code. Pro-
grams can be written in either C or FORTRAN or
any admixture of both, and software debugging and
optimization are provided as well.
3
A data acquisition library accompanies the sys-
tem which provides well over 100 subroutines for con-
trolling the various devices. This software is predi-
cated on the use of buffered transfers, and for the ma-
jority of data acquisition tasks this approach works
well. However, one must occasionally avoid buffering
and it is possible to circumvent this problem with
minor modifications of the DACP microcode drivers.
The software addressed in this paper was written
in a combination of FORTRAN(80%), C (lo%), and
DACP assembly language (10%).
Test Control Software
Overview
The software can dynamically assign control
channels to multiple test stations. A user can start a
test and then logout of the computer, and all critical
errors will be reported to a console, and/or electron-
ically mailed to a particular network location. The
user can, at any time, log back into the system and
acquire immediate status reports, perform some data
acquisition functions, or schedule such procedures at
future points in time. Typically, although not neces-
sarily, acquired data sets are transmitted across the
network and analyzed on another workstation. Gen-
erally the capacity of the test control workstation is
sufficient to both control a complex test and to per-
form data analysis, but the convenience ~f data anal-
ysis in one's own office, rather than the test lab, is
quite a popular feature.
Background Terminology
Shared Memory is an integral part of the con-
trol program, and it is a feature of AT&T UNIX
which allows any number of processes to access the
same memory segment. This allows a command and
control block of memory to be defined which per-
mits other processes running on the computer to in-
telligently interact with the control program. Since
shared memory usage is non-deterministic - any pro-
cess with the proper permissions may access and
change the data within it at any time - it is locked
into physical memory by the operating system to pre-
vent it from being swapped to disk. This locking fea-
ture ensures immediate access by the real time test
control program.
Asynchronous System Traps (AST's) are the
software analog of hardware interrupts. These are
used by the data acquisition processes for data buffer-
ing and program control. In a fashion similar to hard-
ware interrupts, AST's carry a maskable priority level
and require a handler, but, unlike hardware inter-
rupts, they carry a value as well. Hence, AST's allow
the various parts of the program to be prioritized ac-
cording to their level of importance to the test. For
instance, the interlock monitor software may be given
a very high AST priority so that it will interrupt all
but the most crucial processing so that the computer
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018
will analyze the problem at hand. During the pro-
cessing of the current AST the process changes the
mask so that only AST's of higher priority than the
one currently being processed may interrupt. The
ultimate advantage of AST's is that they are much
more flexible than conventional hardware interrupts.
Background Process is a process which executes
without any user interaction leaving the user the abil-
ity to perform other tasks on the terminal while the
process is running. The original user who invoked
the background process may reattach it to the shell
(move it to the foreground). A shell is the command
line interpreter used by the computer to interpret user
input -in Unix the programs which perform this task
are typically either the Bourne shell (sh) or the "Cn
shell (csh). In the interim the user can logout, leave
the test area, and login again from any other location
on the network. Once logged out the background pro-
cess continues, and, although it cannot be reattached
to a shell, it does continue to report errors to the
original terminal.
Main Progmm
The main program, called the fatigue test dae-
mon, or "ftestd," is subdivided into several indepen-
dent operating sections of varying priority. These sec-
tions handle user requests/control changes, analog to
digital control, and digital to analog buffer mainte-
nance.
The ftestd program initially loads itself as a back-
ground process, requests a very high priority level -
slightly lower than the system process scheduler - and
creates and attaches the shared memory segments.
After filling the d/a buffers with zeros, ftestd starts
up the d/a and interlock (alarm) monitor processes,
and, finally, it enters the main test control loop (see
below). All state changes (history reset, etc.) and re-
coverable errors are logged to a transcript file during
the test.
The test or operation control loop consists of
program units that perform requested state changes.
.
Several of these commands (such as load, .rset,
etc.) require significant processing on the part of
ftestd hence slowing the response to the user. The
process interaction is depicted in the left of Figure 2.
As the ftestd program progresses through each de-
cision point it checks a different control variable lo-
cated in the shared memory segment, and performs
the appropriate control actions. For instance, if the
KSAVE logical variable, which indicates whether or
not a restart file should be saved, is set, either by an
external or internal source, ftestd saves the appropri-
ate data to the restart file. This file can then be used
later to restart the test in case it has been interrupted
by a power fault or similar occurrence. Once ftestd
has made a pass through the various decision points
it "sleeps" or waits for the next AST signal from the
DACP interface to arrive and wake it up. This pause
is for a maximum of 10 seconds after which time the
4
main program will go check on the system. This ap-
proach offloads the bulk of the work on to the DACP
and results in about a 10% load on the CPU. The
remaining CPU time is utilized by other programs or
users to perform other tasks.
Each time the Digital to Analog converters con-
vert enough values to fill one buffer of samples the
DACP sends an AST signal to ftestd. The CPU then
suspends all processing, including the management
of the operational control loop, to execute the out-
bound buffer completion routine. The first duty the
routine performs is a poll of the test interlocks, and,
if those are set, the current software and test state
is saved to disk and a stop command is issued in-
ternally, halting history replay. Otherwise, if the in-
terlocks are clear, this routine fills the buffer with
the next set of d/a values, processes any user com-
mands which require execution while in this routine,
and then exits. Any suspended user processes (data
analysis, etc.) resumes. Meanwhile, the DACP plays
the output voltage buffer to the test specimen. This
pattern is followed by all of the functions which em-
ploy buffered transfers.
The variables in shared memory which dictate
the control changes in ftestd can be modified by two
methods. The first is a status/control program, called
GLstun," (so named because it gives ftestd orders)
which accesses the control switches via shared mem-
ory and can be invoked in either interactive or single
command mode. This program enables any user to
read and modify shared memory, much like a sta-
tus/control instrument panel, or to write intelligent
batch processing files for automatic process control.
The second control method is t o embed ftestd com-
mands in the input history - these "embeddedn com-
mands are only executed before a test start.
User Interface - Status/Control Program
The foreground control program, called "stun,"
runs only long enough to change the operation of
ftestd by writing commands to the variables in the
control program's shared memory space. Stun runs
either as a single command line interpreter or an in-
teractive control system.
When invoked stun attaches shared memory, per-
forms a brief status check, writes the status to the
screen, and, if invoked interactively, issues a prompt.
All successful commands are then logged to a file with
status changes noted. Once the appropriate shared
memory values are changed, the remaining process-
ing is performed by ftestd. Before any changes are
made, however, stun checks the current state of the
control system to ensure that no untoward control
conflicts/problems develop. The commands in stun,
listed in the section entitled "Command Set," are
generally those which affect the operation of the his-
tory as it is being replayed, and a typical interactive
session with stun is shown in Figure 3.
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018
Embedded Commands: Before test startup the
file containing the history, called a urunfile,n is loaded
into memory by ftestd. A limited set of commands
can be embedded in the header of this runfde (see
the section entitled URunfile Structuren). Typically,
the commands accessible in runfdes are those which
modify the history itself (scaling, offsets, etc. - com-
mands which become repetitive and tedious i invoked
manually (via stun) each time the history is used. A
1 reside and a data section where the numerical descrip-
list of commands and their function is given in the
following section.
Command Set
All commands start with a "." and are three or
four letters long - any other permutation is consid-
ered a comment by both stun and the embedded com-
mand interpreter. Interactive commands are labelled
with an "(')", embedded commands are labelled with
an "(4)" and those commands which belong to both
command sets are labelled with an "('re)". With the
.
exception of the " AXITn command any of the com-
mands can be entered in either upper or lower case.
Examples of the available commands follow (a com-
plete list can be found in Appendix A):
.run Start history playback.(i~e)
.s t o p Stop history playback.(i)
. s t a t Status of d/a and other run-time infor-
mation. Entire status display is written
to the log file.(')
.r s e t Stop history playback if running, zero
output, load histories from a datafile,
and reinitialize control variables. This
command causes ftestd to process any
embedd?8 commands found in the
runfiles.
The commands which are most commonly
found in runfiles are as follows:
.t y p e Type of history in this file - block,
peak-time, peak-valley.(e)
.mult Set history multiplier.(")
.mean Set history mean offset .(")
. b a s t Set base time step (for peak-time
histories).(e)
^END Indicates end of header section Q
history file - history data follows.("
4
. s a v e Saves current run con ition of test and
ftestd to a restart file.('
. load Loads old run condition of test and ftestd
from a restart file.(')
.b s t p Stops history playback after the end of
the designated repetition.(')
. bgo Countermands ".bstpV operation.(')
.cmd Loads and runs commands from a file.(')
.AXIT Emergency exit - cleanly shuts down
both ftestd and stun at once.(')
q u i t Exit interactive stun.(')
Runfile Structue and History Requiements
Runfiles are history input files which ftestdloads
into memory for later history replay. A runfile with a
typical sequence of embedded commands is shown in
Figure 4. Runfiles have two sections - a header sec-
tion where the embedded commands and comments
tion of the history is found. The header section of the
runfile starts at the first line and proceeds to the line
containing "^END",and the history data begins after
it. The data file is loaded into memory once r s e t.
is issued. Ftestd first reads the embedded commands
which inform ftestd of the history type, set the history
multiplier, set the base time step, etc. The actual for-
mat of the numerical history description varies with
the history type, and all runfiles are in ASCII format
such that a user can easily read and edit all parts of
the file.
The one principle requirement for the input his-
tories is that they must begin and end at the same
level, but this is not unique as most variable am-
plitude fatigue testing programs have the same re-
quirement. After scaling and offsets take effect the
final output, in d/a converter units, must be in the
range -2048 5 x 5 2047. When servicing buffers the
program checks that the output remains within this
range, and, if either limit is exceeded, shuts down the
history playback for that test station, and prints an
error to the system console.
The maximum slew rate (converter units per sec-
ond) can be adjusted by the following methods. In
both block and peak-valley history types a maximum
voltage step size per time increment may be specified
.
via the vdel command. In the peak-time histories
hydraulic response is improved via the .espk com-
mand. This command accepts a start time, an end
time, and a timebase multiplier. The multiplier ef-
fectively changes the D/A data rate and allows the
slew rate to be decreased for a specific section of the
history, after which test conditions return to normal.
Typical Usage
Initially ftestd runs without user interaction as a
background process, and, once it is operating, stun
can be started interactively. Referring again to Fig-
f ure 3, the first task is to load the history into memory
with the . r s e t command. Since embedded com-
mands are almost always found in the history in-
put files, ftestd executes these commands next. Fig-
. .
ure 4 is a good example. Here the t y p e , mult ,
. b a s t , and .espk commands are executed in the
order found in the file. Next, in the interactive ses-
sion, the a/d monitors are started with the .upad
command (operation of these are covered in the next
section) and history replay is started with .run. If a
restart file exist from an older test then .1oad could
also be used to reload the earlier values of the run-
time variables.
History playback can be paused at any time via
the . s t o p command, or it can be paused at the end
5
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018
of a complete history repetition through the b s t p or .
.
block stop command. The bgo command eliminates
the effect of the block stop. The .dnad shuts down
the a/d software monitors releasing the a/d hardware
to another process should a continuous data recording
by an external acquisition program.
A/D Monitors
Frequently it is convenient to log the peak values
of the various signals (loads, strokes, strains, errors,
etc.) associated with the test. The repetition time
between the peak value of these signals, depending
on the history, can occur at widely disparate times
- sometimes as much as 70 minutes apart. One can
use these peak values to monitor specimen behaviour
such as cyclic hardeninglsoftening and overall speci-
men compliance. Also it can be useful having values
of these signals when the specimen is at "rest" during
the brief period (5 seconds maximum) between his-
tory replays to help detect ratchetting. An external
program can then monitor these values, and if they
exceed certain established limits use stun to change
or stop the test (See "External Programs"). These
features are used to detect changes in specimen com-
pliance or strain gage degeneration.
When the ftestd a/d subsystem is activated
( .upad) a set of these simple a/d monitors is in-
stalled in the DACP. This modified DACP microcode
returns a set of high and low values for each channel
after each repetition has been completed. Between
repetitions the command level of the history must re-
turn to zero, and, if enough time is available at the
zero level, the DACP takes two 16 point averages of
the rest or "zero" levels of the feedback lines and re-
turns the averages to ftestd. This information is used
to track mean drift in specimens which experience
torsional strain ratchetting. Both the high value, low
value, and "zero" value data are simply logged into a
file by an inbound buffer completion routine.
Interlock Monitors
The DACP also monitors up to 16 TTL compat-
ible interlock signals at a selectable frequency (usu-
ally 2Hz) and posts the values of the interlocks di-
rectly into the shared memory control segment which
ftestd monitors. This allows ftestd as well as any
ancillary programs (such as the a/d acquisition rou-
tines) to monitor system alarm status. For exam-
ple ftestd checks the servohydraulic interlock status
words in shared memory and, if an interlock has
tripped, it saves the operational parameters (e.g. rep-
etition count, the current history pointer, etc.) to
disk, shuts down the acquisition/control processes for
the affected control channels, and waits for new com-
mands.
6
External Progmms
Certain functions which are not critical to the
operation of the testing program fall into one of two
categories - active and passive. An active task is any
external task which directly manipulates acquisition
or control hardware and, hence, must run at a reason-
ably high priority level (to get it more attention than
mundane system or user tasks). The prime example
of this is the external program which takes hysteresis
loops (or other data) directly from the a/d converters
and can access both the data buffers and the control
shared memory segments which ftestd uses.
Passive programs do not interact with acquisition
hardware and run at an lower priority than active pro-
grams. However, they use data that has already been
processed and is available in log files or through access
with the ftestd shared memory. An example of a rou-
tine passive task is a specimen compliance watchdog
which analyzes the high/low/zero log files from a/d
monitor system and mails the analysis results to the
user or shuts down the test if some criterion is met.
Such a process may in fact be a shell script or "batchn
execution file that invokes the non-interactive version
.
of stun and uses the output from the st a t command
to make decisions about manipulating the test. Cur-
rently the scripts which run these tasks are executed
by the Unix "cron" automatic facility for timed exe-
cution.
One example of a cron driven process is a script
called "watch" which checks the high/low peak file
to see if any of the values have exceeded either a
warning or a stop level. If the test signal has ex-
ceeded a warning level a message is mailed to the
appropriate test operator concerning this fact. If the
test has exceeded the stop level the command "stun
.b s t p " is issued and a message mailed. In this way
the activation of the hard interlocks on the hydraulic
controllers with their associated hydraulic transients
is anticipated and avoided. This script is executed
by cron at least twice during each repetition of the
history in order t o ensure that the data from each
repetition is examined - i.e. if the history takes 70
minutes to run then the script is set to execute every
half-hour.
Future Modifications
The next version of the stun will provide a full
screen menu driven version of the stun interface for
ascii crt's. This will not constrain users in their choice
of terminals as long as the definition for that terminal
is in the acquisition computer's database which, in
Unix systems, is quite extensive. Another aim is to
create an interactive program to help designldebug
test histories, and finally to migrate the program suite
to a different platform (perhaps a RISC architecture
Unix computer).
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

An Example either the acquisition computer or the company net-

The SAE bendingltorsion load frame16 (see Fig- work.
ure 5) produces bending in a specimen by operat- The system has been used for both constant and
ing both actuators with the same signal, and it pro- variable amplitude testing on both unixial and mul-
duces torsion by operating the actuators with signals tiaxial test frames with success over the last three
of equal magnitude but opposite sign. As a result years.
special calculations were necessary to generate the
loading sequences for each actuator since the multi-
axial input histories were in a bending and torsion
format. A code module performing these superposi-
tions was written and inserted into ftestd, and two
control channels were linked together to drive the ac-
tuators.
The runfiles for the service history (see Figure 6)
were quite large - the bending file was 1160kbytes
(109419 points) and the torsion was 774kbytes (73348
points). Since the size of the history files was consid-
erable special techniques for "debugging" the histo-
ries had to be developed. Debugging the histories
consisted of locating portions of the history where
non-real events such as drop-outs, calibration marks,
aberant noise spikes, etc. occurred. One component
of this work was pursued using ftestd's history debug-
ging features (see Appendix A), a dummy specimen,
and the test rig.
The specimen tested was the SAE axle shaft1'
(Figure 7). As shown in the figure a small strain
rosette was placed at the critical point in the spec-
imen notch, and as the test progressed ftestd would
monitor these strains as well as other actuator sig-
nals. The a/d monitors were able to track the even-
tual breakdown of the strain gages in the rosette (Fig-
ure 8), provide useful experimental data (Figure 9) on
material behaviour, and specimen ratchetting (Fig-
ure 10) was derived from the stroke signals. At se-
lected intervals the a/d channels were reassigned to
scan all values in a complete block of data. The notch
strain histories (Figure 11) caused by the input load
history were recorded. These strain rosette histo-
ries were subsequently used as in uts to a multiaxial
stress-strain modelling program 18 .
Summary
A computer program was developed which has
successfully met the requirements for fatigue testing
in the laboratory. The requirements for this program
were that it should 1) operate multiple test frames
independently, 2) be able to dynamically assign any
number of control and acquisition channels to any
given test, 3) operate from any terminal (remote or
otherwise), 4) manipulate and replay the principle
durability history forms, and 5) have graphical dis-
play capabilities.
The hardware and programs described in this pa-
per achieved these requirements on a Unix platform.
The system is accessible through an interface pro-
gram and judicously uses a single front end data ac-
quisition processor. Test update and control can be
performed from any terminal (and data analysis from
any suitable graphics terminal) connected directly to
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

References 12. Sooley, P. M., and Hoeppner, D. W. 'Low-

1. Boggs, B. C., Mondol, N. K., McQuown,
R. E., and Anderson, J. G. 'Digital and An&
log computer Equipment and Its Application to
In-House Testing' ASTM STP 619 (American
Society for Testing and Materials, 1976) pp 2-26
2. Ewing, D. K. 'Computer-based full scale fa-
tigue' Int J Fatigue 1 No 2 (1979) pp 89-92
3. Downing, S. D., and Galliart, D. R. 'A Fa-
tigue Test System for a Notched Shaft in Com-
bined Bending and Torsion' ASTM STP 853
(American Society for Testing and Materials,
1985) pp 24-36
4. Nowack, H., Hanschmann, D., Baumhoff,
N., and Jacoby, G. 'Developments in hard-
ware and software for computer controlled servo-
hydraulic fatigue testing systems' Int J Fatigue
1 No 2 (1979) pp 93-102
Cost Microprocessor-Based Data Acquisition and
Control System for Fatigue Crack Growth Test-
ing' ASTM STP 877 (American Society for Test-
ing and Materials, 1985) pp 101-117
13. Fleck, N. A., and Hooley, T. 'Development
of Low Cost Computer Control' SEE Conf - Int
Conf on Digit Tech in Fatigue (Society of Envi-
ronmental Engineers, 1983) pp 309-316
14. Richards, F. D. 'A New Software Concept
for Computerized Materials Testing' ASTM STP
613 (American Society for Testing and Materials,
1976) pp 50-60
15. Pompetzki, M. A., Saper, R. H., and Top-
per, T . H. 'Software for High Frequency Control
of Variable Amplitude fatigue Tests' Canadian
Met Quart 25 No 2 (1986) pp 181-194
16. Leese, G., and Socie, D. Multiaxial Fatigue:
Analysis and Experiments, SAE AE14, 1989

5. Utah, D., and Malik, H. J. 'Use of Multista- 17. Bonnen, J. J. F., Conle, F. A., and
tion Computer System for Laboratory Data Ac- Chu, C.-C. 'Biaxial Torsion-Bending Fatigue of
quitision and Control' ASTM STP 613 (Ameri- SAE Axle Shafts' 1991 SAE Transactions, SAE
can Society for Testing and Materials, 1976) pp reprint #910164, February 1991
61-77 18. Chu, C.-C., Conle, F. A., and Bonnen, J.
6. Nisar, R. 'Hardware for a General Purpose Ma- J. F. 'Multiaxial Stress-Strain Modeling and Fa-
terials Testing Computer System Using a Dis- tigue Life Prediction of SAE Axle Shafts,' Sym-
tributed P a r d e l Processing Architecture' ASTM posium on Multiaxial Fatigue, ASTM STP 1191,
STP 710 (American Society for Testing and Ma- pp. 37-54, 1993.
terials, 1980) pp 48-57
7. Sunder, R. 'Automated Fatigue and Fracture
Laboratory with Multiple Load Frames and Sin-
gle Host Computer System' ASTM STP 1092
(American Society for Testing and Materials,
1990) pp 232-249
8. McGaw, M. A., and Bonacuse, P. J. 'Au-
tomation software for a Materials Testing Labo-
ratory' ASTM STP 1092 (American Society for
Testing and Materials, 1990) pp 211-231
9. Lim, C. K., Kuklentz, R. J. 'Application of
the Digital computer t o an Accelerated Fatigue
Model' ASTM STP 613 (American Society for
Testing and Materials, 1976) pp 126-141
10. Meyn, D. A., Moore, P. G., Bayles, R. A.,
and Denney, P. E. 'An Inexpensive, Multiple-
Experiment Monitoring, Recording, and Control
System' ASTM STP 877 (American Society for
Testing and Materials, 1985) pp 27-43
11. Austen, I. M., and Holdsworth, K. 'New
developments in the computer control of fatigue
machines' Int Conf Fatigue Eng Mater Struct
(Institution of Mechanical Engineers, 1986) 2 pp
485-493
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

Appendix A .save Saves current run condition of ftestd to

a restart file.(')
Command Set .load Loads old run condition of ftestd from a
All commands start with a "." and are three or restart file.(')
four letters long - any other permutation is consid- . b s t p Stops history playback after the end of
ered a comment by both stun and the embedded com- the designated repetition.(')
mand interpreter. Interactive commands are labelled
with an "(')", embedded commands are labelled with .
bgo Countermands " .bstpWoperation.(')
an "(4)" and those commands which belong to both .upad Brings the a/d converters on-line.(')
command sets are labelled with an "('se)".
able commands are:
The avail- .dnad Halts the a/d converters.(')

.run Start history playback.(i~e) .wron Write current a/d values to screen.(')
. s t o p Stop history playback.(i) .wrof Shuts off a/d screen writes.(')
. s t a t Status of d/a and other run-time infor- . AXIT Emergency exit - shuts down both ftestd
mation. Entire status display is written and stun at once.(')
to the log file.(') q u i t Exit stun.(')
.st ad Status of a/d.(') .lgon Log peak-time information to a file. His-
tory debugging command.(')
.s t i n Status of interlocks.(')
.l g o f Stop peak-time log. History debugging
.r s e t Stop history playback if running, zero
command.(')
output, load histories from the datafile,
and reinitialize control variables.(') It is .inon Enable interlock auto-shutdown.(')
this command which processes any em- .inof Disable interlock auto-shutdown.(')
bedded commands found in the runfiles. .h l o g Write histories resident in RAM to out-
The commands which are most com- put files.(')
monly found in runfiles are as follows:
. t y p e Type of history in this file - block,
. hlon Write superimposed biaxial control his-
tories to files.(')
peak-time, peak-~alley.(~)
.h l o f Stop .hlon.(')
.v o l t Set starting voltage.('Ie) .peek Read a value from the control shared
.mult Set history multiplier.(e) memory segment. System debugging
.mean Set history mean offset.(e) command.(')
. b a s t Set base time step (for peak-time .poke Put a value into the control shared
histories).(") memory segment. System debugging
command.(')
.espk Literally expand-spike. Indicates a
.time Load ptv time values. History debugging
list will follow containing informa-
tion concerning the portions of the command.(')
history for which the base time step . i c u r Change current " .espk" segment. His-
should be temporarily reduced (for tory debugging command.(')
peak-time histories).(e) .cmd Execute the stun commands found in
^END Indicates end of header section of filename.(')
history file - history data follows.(") . r e p Set the total repetition counters.(')
.j blk Sets current history pointers. These . n i c e Change the run time priority of stun.(')
pointers indicate the position of the test ! Shell escape and command.(')
within the history.('Ie)
. v d e l Sets voltage step size. For block
hist ories.('te)
.t d e l Sets time step size. For block
histories.('Ie)
. h o l d Sets peak hold time. For block
histories.('+)
. cyc Sets several history playback variables
(for debugging histories).(')
9
Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

i
load restart file?
L

fl save restart file?

J
iJ
a 8 ~
Initialization
G58
5 0 ~
a0
load DACP microcode 0

set priority
set up shared memory
open log file
initialize d/a, ttl ilo,
and clocks
start interlock monitor
start dla's

shared memory
re1ease

Figure 2. Program flow within the ftestd program.

 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

% stun 12
s t u n a c t i v a t e d f o r c o n t r o l c h a n n e l s 1, 2 ,
s t u n : .met
f t e s t d : h i s t o r y t y e p t v s e t f o r channel 1
!
f t e s t d : h i s t o r y mu t i p l i e r s e t t o 5 . 3 5 7 ~
f t e s t d : b a s e t i m e s t e p s e t t o 2x
f t e s t d : 6 expand s p i k e e n t r i e s l o
Yed
f t e s t d : r u n f i l e f o r channel 1 h a s een r e s e t
f t e s t d : h i s t o r y t y e p t v set f o r channel 2
f
f t e s t d : h i s t o r y mu t i p l i e r s e t t o 4 . 7 2 6 ~
f t e s t d : b a s e t i m e s t e p s e t t o 2x
f t e s t d : 6 expand s p i k e e n t r i e s l o
qed
f t e s t d : r u n f i l e f o r channel 2 h a s een r e s e t
s t u n : .load
f t e s t d : c h a n n e l s 1,- 2 ,- r e s t a r t f i l e l o a d e d .
s t u n : .upad
f t e s t d : a / d s u b p r o c e s s o r running a t 1000.00Hz/channel.
s t u n : .inon
f t e s t d : 2.00Hz i n t e r l o c k m o n i t o r s a c t i v a t e d f o r channels 1, 2,
s t u n : .run
f t e s t d : c h a n n e l s 1, 2 , now running
s t u n : .bstp 300
block s t o p s e t f o r block 300 f o r channels 1, 2,
s t u n : .stat
Wed Jun 3 04:00:05 1992
d/a # 1 2
h i s t type PtV P tV
r u n / s t op run run
st a t u s run run
blk stop no no
reset no no
error no no
jb l k a 179243 98802
198887 111930
i::k:ep
o l d vo t
2098
-137
2098
-159
v delt 1 1
base t 2 2
t unit 2 2
slow? true true
ic u r 89 89
old time 1352663.50000000 1352663.50000000
s t u n : .dnad
f t e s t d : a/d subprocessing system s h u t down.
s t u n : .run
f t e s t d : c h a n n e l s 1, 2 , now r u n n i n g
s t u n : !adpvtlQ.saw p a r
a d p v t : d a t a acq. s t a r t -- f i l e biaxgsr7.300 done ...
s t u n : .upad
f t e s t d : a/d s u b p r o c e s s o r running a t 1000.00Hz/channel.
s t u n : quit
% logout
Figure 3. Ty lcal stun pro ram session for a two control channel test. User inputs are in bold face,
E' %
rep 'es from ftest are prefixed with "f t e s t d :" , and replies from stun are not prefixed. The
embedded commands processed by ".rset" represent two runfile files similar to that found
in Figure 4. The text of the session has been modified in order to clarify interaction with the
programs - typically the responses from ftestd do not arrive instantaneously and, hence, are
somewhat out of order with the command input.
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

.type ptv
* H i s t o r y t y p e must be d e f i n e d f i r s t -- h e r e peak-time-valley.
*
.mult 5.357
* A l l h i s t o r y amplitude v a l u e s (2nd column of h i s t o r y d a t a )
* w i l l be m u l t i p l i e d by t h e f o l l o w i n g f a c t o r .
*
.bast 2
* Here t h e timebase (1st column of h i s t o r y d a t a ) i s
* m u l t i p l i e d by two f o r t h e purposed of r e p l a y .
*
.espk 6
98322 98448 2
167778 167804 4
361853 362066 8
435572 435910 2
764420 764450 16
1019337 1019678 2
* The espk command i s followed by a count which i n d i c a t e s
* t h e number of espk e n t r i e s t o be found a f t e r i t . Each
* e n t r y c o n s i s t s of t h e s t a r t time, endtime, and timebase
* m u l t i p l i e r f o r t h a t p o r t i o n of t h e time h i s t o r y .
*
* A f t e r t h e ^END f o l l o w s t h e a c t u a l h i s t o r y d a t a . The
* f i r s t column i s t h e timestamp and t h e second i s t h e
* amplitude.
^END
1 0
52 6
62 6
499 -5
1127 -5
1451 28
1571 28

1043703 27
1043750 27
1044646 -16
1044693 -16
1044725 0

Figure 4. Typical layout and structure of a history runfile.

 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

Figure 5. Detail of SAE bending-torsion fixture.

Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

Figure 6. Log Skidder history.

Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018
1000 1 Test 7
Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

Blocks
Figure 8. Strains measured in SAE 1045 steel after completion of each block of Log
Skidder bending-torsion history.
Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

La,
Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018
 Downloaded from SAE International by North Carolina State Univ, Sunday, September 16, 2018

Figure 11. Single block of rosette strains taken from notch on

SAE 1045 bending-torsion specimen