Design Review Agenda
Problem DefinitionMetal additive manufacturing machines primarily use either wire or powder feedstock. Powdered metal is expensive and wire is hard to source for alloys that are not used in welding. The use of bar stock would be ideal, as most metals are readily available in rod form, but no standard exists for using rod stock in metal AM applications.
The goal of this project is to develop a feeding mechanism which will enable the use of various bar stock materials in metal AM applications, particularly the Vader AM machine in RIT’s Brinkman Lab. The design must provide stock material fast enough to avoid slowing the machine down, without overfilling the micro-crucible or negatively impacting part quality. The device must also be safe for both operator and machine, and be simple to use. While integration with the Vader is ideal, it is not the primary goal of this project.
Customer and Engineering RequirementsNo updates since Phase 2.
- Budget (~$2500)
- The system must use 12-inch rods as feedstock material
- Feeder fits within a defined volume (2' wide, 1.5' deep, 3' tall)
- Machine weighs less than 50 lbs in loaded state
- The system is safe for operator and machine
- Signals Operator when low on rods
- Feeder operates independently with no human interaction during normal use
- Feeder starts on simulated or actual start signal and stops on simulated or actual stop signal
CAD of Final Design:
From left to right:
Row 1: Total Assembly, Hopper, Feeder
Row 2:Agitator, Weight Bracket, Base
Row 3: Test Base
The directory to all drawings is Here.
Live document here.
Electrical SchematicElectrical Schematic:
Prototyping, Engineering Analysis, Simulation
Hopper PrototypingTo test whether the vertical hopper concept was sound and wouldn't jam, we created a prototype test plan using various 3D printed funnels. To determine optimal funnel angles we printed multiple funnels and measured their performance. The shallowest angle performed best. We built a to-scale model of the hopper system and using an appropriate motor ran the device and determined that it wouldn't jam and would easily meet the flow rate requirements.
Feeder PrototypingWe have gone through multiple 3D printed prototypes in this phase. Each iteration has fixed problems we have found with the previous version.
Vibrations TestingThe proposed design includes an agitator. AM machines require precise movement of the print head and so excessive vibration could negatively impact performance. To address this, we included vibration isolators in the design and, with the guidance of subject matter expert Dr. Ghoneim, decided on a plan to minimize vibration:
- Make the hopper assembly heavy with respect to the rods
- Measure the natural frequency of the hopper assembly in ANSYS
- Set the agitator motor to that frequency
- Dial the offset weight to produce minimum displacement
The feedback form can be found here.
Then to get a measure for allowable vibration we mounted our prototype agitator to the Vader print head and printed baseline cubes. The results below show that there was no effect from vibration.
We are confident that the minimized vibration of the device, further reduced by the rubber isolators, will have no negative impacts on the Vader.
The photogate configuration was tested in lab for use in our design. A LED was powered and aimed at a phototransistor (BPX 38-4) and the output voltage was measured. The test was performed on a breadboard and ambient light was blocked by covering the setup with a box. A hole was made in the top of the box and a rod was placed through and aimed between the LED and the phototransistor to block the light, simulating operation in the design.
The voltage reading of the phototransistor under the box with the LED on was 10.9mV. With the rod blocking most of the light, the voltage dropped to 0.3mV. Because the Arduino has 10-bit ADCs, this difference of 10.6mV between readings is enough to differentiate logic high and low for operation. Increasing the distance between the LED and phototransistor to over 2 inches decreased the output voltage to 2.5mV with the LED on and unobstructed.
The phototransistor used was most sensitive to IR light and had less than 20% spectral sensitivity at the wavelength of light that we used (550-600nm). We have already ordered a photosensor that is not only more sensitive to visible light, but will amplify the output voltage make the difference between logic high and low clearer.
Communication between the Arduino and the level sensor used in the Vader was an initial concern. Researching the level sensor led to the conclusion that the sensor can output an analog or digital signal. The digital communication is through RS-422. A meeting with Dr. Barrios was held to discuss RS-422 in detail and what micro-controller would be best for this project. The Arduino Mega was selected because of the voltage requirements for RS-422 and because of the RS-422 shield that can be used for easy communication.
Along with communicating with the sensor in the Vader, another concern was whether the 1/8" rods would block this level sensor when feeding into the upper pump. The level sensor currently points directly down into the upper pump and if the rod fed in were to block the laser, level measurements would be incorrect. After discussing this with one of the Vader operators, Manoj Meda, we learned that the 1/16" wire that is presently used for operation begins to melt as soon as it enters the upper pump. With this information, feeding the 1/8" rod slow enough will allow it to melt at the top of the upper pump and will not block the level sensor laser.
MSD 1 Risk Conclusion
Full Test Matrix:
The live document is here.
Test Plan 1: Tests all primary requirements. Under each rod condition, run the device for 10 minutes 10 times. The counting rig shown below will create a time series, allowing us to measure both the average feed rate over a long period, and the distribution of delays between individual rods. It also confirms that the device stores sufficient rods and operates under that condition.
Test Plan 2: Confirms that device will stop and start under required conditions (RS422 signal from Vader level sensor)
Test Plan 3: Confirms that the device can be cold started in a reasonable amount of time.
Budget and Purchasing
Purchased This Phase
- Various sensors for testing
- Agitator motor
- Wheels for feeding mechanism prototype
- Shields for Arduino control and communication
- Various small components used in prototyping
Critical Part Purchasing over break: In progress
Risk assessment for MSD 2:
Opportunity: Angle Feed
We are looking into a more compatible method for the Vader system. This is both above and beyond our proposed scope for the project.
Project ScheduleRemainder of Semester:
- Finalize list of parts to purchase over break
MSD 2 Overview:
Start of MSD 2 Plan:
What we learned
- Josh - I have learned how time intensive the mechanical design process is. It is one thing to come up with a concept, but it is completely different to design it. It takes a long time to figure out the right dimensions, choose the right bolt sizes, and have all of that incorporated into the design.
- Mathias - How important it is to perform research when finalizing designs, as well as the importance of speaking to subject matter experts to answer important questions and give more information that might change/help the design.
- Ryan - I learned a lot about working with an iterative design and CAD model. In classes you usually finish a project then submit, but in MSD the project has many changing parts that affect each other.
- James - I learned how many different things the project manager has to keep track of: Budget, time, scheduling, communicating with each member and assigning work, acting as an interface for questions, and having to have a high level sense of each technical element.
- Mark - I learned how to operate in a multidisciplinary team on a single, long-term objective. I now know more about the embedded systems programming design and the importance of making work that can be picked up by later teams.
Suggestions for MSD
- Beginning online modules not terribly helpful
- Provide more guidance at the beginning on project management
- Have more freedom on purchasing (Non-American suppliers, easier to compensate past purchases)
- More detailed expectations for certain deliverables (drawings, PDDR)
- Combine phase 3 and 4, and have the progress be when the PDDR normally was
- Add a week to phase 1
- Meeting Minutes, 3 Week Plans, and Logbook modules not very useful
- Functional Decomp / System Architecture VERY useful
- Pugh selection useful, but arbitrary
- Asana usage was very useful (Not required by MSD)
Progress ReportProgress as of 11/27/18:
- First iteration of 3D printed parts
- 1/16" rods tested (Success)
- Meeting with Minoj:
- He believes that 1/8" rods should not interfere with sensor
- If they do, he believes that feeding them very slowly should solve this
- Determined how to design feed tube in order to integrate with Vader head
- Pseudocode created
- Operating Procedure draft created
- Roughly %75 of design work completed
Plan To Accomplish Before DDR
- Photogates tested and configuration determined (Mathias)
- All design work will be completed (James)
- Drawings will be created for each part (Josh)
- The BoM will be updated with the new complete part list, indentured, with budget integrated (Ryan)
- Test plans will be completed (Mathias)
- Risk assessment for MSD 2 will be completed (Mark)
- Schedule/plan for MSD 2 will be created (James)
- Edge documentation done and fixing the WBS (Connor)
Input required from Customer
- Can the lower bracket of the mounting assembly be permanently mounted?
- What are the feed rate limits, or how could we calculate them?