Every developer knows the pain of inheriting code that fights back. For Calvin Young, a Graduate Research Assistant at Texas A&M's Fluid Mixing in Extreme Conditions Laboratory (FMECL), that fight had been disrupting his detonation experiments for months. When he spotted the LabVIEW sign at JKI's booth during the AIAA SciTech 2024 technical conference, he saw an opportunity.
Calvin approached Hunter Smith and Sam Kaley with a question about persistent DAQmx timing errors in his detonation tube control system. His lab studies how liquid droplets behave when impacted by detonation waves research relevant to propulsion applications. The LabVIEW application controlling their experiments had become increasingly unstable, with DAQmx trigger configuration and timing errors disrupting test runs.
Hunter recognized the symptoms. An inherited LabVIEW application with intermittent errors often signals deeper architectural issues. They agreed to schedule a follow-up call after the conference to dig into the problem.
What started as a troubleshooting question would reveal a classic case of technical debt—and an opportunity for transformation.
FMECL Detonation Tube Test Hardware
The FMECL is a lab focused on studying hydrodynamic instabilities driven by shock waves and detonations. Calvin’s experimental work involves a detonation tube facility used to impact liquid droplets with detonations and observe their evolution under conditions relevant to hypersonic propulsion devices, such as Rotating Detonation Engines (RDE’s). . To make these observations, the lab relies heavily on precisely timed high-speed laser-illuminated imaging techniques.
The control system, built in LabVIEW, is the nerve center of this operation. It manages the timing sequences, high-speed data acquisition (DAQ), and safety controls that make these single-shot experiments possible. In the research environment, failure isn't dangerous, but it is expensive—costing frustrating days of valuable time troubleshooting, wasted resources, and timing errors resulting in missed opportunities for capturing data. When test runs t can't be repeated on demand these issues can bring progress to a standstill.
Calvin inherited a LabVIEW application that had all the hallmarks of classic spaghetti code: it mostly worked, unless it didn't. In his own words: "The inherited code was unstable and would constantly crash. Modifications were difficult due to the organization."
Debugging became a time sink, forcing Calvin to prioritize wrestling with the software over his actual research. He was trying to focus on the science, but the "spaghetti code" was tying him down. Something had to change if FMECL was going to maintain its research momentum.
The follow-up call confirmed Hunter's initial suspicion: the DAQmx errors were just a symptom. The underlying issue was a fundamental lack of software engineering principles. The control system was a tangled web of nested sequence structures and local variables the exact race condition that caused the DAQmx timing problem was hidden within this maze.
JKI, recognizing an opportunity to contribute to this critical research, worked with Calvin and his advisor Dr. Jacob McFarland, Associate Professor of Mechanical Engineering, to secure an agreement for an ultra-focused 8-hour project. The goal wasn't just to fix the timing error; it was to transform the application into a stable, maintainable asset that Calvin could confidently hand off to the next generation of graduate researchers.
The Refactoring Methodology: Simple, Clean, Repeatable
JKI's approach to troubleshooting and refactoring is built on decades of expertise, centered on rapid maintainability and delivering maximum value quickly. The transformation was completed through a rapid, side-by-side collaboration with Calvin, ensuring the new architecture was immediately understood by the end-user.
JKI designed the new system to be easily maintained by students, opting for simple, common design patterns rather than the Object-Oriented Programming (OOP) based architectures typically used in complex, long-term development. This enables engineering students, regardless of advanced certification, to learn, maintain, and troubleshoot their code base.
1. Architectural Clarity: From Spaghetti to Two-Loop Design
Before -> After
The original Block Diagram was a daunting landscape of sporadic, sequential logic. JKI replaced this complexity with a simple, scalable two-loop design, a common pattern easily grasped by CLAD-level developers. This separation of concerns was the key to stability:
- Test Acquisition Loop: Dedicated to high-speed DAQ read monitoring, trigger setup, and recording data to disk.
- Control Loop: Dedicated entirely to commanding all valves, analog setpoints (via DAQmx Write).
This new design enabled much more flexible control, now valve could be manually controlled at any stage of test,
2. Hardware Abstraction: Cluster API Over Hidden Complexity
The existing code had DAQmx calls scattered throughout the main diagram. JKI refactored this logic into a simple, reusable cluster-based API not classes. This common Open/Read/Write/Close pattern made a simple abstraction that wrapped the complexity of hardware interaction inside a few subVIs, making the top-level diagram intuitive and maintainable by students. This new interface also made it easier to test the hardware interface without running the whole experiment. The cluster-based approach ensures that future modifications to hardware only require updating a single wrapper VI, without touching the main application logic.
3. UX Overhaul: From Cluttered to Schematic
The original Front Panel was a cluttered array of controls and indicators (see ). The UI overhaul replaced this with a schematic-based interface, intuitively mapping the controls to a graphic representation of the detonation tube (see ). These simple changes meant that Calvin and his team could focus on the experiment's process rather than searching for the right control on a disorganized screen.
4. Safety & Robustness
The final hours were dedicated to critical quality-of-life and safety improvements: implementing robust error handling throughout, ensuring all outputs are safely reset on shutdown, adding an abortable 5-second countdown to the experiment sequence, and adding extensive comments and consistent naming conventions for future maintainability.
The result of the focused 8-hour sprint was a completely stable, fully documented, and intuitively designed control system. It proved that a major transformation doesn't require a multi-month engagement; sometimes, all it takes is a focused application of world-class software engineering.
The difference the 8-hour refactoring made was immediate and dramatic not just in the code, but in the lab's productivity. With the race condition solved and a stable architecture in place, Calvin and the FMECL team could finally get back to their core mission.
The frustration and instability caused by the inherited code evaporated, replaced by a system that was intuitive, reliable, and ready for future work. Calvin noted that the refactored code is now "easy to understand, navigate, troubleshoot, and expand."
This newfound stability translated directly into increased research output. Experiments that were once interrupted by intermittent software bugs now ran reliably, preserving valuable time and resources. As Calvin explained: "We are no longer losing days of productivity in a month over software issues. There are many fewer lost experiments due to control and data acquisition issues. I feel confident that my successors will be able to implement new experiments and modifications on their own rapidly."
Beyond fixing the immediate problem, the project provided a template for better software practices within the academic lab. The team now had a blueprint for how professional, clean code should look, empowering them to apply these standards to future projects. Calvin summarized his overall experience:
"Yes! Hunter took the time to understand our experiment & existing control system. After coding up the new, updated system he then worked with us to iterate to a final polished product on a very reasonable timeline. I could not recommend this company higher for this."
Dr. McFarland added “how important it is to have a well-written code as it will be handed down to new students for many years to come, and each will likely want to add their own bits. Having it well-organized will help to keep it from rapidly evolving back to where it was.”
The story of Texas A&M’s FMECL lab is a common one: groundbreaking science hampered by legacy software. Whether you’re dealing with an intermittent DAQ error, an unreadable block diagram, or a front panel that scares new users away, spaghetti code is technical debt that actively steals time from research and development.
JKI's focused, 8-hour engagement with Calvin Young proved that major architectural transformations don't require months, just the right expertise applied efficiently. By prioritizing maintainability and clean design, JKI delivered a stable control system that empowered the FMECL team to successfully complete their research (and in fact, since the project completed, Calvin has successfully defended his dissertation and earned his PhD).
If your research or engineering team is tied down by unstable, inherited, or unscalable LabVIEW code, let JKI help you get back to the work that matters.
Contact JKI Today for a Code Transformation:
We offer fast, focused engagements for:
- Quick Troubleshooting Consultations
- UI Modernization & Cleanup
- Hardware Abstraction Module Implementation
- Complete Safety-Critical Application Development
Focus on the science. We'll handle the software engineering.
Enjoyed the article? Leave us a comment