Student Projects

Showing results for 
Search instead for 
Did you mean: 

Student Design Competition 2011 - LeTourneau University: ACL Fixture Control Project

LabVIEW Student Design Competition

ACL Fixture Control Project

Contact Information

University: LeTourneau University

Team Member(s): Richard DeBellevue, James Frank, Tom Kelley, Justin Thomas

Faculty Advisor: Dr. Roger Gonzalez

Email Address:

Project Information

Title: ACL Fixture Control

Anterior cruciate ligament (ACL) failure is a common injury among athletes, but the biomechanical effects of this failure on the knee are not fully understood. A dynamic computational model of the human knee that is validated from experiments on cadaver knees would allow for an increase in the understanding of the knee. A dynamic knee fixture has been built, and a control system capable of coordinating the movement of the fixture and simulating conditions on the knee is being developed. Data gathered from experiments ran on this fixture will be used to validate the computational model of the knee.


Controller Software: NI LabVIEW 2009, Windows 7

Fixture DAQ Hardware: NI PCI-6254, NI PCI-6033E, NI PCI-6703

The Challenge:

The Controls team was responsible for the development of a control system in LabVIEW that simultaneously controlled positions, moments, and muscle forces on the knee fixture (Figure 1).  In addition, the controller needed to record the resulting positions, pressure distribution on the tibial plateau, posterior cruciate ligament (PCL) strains, anterior cruciate ligament (ACL) strains, and the ground reaction forces on the ankle.

Figure 1 - The Test Fixture with an artificial knee installed

The fixture contained three sleds consisting of a medial/lateral (side/side) position sled, an anterior/posterior (forward/backward) position sled, and a superior/inferior (up/down) hip position sled.  In addition, seven muscles were actuated using pneumatic cylinders with in-line load cells.

The Solution:


A control system was developed using LabVIEW that could parse desired experimental data, control the knee fixture, record the results, display the results, and analyze the results.  Primary considerations included controller maintainability, stability, safety, preservation of the biological knee, and accuracy of the position control.  These were addressed through a variety of solutions as outlined below.

Controller Architecture

A queued state machine architecture was selected because it helps to ensure that the code is maintainable and scalable.  It also allowed for relatively quick development through code re-use. The scalability of the queued state machine architecture meant that additional capabilities could be added to the controller over time. These capabilities included the ability to load and prepare sets of experimental data while the program is running, view trial results and modify control system parameters immediately after a trial, and manually position the fixture.  This allows for much more seamless transitions between tests.  The most recent state machine has been displayed below in Figure 2.  Because of its complexity, some states are duplicated on the diagram, but they are the same state.

Figure 2 - The State Machine

Hardware Control Code Abstraction

Since the code required to perform the desired tasks was obviously expansive, object-oriented code was used to create a significant amount of abstraction allowing clear and modular code.  This facilitated the creation of a single class that encapsulated all of the control and interface logic for the fixture hardware.

There were two classes used.  The first one, the Fixture class, was implemented as a single LabVIEW class containing private data for the command voltage for each actuator, the value read from each feedback transducer, and the PID controller parameters for each component’s controller.

The second class, the Experiment class, is used to manage the experiment information such as, pre-processing of desired position paths, file paths, and experiment results.

Timing Concerns

In order to maximize responsiveness to disturbances, the execution time of the main control loop had to be minimized.  An analysis of the most time-expensive operations revealed that DAQ reads and writes were the most computationally expensive.  To reduce the number of reads and writes, the hardware inputs and outputs were not read/written with the most current values each time private class data was modified.  Rather, DAQ I/O was refreshed once at the beginning and end of batch functions with an array list of components and their target/desired values as can be seen below in Figure 3.

Figure 3 - Batch DAQ Reads and Writes

Pneumatic Delay Compensation

Synchronization of the controlled variables was achieved by accounting for the delay introduced by the pneumatic actuators.

A solution was developed to measure the delay for each component based on the desired values and the actual achieved values.  A numerical approach was used to determine the time shift that provided the smallest average error.  Using the measured delay, the setpoints were shifted to achieve the desired position at the desired time.

For example, in the figure below, the green dashed line is the setpoint position, the grey is the desired position, and the red is the achieved position. For this particular trial, a delay of 440ms was used. The vertical axis is vertical position and the horizontal axis is time.

Figure 4 - Experiment Results Showing Delay Compensation

As can be seen, by providing the setpoint ahead of time, the delays inherent in the system can effectively be corrected for and provide a much closer adherence to the desired path.

In later trials, the controller was tuned to minimize the delay.  This improved the responsiveness to disturbances.

Object Oriented Programming

In order to cleanly separate experiment management code from controller code, the experiment management code was abstracted into a class as was previously done with the fixture control code. In order to further ease the use of the experiment management class in the controller and other VIs, a singleton pattern was used. A singleton pattern is a design pattern that guarantees that a class has only one instance in memory. This pattern was advantageous because the experiment class was designed to represent the entire experiment data library.

The implementation chosen allowed for a functional singleton with no wrapper code and minimal overhead. A template VI for this implementation is shown in Figure 6.  In this figure, the VI on the left obtains the singleton reference to the experiment class as demonstrated in Figure 5 and can be used in the “Data Value Reference Read/Write Element” frame as if it was a normal class.  This ensures that the memory use is optimized.  After selecting this implementation option, tests were performed to verify that the chosen solution worked correctly.

Figure 5 - Creating and Obtaining the Singleton Class Reference

Figure 6 - Singleton Implementation for Experiment Class

Additional Sensors

3 Linear potentiometers, 7 unidirectional load cells, 1 6-axis load cell, 3 pressure transducers, 12 pressure regulators, 1 pressure distribution sensor (Tekscan), and 2 differential variable reluctance transducers (PCL and ACL).

Control System Interface

The interface for the control system was designed so that during the experiment, all relevant data and controls can be accessed.  In addition, the interface enables the user to perform tasks that would otherwise be tedious with high chances of human error.  These include interpolation and expansion of data relative to time, experiment information collection (e.g. subject, date, time, unique iteration code, et. al), copying tuning parameters, editing tuning configurations, and enabling/disabling certain devices.  The standard controller front panel can be seen below in Figure 7, showing the current experiment information is on the left and the list of previous experiments is on the right.

Figure 7 - Singleton Implementation for Experiment Class

Another notable feature is the Safe Mode.  In this mode, an extra layer of protection is enabled to help prevent the user from accidental button presses that could cause sleds to crash into their limits of range at high speeds, a primary safety concern while individuals are nearby or when a specimen is loaded into the fixture.

The Benefits of LabVIEW and NI tools

LabVIEW provided many benefits for the ACL project.  First, it facilitated the rapid creation of an easy to use human-machine interface for experiment control and management. Second, the numerous available LabVIEW libraries and toolkits allowed for development of high quality data acquisition, control, and processing algorithms. Finally, the use of G allowed for the development of high quality maintainable code in a collaborative environment. The National Instruments data acquisition hardware provided reliable and accurate signal input and output capabilities, allowing for simultaneous reading of a number of sensors and control of fixture actuators.

Project Pictures and Videos

Experiment Data and Fixture Tracking

The Controls Team

Figure 8 - Tom Kelley, Richard DeBellevue, Justin Thomas, and James Frank

NI Employee (retired)

Hello there,


Thank you so much for your project submission into the NI LabVIEW Student Design Competition. It's great to see your enthusiasm for NI LabVIEW! Make sure you share your project URL with your peers and faculty so you can collect votes for your project and win. Collecting the most "likes" gives you the opportunity to win cash prizes for your project submission. If you or your friends have any questions about how to go about "voting" for your project, tell them to read this brief document ( You have until July 15, 2011 to collect votes!


I'm curious to know, what's your favorite part about using LabVIEW and how did you hear about the competition? Great work!!


Good Luck, Liz in Austin, TX.