The Challenge: Precise Amplitude Control Across a Frequency Sweep
A sensor manufacturer in the Rochester, NY area needed a way to qualify their IEPE accelerometers on an electrodynamic shaker. The requirement sounds simple: mount a sensor on a shaker, sweep through a frequency range, and verify the output. The catch is that electrodynamic shakers don't behave the same at every frequency. At low frequencies, displacement limits the achievable acceleration. At higher frequencies, the shaker's force capacity and mechanical resonances cause the amplitude to drift. Without active correction, the vibration level at the sensor changes as the frequency changes — and that makes qualification data unreliable.
The customer needed the system to maintain a constant g-level as the shaker swept from 1 Hz to 10 Hz — a range where displacement limitations make open-loop control essentially useless. A vibration sensor mounted on the shaker provided real-time feedback, and the controller had to continuously adjust the drive signal to keep the amplitude locked on target. This is a classic closed-loop control problem, but it demands deterministic timing that a Windows-based PC simply cannot guarantee.
Why Windows Couldn't Do It
The customer had strong in-house expertise in C# and web-based development. They initially explored building the shaker control on a Windows PC, but quickly ran into the fundamental limitation: Windows is not a real-time operating system. The control loop needed to execute every 50 milliseconds with consistent, bounded timing. On Windows, the OS scheduler can preempt any process at any time — an antivirus scan, a Windows update check, a background service — and suddenly your 50 ms control loop takes 200 ms. For a closed-loop system driving a shaker with a human standing nearby, that kind of timing jitter isn't just an accuracy problem. It's a safety problem.
The customer recognized this challenge and made the right call: use a platform built for deterministic control, and interface to it using the tools they already knew. That's where the NI CompactRIO came in — and where the architecture got interesting.
The Solution: cRIO as a Black Box with a RESTful API
The design philosophy was straightforward: make the cRIO invisible. The customer didn't want to learn LabVIEW, didn't want to maintain LabVIEW code, and didn't want to depend on LabVIEW developers for day-to-day operation. They wanted a black box — send it parameters, tell it to run, and get data back. So that's exactly what we built.
The entire closed-loop control application runs headless on the cRIO's real-time processor — no monitor, no keyboard, no PC required for operation. The cRIO boots up, initializes the hardware, and exposes a RESTful JSON API over Ethernet. The customer's C# application communicates with the controller using standard HTTP requests — the same way any modern web application talks to a backend service. No proprietary protocols, no NI drivers on the client machine, no LabVIEW runtime. Just JSON over HTTP.
Approximately 12 API Endpoints — Everything the Customer Needed
The web service API exposed roughly 12 RESTful endpoints covering three categories: parameters, data, and device status. On the parameter side, the customer's C# application could configure the frequency range, target amplitude (in g), sweep rate, and dwell time — all through simple JSON payloads. Start a sweep, stop a sweep, and query progress were all API calls.
On the data side, the primary response was real-time amplitude — the actual measured g-level at the sensor, which the customer used to verify the system was holding target. Waveform data was also available through the API for customers who wanted to capture the raw time-domain signal, though this particular customer focused on amplitude and status. The device status endpoint returned the current state of the controller — idle, running, sweep complete, or error — so the C# application always knew what the cRIO was doing without polling excessively.
The Hardware: NI 9234 and NI 9263 in a CompactRIO Chassis
The I/O was clean and purposeful. An NI 9234 module provided the IEPE signal conditioning needed to power and read the accelerometer — it supplies the constant-current excitation that IEPE sensors require and digitizes the AC-coupled vibration signal with 24-bit resolution at up to 51.2 kS/s per channel. On the output side, an NI 9263 analog output module generated the drive signal sent to the shaker's power amplifier. The cRIO's real-time processor ran the control loop: read the accelerometer, compare to target, adjust the output. Every 50 milliseconds, with no jitter.
The beauty of this hardware combination is that both modules sit in the same CompactRIO chassis, connected directly to the controller's backplane. There's no USB latency, no external DAQ box, no Windows driver stack in the signal path. The real-time OS reads the input and writes the output in a single deterministic loop iteration — exactly the kind of tight coupling that closed-loop control demands.
Closed-Loop Control: Holding Constant G Across the Sweep
The control algorithm continuously monitored the vibration amplitude through the NI 9234 and compared it against the target g-level. As the frequency swept linearly from 1 Hz to 10 Hz, the controller adjusted the NI 9263 output voltage to compensate for the shaker's changing mechanical response. At the low end of the sweep, where the shaker needed large displacement to achieve the target acceleration, the controller drove harder. As frequency increased and the shaker became more efficient, the controller backed off.
The result was a flat amplitude profile across the entire sweep — exactly what sensor qualification requires. The customer could set a target g-level, start the sweep from their C# application, and trust that the vibration at the sensor was held constant throughout. No manual gain adjustments, no operator intervention, no post-test corrections. The cRIO handled it all in real time.
The Result: Multiple Stands, Same Architecture
The system gave the customer exactly what they needed: the precision of real-time deterministic control without having to build or maintain a LabVIEW application. Their C# developers could integrate the shaker controller into existing workflows, build custom UIs around it, and automate multi-step qualification sequences — all using HTTP and JSON, tools they already understood. The cRIO was just another service on the network.
The accuracy improvement over their previous approach was significant enough that the customer didn't stop at one. The same architecture is now running on multiple qualification stands, each one a cRIO black box controlled through the same RESTful API. New stands can be added without additional LabVIEW development — deploy a cRIO with the same image, point the C# application at a new IP address, and it's running.
Why This Architecture Works
This project is a good example of playing to each platform's strengths. The cRIO handles what it does best: deterministic real-time control, hardware-timed I/O, and IEPE signal conditioning. The customer's C# application handles what it does best: user interfaces, database integration, workflow automation, and business logic. The RESTful API is the clean boundary between the two worlds — no shared codebases, no platform dependencies, no skills gap.
For manufacturers who have invested in web-based or .NET development teams but need the precision of real-time hardware control, this pattern is repeatable. If your application involves closed-loop control, high-speed acquisition, or deterministic timing — and you want to keep your existing software team productive — a headless cRIO with a web service API might be exactly the right architecture.
Need a Similar System?
If you're building vibration test systems, sensor qualification stands, or any closed-loop control application that needs to talk to your existing software infrastructure — that's what we do. Korpra has been designing LabVIEW and NI CompactRIO systems for manufacturers across Rochester, Buffalo, Syracuse, and nationwide since 2001. Call us at 585-678-1649 or request a quote.
Interested in a similar system?
Let's talk about your requirements.