JPF Welding Automation

Transcription

1 JPF Welding Automation ECE 1808 / ME 30 EE: Thomas Bacon, Brittany Bohn, Timothy Jorz, Ivan Paz ME: Nathan Baker, Ronnie Fierro Faculty Advisor: Ashwin Dani Industry Sponsor: Mr. Scott Carlson

2 Summary Kaman manufactures a Joint Programmable Fuze (JPF). They wish to automate a specific part of the JPF building process, that involves testing a part for any leaks to ensure welding was done correctly. This is done by injecting helium into the part and testing it. Our project is to find a way to automate this process. Background Kaman currently manufactures a Joint Programmable Fuze (JPF). Kaman wishes to automate a step of the JPF building process, which involves testing a specific part of the JPF by for any leaks, to make sure the welding done prior to this test was completely effective and up to their standards. The test consists of plugging two holes in the specific JPF part, then you put a fixture onto the part, and the fixture injects helium, and is tested for any leaks. Automating this testing process, will ensure a decrease in testing failures, decrease cost, increase production and the production efficiency of the JPF. Separately to our project, Kaman also wants to automate the part of the JPF building process that happens before the leak test, and after the leak test. Their ultimate goal is to have a fully automated cell that consists of all these parts of the building process being automated. Solution

3 Above is the networking configuration that our sponsor, Scott, and our groups have decided on. In general, some of the reasons that we had chosen the above include: Better EMI resistance, greater durability, greater code stability, and our sponsor has the most familiarity with this solution. One thing to note with this solution is that since the PLC( Programmable Logic controller), typically use a large amount of ladder logic, we should expect there to be more groundwork in programming these as compared to the solution shown below. The general consensus is that in order to send the required strings, we should expect to store each individual character in separate buffer locations until the entire thing is ready to be sent out to the Tester. From there, the tester will send back a string detailing its measurements/ completion status. This received string will need to be stored into a temporary buffer and each character will need to be logically compared with a PLC s comparator to determine the type of measurement and the actual measurement itself. If the test passes, continue further down the control logic pathway. In the Raspberry pi (PI) solution( officially the backup solution), the ASCII data can be

4 stored on the PI and we can send the data serially through the RS232-TTL converter. From there, much like the PLC, we should receive an ASCII string detailing the type and data for the measurement. For this situation, we could have a Python program running that simply parses the input by taking (string.split() ) the first char and creating a dictionary to indicate the type of measurement and then reading the rest of the characters to determine the actual measurement itself (and whether or not it falls into the pass category or retry category or fail category which would probably be handled by a state machine approach). Above is a picture of the contraption that the UR5 places the test piece into. The piece that is getting its welds tested is circled in red. It initially starts in a specific position that is the same every time. This removes the need of needing to change its orientation to a correct way because it will always be the same. The UR5 picks up the test piece from that spot and then places it in the contraption above. The part labeled Linear bearing then brings down the plugs and plugs the holes in the test part. The backfill port is the threaded port and is going to be plugged with a rubber stopper. The

5 other port is getting plugged by a rubber gag seal that is similar to what already is in the current test hood. Once these are plugged then the helium test begins. The UR5 will be connected to the device that runs the test and will tell it when to start. This test ensures that less than a certain amount of helium gas gets through the welds and seals. Now if the device passes the test, the test hood comes out of the test device and the UR5 picks it up and puts the test device in the designated pass location. If the test is a failure then it gets ran one more time. If the test passes the second time then the UR5 does the same thing and puts the device in the pass location. If the device fails the leak test then the UR5 places the part into a designated fail location. Once that happens the UR5 grabs another test device and repeats itself. We discussed other methods for a solution, which did not fulfill our needs. The first idea we had was to not even use a robot in the first place and only use a conveyor belt. Doing this would have made it very hard to place and remove the test piece from the testing hood, and to have gotten the piece in the correct orientation for the test. It also would have been more difficult to sync the current test software with the conveyor belt to get the test to start. Also if the device failed with the conveyor belt way it would have taken more sensors to correctly get the device placed in the correct area. We had another idea of using the robot and a conveyor belt. We would have had the UR5 place the fuze onto the conveyor belt (to avoid the orientation issue of above) and to take it off the conveyor belt at the end. Once on the conveyor belt the test piece would have moved down to where the test hood was and then have the backfill port plug and other rubber gag seal filled. This idea was close to what we finalized but we came to the conclusion that a conveyor belt would be a waste of money when the robot could do that simple task itself. Putting the conveyor belt would have over complicated things. Our last idea was simply to have the robot itself screw in the plug for the threaded backfill port. This posed two problems. The robot would have to line up the threading perfectly. This is a very precise task and if it were to make a mistake, it would damage the threading which in return would damage the entire integrity of the piece and its ability to pass the test. The second problem with having the UR5 screw in the backfill

6 port would be that the UR5 would need a torque sensor to ensure that the screw was not inserted too tight. If the screw was inserted too tight then it could dent the fixture and damage the piece as a whole. Project Phases, Timing, and Milestones For this project we started with meeting with our sponsor, KAMAN, in Middletown to see the facility and the test piece we were going to be working. Once we got the idea of what we had to do in our mind we started brainstorming ideas and ways that we could make the process autonomous. We knew the sponsor wanted to sue the UR5 robot so we started with ways of integrating that. We have been having close to weekly calls with Scott Carlson discussing ideas and ways we can improve our ideas. We then had initial design reviews and reports. We then continued our weekly meetings and redesigned the way we wanted the UR5 to be used. We then solidified how we want to do this project and made our final presentation after approval from our sponsor. We plan to meet with the sponsor and present them our design. Once that is done we plan to visit the site on a scheduled basis and work on the process itself. Below is an outline of our entire project up to the demo day at the end of the Spring 2018 semester.

7 Budget There was not a given budget limit from Kaman. However, we are required to go through Mr. Carlson about any parts we need to order and why we would need these parts so that he can confirm if those parts would be useful toward our project. Kaman has already ordered a UR5 robot that costs approximately $35,000. Kaman wanted to choose this robot to expand our project in the future to incorporate more automatic testing processes. We choose two CLICK PLCs to help with the communication protocols between the tester and the UR5. These will help to store received information and transmit information. These two PLCs came out to approximately $130. The communication between the test fixture and the PLC will be through RS-232 cables. We ordered 3 cables that came out to around $15. This puts our total budget around $35,300. Information about personnel and collaborators We are working directly with Kaman. Kaman is an American Aerospace company that works directly with the U.S government and allies. Our company sponsor is Mr. Scott Carlson. He is a manufacturing Engineer that works for Kaman and is leading the automation project. We currently hold a conference call with Mr. Carlson every other week.

8 This is a joint project with the Mechanical Engineer Department. Therefore, we have two ME Majors, Ronnie Fierro and Nate Baker, work along with us. We meet once a week as a group to work on the project. Our academic advisor is Professor Ashwin Dani from the ECE Department. The ECE students meet once a week with Professor Dani, to discuss the project. The ECE members of the group are Thomas Bacon (EE), Timothy Jorsz (EE), Brittany Bohn (CmpE/EE), and Ivan Paz (CmpE).