The main components of the final design are categorized and listed below:

1. Mechanical Hardware

   1. Vertical Axis Ball Screw Actuator

   2. Horizontal Axis Lead Screw Actuator

   3. Wagon Wheel Gripper Assembly

   4. Into the Machine Axis

2. Electrical Hardware

   1. Programmable Logic Controller (PLC)

   2. Stepper Motors

   3. Motor Driver

   4. Network Switch

   5. Power Source

   6. Calibration Interface

   7. Current Sensor

3. Software

   1. Python Systems Control

   2. Graphical User Interface (GUI)

   3. Arduino Motor Control

Mechanical Hardware

Vertical Axis Ball Screw Actuator (Z-Axis)

Functional Requirements: 

• Lifts largest wagon wheel and entire horizontal axis and gripper assembly (820g)

• Total travel length of at least 80 mm

• Completes full travel length in 5 seconds

• Connection to the horizontal axis supports a 1.3 Nm moment

• Maximum height of 276 mm

The vertical axis ball screw actuator was purchased from a linear position actuator company, FUYU. This product was chosen for its ability to meet the functional requirements at low cost ($150) compared to other possible design solutions, and included all components shwon in figure 2.1. Purchasing the entire assembly rather than designing, manufacturing, and assembling from scratch also saved invaluable engineering time. A mounting bracket was designed and machined to mount the horizontal axis onto the FUYU vertical axis (figure 2.2). 

Horizontal Axis Lead Screw Actuator (Y-Axis)

Functional Requirements:

• Precision better than 0.5 mm 

• Minimum horizontal pushing force of 8 N 

•  Small and lightweight

The horizontal Axis Lead Screw Actuator (figure 2.4) was designed from the ground up, using a NEMA 8 stepper motor with a lead screw purchased from Anaheim Automation. The axis is supported by an aluminum beam with a mounted hardened steel rail for 2 horizontal sliders. As opposed to the vertical axis, this component was designed from the ground up due to the more stringent space-requirements of this component, as it needed to fit within the space between the GDS O-ring and cooling puck (see home page). 

Deflection Analysis of Horizontal Axis

A main concern for the horizontal axis component was that deflection under the load of the gripper and sample would exceed the required precision tolerance for positioning the sample. The initial horizontal axis design was supported on one side (cantilever beam) with one aluminum beam. Other options would be to support the beam on both sides (simply supported beam) and/or add multiple or larger aluminum beams for support. In order to inform this decision, deflection analysis was conducted using Finite Element Analysis (FEA) and analytical methods on the worst case-scenario loading (gripper as far from support as possible). Analysis assumptions and results are summarized below and shown in figure 2.5.

Analysis Assumptions: 

• Cantilever supported beam

• Combined stiffness of beam from aluminum support and steel rail using parallel axis theorem

  • Neglect mounting holes in steel beam

• Evenly distributed weight of aluminum beam and steel rail 

• Weight of gripper and sample evenly distributed between horizontal sliders

Results:

• Max deflection: 0.36mm

• Deflection at measured spoke: 0.12mm

  • Deflection < required precision (0.5m) ✅

• Good agreement between FEA and analytical solution (within 10%)

• Interpret results as worst-case due to actual support being better than simple cantilever

Conclusion: Proceed with current design using one support and one aluminum beam for support.

Into the Machine Axis Actuator (X-Axis)

Functional Requirements:

• Overcome return spring on cooling puck (15 N)

• Travel 3 cm 

• Clamp sample with sufficient force to establish vacuum with O-ring

The x-axis actuator consists of a rack and pinion powered by a NEMA 23 stepper motor (figure 2.7), used to push the cooling puck against the sample, clamping it against the GDS O-ring prior to the vacuum is established for analysis (figure 2.8). A current sensor was implemented (see electrical components section) to sense the current jump that occurs when the sample meets the O-ring and command the motor to halt. This was necessary due to varying thicknesses of the wagon wheel samples.

Electrical Hardware

Functional Requirements:

• Provide 12V DC to electrical components

• House electrical components in a ~1.2m x 1.2m x 1.2m space (housed under a small table)

• Ability to drive a 2.5A, 2.8A and 0.5A stepper motor

• Utilize current sensor to detect crash on x-axis

• Actuate stepper motor when prompted by Application Programming Interface (API)

• Easy to use calibration interface to actuate both axes

Software

Python Systems Control

Functional Requirements:

• Facilitate communication between API and GDS via TCP/IPv4 to send and receive XML strings

• Send and receive string formatted motor commands to PLC via TCP/IPv4 

• Utilize user inputs to calibrate and start analysis process

• Handle error messages to allow the user to determined subsequent steps

The control system is programmed to follow the state machine computational model. The entire system exists in one of several states which is controlled by certain events/triggers. The system expects triggers, such as XML messages from the GDS and logical expressions to and from the Arduino Mega. Based on the current state that the system is in, the system executes certain functions. The system can be described as having the following states (listed below and shown in figure 2.13):

The analysis state contains substates that allow the system to flow through sample loading, analysis, unloading, and GDS self-cleaning (AKA Reaming) procedures, as well as handle errors. These nested states are shown in figure 2.14.

Arduino Motor Control

The Programmable Logic Controller (PLC or Arduino MEGA, see electical hardware section) also follows a state machine model to control the motors through the sample calibration, analysis, and GDS self cleaning processes. The states for the PLC are shown in figure 2.16. 

Hardware Performance

Precision and Accuracy Performance of the Positioning Mechanism

In order to assess the achieved precision and accuracy of the final gantry prototype, it was placed facing a wall with a marker secured to the gripper (figure 2.17). The mechanism was programmed to trace out an 8X8 grid with 10mm spacing between grid points, and each position marked. Then, a photograph were taken of the grid (figure 2.18) and grid point positions located using image processing in MATLAB (figure 2.19). The distance between adjacent points throughout the grid was used to asses the precision and accuracy of the mechanism achieved by both axes, with results shown in figure 2.20 and table 2.1. In conclusion, the achieved precision for both axes were better than the required 0.5mm. The median accuracy was also within the 0.5mm margin, and further testing could be done to refine the stepper motor step to distance conversion ratio used in the software if it is found to be necessary. 

Automation Results of Sample Alignment Gantry Mechanism

The sample alignment gantry mechanism was installed in the GDS900 and all software was installed on the PC Desktop computer. Visual inspection confirmed that the programmed pathing for positioning of the 8-spoke wagon wheel was successful after the calibration procedure was completed. Additionally, the programmed retracted position successfully moved the mechanism to a position where the GDS was able to perform self-cleaning. However, when the analysis process began on the GDS, connection with the PLC was repeatedly lost and the motors occasionally began running uncontrollably. Extensive trouble-shooting was unsuccessful within the time-limitations of the project, and full integration and testing of the mechanism will be a future endeavor for another individual or team. It is hypothesized that electromagnetic interference within the GDS causes the loss of connection due to repeated tests outside the GDS that did not lose connection (Table 2.2).