Technical Note · Vibration Control Fundamentals
The Adaptive Control Loop
How a vibration controller keeps a test on profile, the minimum loop time that physics imposes, and why every millisecond of lag beyond that minimum costs speed, accuracy and safety.
Key takeaways
- A vibration controller is an adaptive closed loop: measure the control accelerometers, compare with the reference, correct the drive, and repeat continuously, because the shaker, fixture and test article change during a test.
- The loop cannot be faster than the data it needs. For random control, one spectrum needs T = 1/Δf = lines / bandwidth seconds of data. No processor can shorten that.
- Overlap processing delivers new spectra more often than 1/T, but each spectrum still describes the last T seconds.
- Everything added on top of that minimum is loop lag: acquisition, data transfer, processing and output buffering. Lag forces lower correction gains, slows recovery from changes and causes overshoot.
- Panther computes the control loop on a dedicated FPGA and multi-core ARM real-time processor in the chassis, so the lag added to the physical minimum is kept as small as possible.
Why vibration control has to be adaptive
A shaker does not reproduce its drive signal faithfully. Between the controller's output and the control accelerometer sit the power amplifier, the shaker armature and its suspension, the fixture, and the test article, each with its own resonances and anti-resonances. Their combined frequency response can easily vary by 40 dB across the test band, as shown in our Transmissibility and Resonance notes.
The controller could measure that response once and pre-compensate the drive, but the system does not stay put. Test articles heat, joints loosen, resonances shift, amplifiers drift and nonlinear hardware behaves differently at different levels. So the controller measures and corrects continuously. That repeated measure-compare-correct cycle is the adaptive control loop, and it is the core of every digital vibration controller since Spectral Dynamics introduced the first one in 1969.
What "correcting the drive" means
For random control, the comparison and correction happen line by line across the spectrum. If a line is 2 dB low, its drive is raised; if it is 3 dB high near a resonance, its drive is lowered. The size of each correction is set by a loop gain between 0 and 1: a gain of 1 tries to remove the whole error in one step, a gain of 0.3 removes 30% of it. Higher gain means faster convergence but less tolerance of measurement noise and lag. Figure 2 shows a random test converging from a flat initial drive.
Sine and shock control follow the same principle. In sine, the controller corrects the drive amplitude (and in multi-channel tests, phase) at the current frequency as the sweep proceeds. In shock, it corrects the drive waveform between pulses so that each successive pulse matches the reference more closely.
The physics: the minimum time per loop
A controller cannot correct what it has not measured, and measuring a spectrum takes time. The constraint is the same one described in our FFT Fundamentals note: to separate frequencies Δf apart, you need at least 1/Δf seconds of data.
Three settings determine the minimum loop time:
- Bandwidth (the highest control frequency). For a given number of lines, wider bandwidth means coarser lines and shorter frames.
- Resolution (number of lines). Doubling the lines halves Δf and doubles T.
- Overlap. Starting each new frame before the previous one ends gives spectra more often. With 75% overlap, a new spectrum arrives every T/4.
| Bandwidth | Lines | Δf | Frame duration T | New spectrum every (50% overlap) | New spectrum every (75% overlap) |
|---|---|---|---|---|---|
| 2000 Hz | 400 | 5 Hz | 0.2 s | 100 ms | 50 ms |
| 2000 Hz | 800 | 2.5 Hz | 0.4 s | 200 ms | 100 ms |
| 2000 Hz | 1600 | 1.25 Hz | 0.8 s | 400 ms | 200 ms |
| 2000 Hz | 3200 | 0.625 Hz | 1.6 s | 800 ms | 400 ms |
| 500 Hz | 800 | 0.625 Hz | 1.6 s | 800 ms | 400 ms |
| 200 Hz | 800 | 0.25 Hz | 4.0 s | 2.0 s | 1.0 s |
Two further physical limits sit on top of the frame time:
- Statistics. One frame of random data gives a very rough spectrum. The controller averages frames, and the number of averages sets the statistical accuracy, as explained in our Statistical Degrees of Freedom note. More averaging means a steadier control spectrum but a slower response to real changes.
- The structure itself. A resonance with quality factor Q needs roughly Q cycles to respond fully to a change in drive (see Resonance). At 20 Hz with Q = 25, that is over a second, regardless of the controller.
Overlap shortens the update interval, not the memory. With 75% overlap the controller gets a new spectrum four times as often, but each one still describes the last T seconds of data. A sudden change shows up in the next spectrum only partially, and fully after T. Overlap makes the loop more responsive, and it gives a sharper picture of rapid changes, but it does not remove the 1/Δf limit. Our Overlap Processing note covers the settings in detail.
Beyond the physics: loop lag
The frame time is the irreducible part of the loop. Everything else between "the last sample of the frame arrives" and "the corrected drive reaches the shaker" is lag, and it depends entirely on how the controller is built.
| Source | What causes it | How it is minimized |
|---|---|---|
| Anti-alias and decimation filters | Digital filters in the ADC path delay the signal by a fixed number of samples | Filters designed for low group delay; higher sample rates |
| Data transfer | Moving samples from the acquisition hardware to the processor, often in large buffered packets over USB or Ethernet to a host PC | Processing in the acquisition chassis, close to the converters |
| Processing | FFTs, averaging, the control law and drive synthesis for every channel, every update | Dedicated parallel hardware (FPGA) and real-time processors instead of a general-purpose operating system |
| Scheduling jitter | A desktop operating system can delay a control computation while it services other tasks | Deterministic real-time execution that does not depend on the host PC |
| Output buffering | Drive samples queued ahead of the DAC; a new correction cannot take effect until the queue empties | Short output buffers, made possible by fast, deterministic processing |
Why lag matters
1. Lag limits how hard the loop can correct
A loop with lag acts on old information. If the correction is strong, the controller keeps pushing after the error has already been fixed, overshoots, and corrects back the other way. Beyond a certain gain the loop oscillates and diverges. The maximum stable gain depends only on how many updates of lag there are.
2. Lag slows recovery and causes overshoot
Figure 5 shows the same loop, with the same moderate gain of 0.4, responding to a sudden 6 dB change in the test article, for example a resonance shifting onto a line or a fastener loosening. The only difference between the curves is lag.
| Lag | Maximum stable gain | Overshoot after a 6 dB change | Time to settle within ±0.5 dB |
|---|---|---|---|
| 0 | 2.00 | none | 0.5 s |
| 1 update (100 ms) | 1.00 | 0.7 dB | 0.7 s |
| 2 updates (200 ms) | 0.62 | 3.1 dB | 2.1 s |
| 3 updates (300 ms) | 0.45 | 5.5 dB | > 3 s |
Overshoot in a vibration test is not just a control-quality issue: it is energy delivered to the test article above the specification. On a lightly damped resonance, it can mean an over-test exactly where the hardware is most vulnerable.
3. Lag delays protection
Alarm and abort decisions are made from the same measurements, so they inherit the same lag. If a fixture bolt fails or an accelerometer comes loose, the time between the event and the drive being removed is the measurement time plus the loop lag. Every millisecond of lag is a millisecond of uncontrolled drive into a test article that may already be damaged.
4. Lag matters most where the physics is already slow
At low frequencies and fine resolutions, frames are long and updates are infrequent. Lag that is negligible against a 50 ms update can still matter, but lag that pushes a 1 s update to 1.2 s makes an already slow loop slower. Conversely, with fast updates from short frames or high overlap, a fixed processing lag becomes a larger fraction of the update interval, which is exactly when Figure 4's limits start to bite. High overlap is only fully effective in a controller whose lag is small compared with the update interval.
Common misconceptions
| Misconception | Reality |
|---|---|
| "A faster computer gives a faster loop." | Only the lag part. The frame time 1/Δf is set by physics and is the same on any hardware. |
| "High overlap removes the resolution penalty." | It increases how often spectra arrive, not how much data each one needs. Each spectrum still spans 1/Δf. |
| "Higher loop gain always means better control." | Only if lag and measurement scatter are small. With lag, high gain causes overshoot and instability. |
| "Loop speed only matters for difficult articles." | Any article that changes during test (heating, loosening, nonlinearity) and every abort decision depends on it. |
| "A loop time spec tells the whole story." | Ask what it includes. Update interval, frame duration and end-to-end lag are three different numbers. |
Quick reference
| Quantity | Formula | Rule of thumb |
|---|---|---|
| Frequency resolution | Δf = bandwidth / lines | 2000 Hz / 800 lines = 2.5 Hz |
| Frame duration | T = 1/Δf = lines / bandwidth | Doubling lines doubles T |
| Update interval with overlap p | T · (1 − p) | 75% overlap → T/4 |
| Time for a full response to a change | ≥ T + lag | Overlap does not shorten this |
| Structural settling | ≈ Q / fn seconds | Q = 25 at 20 Hz → 1.25 s |
| Max stable gain, integrating loop | 2.0, 1.0, 0.62, 0.45, 0.35 for 0–4 updates of lag | Each update of lag roughly halves the usable gain at first |
| Abort reaction time | detection measurement + lag + drive ramp-down | Minimize lag to protect the article |
How Panther minimizes lag
- Control computed in the chassis: the heart of Panther is an FPGA combined with a multi-core ARM processor. Acquisition, spectral processing, the control law and drive synthesis run in dedicated hardware next to the converters, so the loop does not wait on buffered transfers to a host PC or on desktop operating-system scheduling.
- Parallel processing where it counts: computationally intensive signal processing is offloaded from the ARM processor to the FPGA's parallel hardware, and the two communicate over a high-bandwidth, low-latency AXI interface. Processing time stays short even as channel count, line count and overlap increase.
- Overlap that pays off: because processing lag is small compared with the update interval, Panther can use high overlap (up to 95%) for fast updates without running into the gain limits of Figure 4.
- Synchronous, phase-matched channels: a single master clock samples every channel and drives the output, with channel-to-channel phase match on the order of 0.01°, so multi-channel control decisions are based on simultaneous data.
- Fast protection: real-time monitoring, Process Lines with warning and alarm levels, and automated abort sequences act on the same low-latency measurements as the control loop.
References and further reading
- Spectral Dynamics, An Advanced Random Shaker Control Algorithm (feedback and feed-forward error correction in closed-loop random control).
- J. S. Bendat and A. G. Piersol, Random Data: Analysis and Measurement Procedures, 4th ed., Wiley.
- G. F. Franklin, J. D. Powell and M. Workman, Digital Control of Dynamic Systems, 3rd ed., Addison-Wesley.
- C. M. Harris and A. G. Piersol (eds.), Harris' Shock and Vibration Handbook, 5th ed., McGraw-Hill.
- Spectral Dynamics Technical Library: Overlap Processing; Statistical Degrees of Freedom; FFT Fundamentals.
