Running the SDSC Shake table
Paul Hubbard
hubbard@sdsc.edu
Revision history
1.0 12/13/2004 Initial posting
1.1 12/15/2004 Many corrections
Purpose
This document aims to instruct NEESit people at SDSC how to run the
Anco shaketable for demos and such. As such, it skips over some steps
and omits others. If I've missed something or left out essentials,
please email me at the address above.
Introduction and Background
As of October 2004, SDSC inherited the Anco-brand shake table
from Argonne, and put it into
the basement of SDSC in room B02. (Keys for B02 are available from SDSC
admin staff) This is
a single-axis unit intended for demos and small-scale testing, such
that we can verify code, train users, etc.
It's worth noting that many implementation decisions have been made
assuming that this is a demo unit, and not for science. For example,
the position sensor has smaller range than the full stroke, and has
non-shielded wiring. The PID loop needs to be further tuned to reduce
overshoot and ringing. If you want to do real science, expect to do
more work.
About the Hardware
So what, you ask, is a
shake table?
A shake table is mainly used to replicate earthquakes for the purposes
of testing structures and materials. They see other uses in industry;
the auto biz uses them for noise and vibration testing sometimes.
Depending on your budget, they have 1-6 axes of movement, varying
acceleration, load capacity, stroke, etc.
This unit is relatively simple and cheap. It's a model R501 from Anco,
with a single-axis linear motor and approximate force of 200lbs. Stroke
is about 30cm. It's powered by 220VAC at 20 amps. The control system
(more on this later) is an analog input denoting force.
If you want to replay an earthquake, you'll usually start with data
like this:
This is from the
1971 Sylmar earthquake. Why, you ask, is it in the section on
hardware?
Because its a nice segue into the control hardware. Consider: Our sole
control is force. As shipped, there are no sensors on the table. Without
some way to measure position, acceleration or veloctity, the table is
useless. So I added a position sensor, in the form of a BEI
Duncan 15cm DCDT. Have a look at the edge of the table closest to
you in this picture:
and you can see the sensor. It's fed by a bench power supply that sits
beneath the table:
The DCDT power supply is the black one on the left. It's set for 9VDC,
though we may replace it with a +- 10VDC
supply to get better resolution.
You need to make sure that both power supplies show power, or you'll
have problems running the software.
While we're still on hardware, note that the beige box is a 'torque
amplifier' used to control and drive the table motor. In general, this
is totally hands-off. If you need to reset it, (carefully!) pull the
plug from the wall to do so. It's the big 3-prong 220 plug on the right:
Be very careful when doing
so. 220VAC is very hazardous indeed!
The smaller wall-wart supply on the left is also essential - this
powers the OSHA-mandated kill switch. It's the big red button on the
desk:
If the wall wart isn't plugged in, the system will not work. While on
the kill switch, note that you have use two hands to turn it back on;
it latches in the on and off positions. Be cautious, as it is possible
to pull to hard and damage the switch itself.
DAQ hardware and connections
Moving on, I've also added a 2-axis
accelerometer on the back edge of the table:
It's the small board on the right. This is connected to the second
serial port (COM2) on the PC. Since it only moves along one axis, the Y
acceleration data is junk.
Also mounted on the table are three 'lollipop' models, with masses on
flexible stalks. As the table oscillates, these will respond based on
their own natural response frequencies. This is a standard way to
demonstrate resonance and looks kinda cool.
In the kill switch photo, you can also see the DAQ unit. For now, we
are using a Firewire-connected DAQpad 6070E
from National Instruments. It's the laptop-sized box on edge next to
the PC. Connections on it are:
DAC0 (analog output zero) goes to the force input on the torque
amplifier. This is a small cubic black box with a BNC connector:
Input channel one (not zero, for various reasons unrelated to the
table) is connected to the output of the DCDT. You can see the BNC
connection in the power supply photo above. This has a derived channel
in software that converts 0 to 9VDC into +-150mm position via a linear
calibration.
For now, these are the only DAQpad connections. The accelerometer goes
via the serial port.
Control System
Now that we have a table with a position sensor, we can build a control
system. For the initial implementation, I chose to use the classic PID control
method. This is PDE-based control theory, and well understood.
Later on, we have a fuzzy logic
controller that we can drop in to improve the response; for now
it's PID-based.
Gotchas of this approach:
- Never, ever, ever run the
software with the table powered off. If you do, the PID will
attempt to correct the error by increasing the force until it maxes
out. When you do power it on, the table will run full-speed into the
stops. Noisy, scary and hard on the hardware.
- When running, it will hunt around a bit as the algorithm attempts
to minimize the errors. This creates a very irritating noise. I
recommend earplugs.
- This PID implementation needs to be tuned, so the accuracy is
pretty bad.
How to log in to the machine
The code is running on an XP box called shaketable.sdsc.edu. Remote
desktop access is enabled, and I've setup a demo account. Please
contact myself, Shannon or Wei for access.
Running the Software
As with the mini-most, we have four main programs to run:
- Server daemon. This handles data streaming: connection
management, subscribed channel list, DAQ status, and all communications
with the DaqToRbnb program.
- NTCP server daemon. This talks to the NTCP server. Connection
management, parsing, queues, etc.
- Control program. This, upon receipt of an NTCP command, replays
the Sylmar quake on the table.
- DAQ program. This reads the accelerometers and streams the data.
Note that the present version doesn't save data to disk!
Open anco-shaketable.llb:
Note that the 'Function generator.vi' is a copy of the NI-supplied
version, put here for testing. You can use it by itself to drive the
table and test the hardware; it does not depend on any NEES code at all.
Run the control and DAQ programs, then open daemon-programs.llb and run
the NSDS and NTCP daemons. When you've done that it should look
something like this:
How the NTCP triggering works
NTCP is a limited protocol; it cannot handle the sort of requests
needed here, e.g. 'play this earthquake back at 50Hz.' So what we do is
store the quake data in a local text file, and use NTCP to trigger
replaying of it. In particular, 'move the X axis to any non-zero
displacement' is used here.
How to trigger NTCP
There are two present methods, depending on how you want to demo the
table. You can open ntcp-testing.llb and select 'NTCP exerciser -
single move.vi'. Its already preset to request a move on X, so running
it will trigger the quake replay. This is kinda fake, since it bypasses
NTCP/OGSA/etc, but hey! It works. That looks like this:
Secondly, you can use a real NTCP client. The nclient program in the NTCP
tutorial works perfectly for this. Since that's covered there in
depth, I won't repeat it here.
Streaming Data
To stream data and video, you need to have a data turbine running and a
copy of the NEESgrid applications. In particular, you need to run
DaqToRbnb and point it to shaketable.sdsc.edu. See
this page for information.
Assuming that the data turbine is on neespop.sdsc.edu, here's the
command that I use on the neespop:
nohup java org.nees.rbnb.DaqToRbnb -q shaketable.sdsc.edu -n Shaketable -z 10000 >& /dev/null &
The nohup and the redirect mean that it continues to run after I close
the terminal, and its debug output is discarded. Try
java org.nees.rbnb.DaqToRbnb -q shaketable.sdsc.edu -n Shaketable -z 10000
for normal use. Both commands give a nice name ('Shaketable') to the
DAQ, and set the cache to 10,000 points.
Streaming Video
Also in the room are a couple of Axis cameras. You can use the
AxisSource Java program to feed video frames into the Data Turbine
for viewing. See this
outdated page about an old experiment for example usage.
The axis units are neescam1.sdsc.edu and neescam2.sdsc.edu. As of this
revision, only one was online right now due to a missing power supply.
To feed high-res video, I use:
nohup java org.nees.rbnb.AxisSource -S neescam2 -f 15 -z 2500 -A neescam2.sdsc.edu >& /dev/null &
As with data, you can leave off the nohup and the redirect to /dev/null
if you are just running these interactively. This selects high-res
(NTSC, 720 by 408), 15 frames per second, 2500 frames in the cache with
a name of 'neescam2'.
Launching the Data and Video viewer
This is for testing, but you can try the JNLP/webstart link
that Wei has set up. Not guaranteed to work, but if it does you'll
have a data viewer running that starts up a connection to the neespop
at SDSC. The data and video commands above assume that they are running
on the neespop, since the apps by default connect to the turbine on
localhost.
Concluding Remarks
I realize that some of this is rather terse and may not be useful. I
would like to hear from you about what is useful, and what needs to be
expanded. I made several assumptions about the reader, and would
appreciate any feedback or corrections.
