ME 416/WSU specific advice
From wsuwiki
Contents |
Specification Problems
Find people who know their stuff
By: Casey Harman
Probably the most important thing I learned in 416 was to seek out people who know about the topic I’m interested in. When Precor, our project sponsor, decided to that they wanted us to experiment with rivets, we were clueless on what to do and where to look. For several weeks we did research on the internet and failed to produce any meaningful results. During the conference calls our sponsor asked us questions that we were unable to answer.
Finally I took to trip down to Norm’s shop. He apparently worked extensively with rivets when he worked on airplanes. Norm told us everything we needed to know about rivets. Within two days we were able to return to our project sponsor with good solid data and were able to move forward with the project.
Find people who have been working in their field for a long time. When the Precor design team decided to use a hydraulic system, we found a local supplier in Lewiston. Our contact there, Mike Knoll, has been in the hydraulic industry for 27 years. He was able to order the hydraulic parts we needed for the cheapest price possible.
Many of the large suppliers have technical assistance. If you call them they may be able to recommend the products you need. Eaton Electrical, the company we ordered our PLC from, has excellent technical assistance. We were able to call them and within five minutes we had the part numbers of the products we needed.
The moral of the story is find people who know their stuff and ask lots of questions.
Company Visit Documentation
By: Joe Giacalone
One ME 416 group is doing their senior design project for BP Cherry Point Refinery. The project is to design an unloading system for the metal shear in their machine shop. At the beginning of the semester they talked with their contact at BP and set up a meeting at the refinery for the third week of the semester. When the group traveled to BP they were prepared to document their customer’s needs with drawings, dimensions and pictures. They documented this project to the extent they found acceptable and returned to Washington State University to begin design work on the project.
As the conceptual designs began to surface, the group members realized that maybe they did not document the project as thoroughly as they thought they had. As conceptual designs turned into more sophisticated designs involving accurate dimensions and precise geometries the group came to realize that they were missing many dimensions from the existing shear that would need to be known to continue the design process. The group was forced to contact their BP sponsor and ask for the missing dimensions.
The group visited BP with little idea of what the project actually was. If the group would have had a better idea of what the project actually entailed before visiting the site, they could have begun some very preliminary conceptual design before the visit. This would have given them a better idea of what dimensions from the existing shear would need to be documented. Because BP is 350 miles away from Pullman, missing information had to be found at the sponsor’s expense.
Scope Creep
By: Matt Ahl
The specification for a design project usually gets nailed down in the very early stages of a project and the students progress from this point. However, all too often the power of this document is forgotten. When executing a project any engineer must remember to use this as the project control and refer themselves and the sponsor back to it in times of confusion. This case study is a great example of the industry buzz word: “scope creep.”
The Hamilton-Sundstrand oil pump test rig upgrade project was already very different from the beginning. A test rig was already built and our job was to upgrade the components. During the kickoff meeting the project sponsor requested that the group spend a couple weeks running the test rig in order to better understand the necessary upgrades. This seemed logical to the group, so we eagerly agreed. Little did we know this would cause the project to take an entirely different direction.
Since the project was so well defined by the existing hardware the group was able to create a detailed project specification. This specification briefly touched on initial rig testing and focused on redesigning and upgrading. The project sponsor did not really acknowledge the details of this document, and therefore it was brushed aside by both parties. During the weekly teleconference with the project sponsor continued to focus on better, more in-depth testing. This became the proverbial fork in the road.
More, more, and more testing is what the sponsor wanted; so the group followed their requests and continued to test as the semester rolled on. Every week the original timeline was pushed back further and further as the testing took precedent. Just before the mid-semester review of the project, it became apparent that there were two different projects being tackled; one the original specification dictated and one the sponsor now wanted. There was no longer enough time to complete both and an ultimatum had to be presented.
There was very little time left in the semester and the resign and upgrade laid out in the specification would be difficult to undertake. The testing requested by the sponsor was do-able, but no upgrades could be made. The sponsor reluctantly agreed to finish the testing and gather as much data as possible. There was a three week period where each teleconference became more frustrating for the design group and the project outcome seemed to be in limbo. All of this frustration and lack of direction could have been avoided if the group stuck to the original specification and always referenced it when the sponsor would ask for more testing, data, etcetera.
The moral of this story is to stick to your original plan. Don’t let your sponsor push you around. If a change is needed, mutually agree on modifying the specification. This will ensure good communication between both sides and an outcome that both parties can appreciate.
Specification Creep
Hamilton/Sundstrand Corp is a world leader in the development and manufacture of systems for the aerospace industry that range form commercial aircraft to defense systems design and testing. One of the main products that HSPS manufactures is Auxiliary Power Units (APUs). APUs can be found in the tail sections of many aircraft and serve multiple functions. A typical APU is a compact gas turbine coupled with an electric generator.
The task of our design team indicated that we were to tear down and rebuild the APU oil pump test rig built the previous semester in order to incorporate new parts. In addition, we were told to spend a little bit of time running the current rig to become accustomed to its quirks, confirm previous data that had been taken on it, and figure out what we wanted to change. We eagerly agreed to this, began ordering parts necessary to make the rig work again, split up the design process amongst ourselves, and started to take data. It soon became apparent that the data acquisition system was not set up correctly. Bringing this news to our sponsors at the next teleconference, thinking that we would be instructed to continue with our re-design and re-design the DAQ in the process, we were told that before we could tear the rig apart, they needed hard data. This was a somewhat unexpected extension of the specification, but we went with it.
However, as time went on, even more problems with the rig were discovered: The heater was not capable of heating the oil up to the specified temperature, the outlet transducer was placed in such a way that it was ruined by pressure spikes and blew, and the entire DAQ program was incorrect. Meanwhile, as we struggled to fix these problems we were running out of semester. Finally, we knew that we could not possibly finish all the tasks in our original spec by the end of the semester if things were to continue to proceed in this way. Our frustration continued to build as each weekly teleconference left us more confused.
In about the 9th week of the semester, we called in Dr. Chuck and told our sponsors at the next teleconference that we could either get the rig going and take data, or we could do their re-design for them, but we couldn’t do both. They reluctantly decided they wanted data instead of a new rig. In retrospect, we should have brought up this issue with them at least three weeks earlier, when we knew that we were behind schedule. This would have been much more efficient and less stressful for us, because we would have not had to work on re-design, and would have been able to concentrate on getting the rig running. Be sure to keep referring back to your spec and original timeline. If you get off of the timeline or spec, talk to your sponsors and Dr. Chuck to make sure that you know what you have to do to graduate.
--Ldeibler 09:46, November 7, 2006 (Pacific Standard Time)
Time Constraints
By: Walter Langford
A very important component in a project is that at some point it must end. Therefore, the issue of time constraints and team capability become key issues. A major issue has arisen in my team’s project. Two pressure transducers have failed under operating conditions, thus causing possible safety hazards and cost of money.
Three questions have arisen regarding this problem. First, what is causing the transducers to fail? Second, do we have enough time and the capability to determine what is causing the transducers to fail? The first question cannot be answered until the second question can be answered. If we cannot solve this problem, can we finish our project by completing all of the specified pump performance tests? As everybody knows, investigation and troubleshooting takes time…
We have not completely isolated the problem, however the team has decided that testing must go on, regardless. The project must be finished, thereby resulting in a deliverable to the customer. Given the time constraints (and we are running out of time) a full investigation is out of the picture. However, steps have been taken to prevent the failure of another transducer.
The team has narrowed the cause of failure down. Most of the electrical issues have been dealt with in the DAS and wiring. We also discovered that we sampling at too low of a rate for all of our sensors, resulting in alias frequencies and poor monitoring of the behavior of the system. We think the transducer is failing due to fatigue loading at higher flow rates and greater pressure differentials across the pump. The fatigue loading is a result of the pulsation of our vain pump. When we starve the pump for fluid (pressurize the system), the vanes pulse with greater amplitudes, which may be damaging the transducer. To prevent this, we are going to place a stop cock valve in series with the transducers, to prevent the dynamics of the pressure from reaching the transducer. Hopefully this will work and we can finish our project.
A variable that has not been investigated is vibration in the system. We don’t know what the rig vibrates at or how it behaves dynamically. This type of analysis would involve placing accelerometers on all the components of the rig and testing for frequencies at different operating conditions. This would involve an entirely different type of testing and analysis, and we don’t have the time.
The moral is, get done what you can get done and troubleshoot what you can troubleshoot. Take care of the major issues as best as you can with the time aloud. Don’t focus on one thing and stop the whole show, because you won’t finish your project and you won’t have a happy customer. I’m not saying ignore the issue that cannot be dealt with, just keep them in mind and document them well for whoever approaches the project next. Maybe they will have the time to solve the problem that couldn’t be fully dealt with.
How to have a good Conference Call (its not as easy as you think)
By: Daniel Stone
Conference calls are not something ME 416 students generally stress out about – it’s really only a conversation with your employer about work that’s already been done. However, there are a few preparations that will greatly increase your success and the impression your employer has of your group.
Let’s start with the story. The conference call date was set, and the room had been selected by our liaison. The time came to make the call; Steve (a fellow Wagstaff project member) and I arrived five minutes early to set things up. The first problem was no outside line – hence lesson 1 is to set the conference call up so that the employer calls you, or else you’ll have to get a long distance code from Jan. After calling our employer, Craig, on a cell phone, we soon found out another disturbing fact: he had posted on Base camp about 1 hour earlier that we needed computer and internet access, which the conference room was entirely void of. Hence lesson 2: check Base camp about 20-30 minutes before the meeting. We were now without an adequate conference room, computer, Liaison (she hadn’t arrived yet), or Dr. Chuck – basically, we were up sh^#’s creek. We could not use the EE/ME computer lab, as the computer settings cannot be modified, and there is no speaker phone. But just as everything had gone wrong so far, everything began to go right. This brings me to lesson 3: stay positive and optimistic – even if things look really bad, because a negative attitude will only make it worse, and often a solution may be right around the corner.
The solution was to use my work computer (luckily I work nearby in the ETRL 122 lab), and my new cell phone with a decent speaker phone. Our liaison arrived, and we carried off a successful meeting. The meeting was successful because 1. We worked as a team (our liaison set up the call while I set up the computer), 2. We were prepared with an agenda (a must do for an organized conference call), 3. We had good work to discuss (which always makes the employer happier), 4. We got lucky – a computer whose settings could be modified, the arrival of our liaison in time for the call, and a recently bought cell phone with a good speaker phone. As a final bit of advice, get drunk with your team after a stressful event – it helps the team dynamic and is generally just a good idea.
Project Complications
By: Aaron Wilkinson
One of the fall 2006 groups in the ME 416 design class at Washington State University was assigned to the Puget Sound Naval Shipyard (henceforth referred to as PSNS) for consulting. This consulting project involved designing an articulated nozzle for cleaning the inside of stainless steel tanks. When the group assigned to this project first looked at the problem, it seemed relatively straight forward. However, once concepts were generated and compared to specs it was realized that this was a much larger task than expected.
A large amount of time was spent researching cleaning systems already in use. This turned into many dead ends. Although most of the manufactured systems did not meet the spec in at least one way, many things were learned from these devices. The problem was also complicated by the delay in travel to the project site. Due to security clearances the group was not able to travel until half way through the project. Once at PSNS, many more design ideas and flaws were realized. In the long run, a final concept, that was later approved, was drawn up while returning to Washington State University from PSNS.
Hindsight Is Always 20/20
By: Bryce Eschenbacher
This cliché saying actually has some meaning for me and my group this semester. We have been assigned to design a manipulating end effector for the Boeing Company. This effector would need to have six degrees of freedom and be able to support 450 pounds of weight.
The design process yielded many ideas of how to accomplish this, one of those ideas was a Stewart platform. This consists of two parallel plates connected with six triangulated linear actuators. The idea is that for any motion, linear or rotational, can be achieved by manipulating all six actuators together. The computer program alone would take six months or more to complete. We should have let the idea go at this point.
But we continued on and actually found a complete program, written for MatLab, which would work for us. We have the program at school and can easily assemble the platform and get it hooked to a computer. The problem that we didn’t see for another week was that Boeing would have to purchase the industry version of MatLab with Simulink and SimMechanics, which comes in at the $10000 price range. Suffice it to say Boeing was not willing to shell out that much money for a program they would only use for this application.
We have since reverted back to our simpler idea that requires only the human body to work. We could have avoided the disappointment of having an idea not work by looking at the price of the required program up front. We also would have saved ourselves the two weeks time it took to come to the conclusion that we couldn’t do this.
But looking back makes everything clear…
It Pays to be Honest and Realistic
By:Jaime Gilbert
Who would have ever thought that a donut making machine would lead to such life lessons as honesty and setting realistic goals? We started out the semester thinking that we were only going to be redesigning an oversized mammoth of a gear box but have realized over the course of the past 10 weeks that we are having to do nonlinear analysis of hyper-elastic materials using computer programs that are only used by graduate and Ph.D students. This leads to lesson number one, make sure that you know what your project sponsor really wants and don’t try and be superheroes and give them more than they ask for, it is going to chew up your time and you will most likely just find yourself loosing track of what the real project scope is.
Lesson number two, it is important that you are honest with your project sponsor. If you are having troubles with your project, make sure your sponsor is aware if it is possibly going to affect the outcome of your project. In our case we had a hard time acquiring and learning ABAQUS to do non-linear analysis and it wasn’t until the 10th week that we found out that it would take 6-8 weeks to have a new prototype made and back to us for the testing that is required by our sponsor – BIG PROBLEM!
In summary, don’t try and be a superhero in ME 416 and be honest with your sponsor about your problems, it will save your butt in the end!
Technical Help
Shop Access
By Nicolas Juliano
Within the time an undergraduate engineering student spends at Washington State University, they get the opportunity to be involved in projects that require hands on manufacturing. This opportunity can come in the form of a senior design project or engineering clubs. To complete these projects the engineering department has manufacturing facilities. However due to lack of support, getting any project done that requires the facility at the undergraduate level is a struggle, but not impossible. In the case study of the Robotics@WSU, an engineering club, we can see an example of the struggles encountered to complete a project.
In the fall semester of 2004, the club began to plan out their design for the Robomagellan competition. As the design came to fruition they needed to acquire parts and equipment for the project. As they went to attain these items, they encountered their first hurtle, which was getting their purchase orders processed. This involves the purchase order being approved and then submitting it to be ordered. On average the processing of the order could take up to a week. This led to consistent delays in acquiring materials. This in turn pushed back the completion date.
The next step in the project was the actual construction. This involved machining and other manufacturing processes. To understand the restrictions the robotics club encountered along all engineering students, you must understand the way the shops at WSU work. WSU has two machine shops available to undergraduate students. The shops are in the basement ETRL and TRFB L20. The hours of operation for the shop in ETRL are in three hour blocks on Tuesdays and Fridays. This time is mainly intended for the ME310 manufacturing labs. It is also sometimes open during other times during the week for research projects. As for the week end it is not open. The shop in TRFB is mainly geared towards sheet metal fab and welding. It is open from Monday through Friday. To use the shop requires 24 hours notice on a signup sheet. If you do not signup ahead of time, you will not be granted access. However it is sometimes available on the weekends if you know the right people. It should also be noted that even if you get access to the shops, you will find that they are minimally equipped with tooling required for the machinery.
When Robotics@WSU realized the limitations of the facilities, they found creative ways to work around them. The first was to implement components in their designs that could be produced to size by the manufacturers. One specific example is the frame used in the Robomagellan robot. It was made from structural extruded aluminum. The manufacturer of the tubing cut it to length and then sent to it with fasteners as a kit. With this approach, the frame only required being assembled, much like an erector set. Another example of working around the shops was the members of Robotics@WSU bringing their own tools. Since access to the machine tools is hard as previously described, one of the group members brought a desktop mini lathe from home. With the lathe in hand, the group could complete parts during their schedule. By thinking critically about alternative construction designs and bringing their own tools Robotics@WSU was able to be successful in their pursuits.
From the struggles that Robotics@WSU encountered we can take away some important ideas. The first is that if the students have the drive and determination to get their projects done, they can and will. Another important fact is that similar stories are told again and again. As a suggestion to interested parties, to avoid the issues Robotics@WSU encountered, clubs and projects require support from the faculty and easy access to the manufacturing equipment.
Calling The Vendor
Vendors are an important resource for getting the parts needed to complete any project. Often you will come across a potential vendor during an internet search for some part or tool you need. For the Puget Sound Navel Shipyard (PSNS) pipe cutter project, it was decided that two different purchasable tools would be investigated. The MRA Maintenance Pipe Cutter from George Fisher and the Small SB Clamshell pipe cutter from Tri Tool.
The first step before calling the vendor is to familiarize yourself with their product. Find out what exactly they have to offer and if the product will actually meet your needs. There’s no point in calling the vendor if the product just isn’t going to work. Upon reading the information about the MRA pipe cutter from George Fisher’s website and the Clamshell pipe cutter from the Tri Tool website both appeared to meet the needs of the project.
Next you will want to get the product/part number from the website and the information to call them. It’s always a good idea to come up with a list of questions before you call, that way you can just work down the list.
Some important questions to ask:
- Have a specification for the product mailed, faxed, or e-mailed to you.
- Shipping time
- If they offer any modifications to their product, i.e.: from the PSNS project, do they offer an electric motor rather then a pneumatic one?
- Price
When talking to the vendor, often they are very knowledgeable, so going over the specifics of what you plan to use the product for will help clear up any possible confusion and acts as a check to make sure it will meet your needs. The vendor should be able to clearly explain what the product is and how it works, if not they should be able to get you in contact with someone who knows the information. When talking to Digital Welding Systems Inc., which is the vendor for the MRA pipe cutter, they felt that for the PSNS application the MRA pipe cutter would not be a good fit. This is because the wall thickness of the pipe that PSNS will be cutting far exceeds the working range of the MRA pipe cutter. Therefore the MRA pipe cutter concept was dropped.
Remember always that the vendor is there to help you out so if you have any questions just ask. If for some reason they do not feel that the product will meet your needs, perhaps they will be able to suggest some other solution. If they aren’t able to verify that the product will meet your needs then either you will need to provide some more information about what your requirements are or the product is not right for your application. In the case of the Clamshell pipe cutter, Val from Tri Tool was able to say that the tool would indeed meet the needs of PSNS cutting application.
After verifying with the vendor that it is indeed what you need you can begin to talk about ordering the product. It is usually a good idea to have them quote you the price of everything you will be ordering in writing. That way you have a hard copy to add to your file. Val gave a cost breakdown of all the parts which PSNS would need to purchase for the Clamshell cutter and he faxed a copy.
Seimears 13:56, 1 Dec 2005 (Pacific Standard Time)
Track your order
By Yen-Chia Huang
After purchasing parts from vendor, it is very important to ask them specific ship date of your order. Thus you and your group have an idea when the part will arrive. Most of vendors give an general answer as “It will take like 5 to 7 days”. At this situation, ask your vendor the tracking number. It is very important when your group is doing a project with limited time. Many unexpected things may happen during testing, do not waste too much time on waiting because your group will need extra time for fixing errors.
Equipment Selection
by Nicolaas Verhoeven
Choosing the right equipment can be a tough choice. At first it might seem overwhelming and you don’t know where to start. This is what it was like for me and others at “Cougar Flight Systems”. We were designing a data acquisition system (DAQ) for Ellison-Mahon Aircraft on their custom built amphibious aircraft. They wanted more than ten parameters monitored simultaneously, which meant our group had a lot of equipment to select.
We found the easiest way to select equipment was to subdivide the different equipment to different members of the group. Each group member looked at a few different options and did research on its capabilities and limitations. After all the general data was gathered they presented it to the remaining members of the group and we had a discussion on whether it would get the job done or not. This way of dividing the work made it fast and efficient and everybody still had a say in the design process. We proceeded to find a best possible choice and do even more research about each one so that we could become very knowledgeable on every equipment choice we were going to use.
We ran into the problem of choosing some equipment that after further research we discovered would not meet our needs. So we went back and looked at some of our previous choices. This is a great example of why you need to be flexible when choosing equipment. There might be design changes, price changes, or size requirements that cause your equipment choice to be reevaluated. We anticipated this and it allowed us to quickly change to an alternative.
I feel these are some typical problems and some good solutions to many problems that ME 416 students will face. I hope that they help future students avoid serious equipment selection problems. Just remember that sub tasking can accomplish things very efficiently and be prepared to adapt or change if a problem arises.
Documentation - Equipment Selection
By Johannes Meyling
One of the greatest hold ups in the progress of taking an engineer design to a product is lack of documentation. Our group had everything figured out for ordering pressure transducers to measure both airspeed and altitude of an aircraft, except when it came time to get the verification to proceed with the order, we did not have solid calculations to support the hardware we wanted to purchase. This not only delays the delivery of the equipment that might be pertinent to your product, but most of all it could put you in a position that could completely undermine your credibility.
The lab reports that we have all done in the past requires documentation and theoretical background on the equations that are used for data reduction. This aspect of the lab reports carries directly over into the design analysis, proposals and supporting documentation that all lend to building your credibility and the customers confidence in the product that you are providing. This documentation of equations and supporting theory does not need to be a huge comprehensive and elaborative report, rather, it should be specific to a particular engineering design decision that the group has made.
Our group was responsible for providing a complete flight data recording system that monitors a comprehensive amount of flight data for determining the performance of an experimental aircraft. Two of the most important measurements we needed to record were airspeed and altitude. After searching for various equations and data on those two calculations we were easily able to reduce the data we found to specific accuracies a pressure transducer would need to have. We did not have any documentation, however, to support what we had reduced from the information we collected and quickly realized we needed to work the “numbers” out thoroughly and provide the supporting information to increase our credibility and keep the project moving without hold up. We wrote two small reports complete with equations, theory, sample calculations and recommended pressure transducers that the customer was able to review and make an educated decision on which pressure transducer to use. This was extremely important because the cost of certain pressure transducers are quite a bit higher than others, and the documentation proved extremely beneficial in convincing the customer that the higher priced pressure transducer was indeed the best suited for the job and that it could be seen as an investment for long term use in other areas of experimental data collection/monitoring.
This lack of documentation on our part initially could have prevented us from meeting our milestones and ultimately our product due date. Worst of all it could have completely destroyed our credibility and gave us nothing to rely on in the event that the pressure transducer would not provide the accuracy that the initial specifications required. We strongly urge you to professionally document supporting information for your decisions.
Designing a user interface in Excel
By: Randal Morrison
For our ME 416 project, we were asked to develop a data acquisition package to monitor different flight parameters for an experimental aircraft. Our client is on a strict budget and has asked us to find the cheapest way to accomplish our goals, to that end we have focused on borrowing equipment from WSU and writing our own software.
My focus for the past two weeks has been developing a software package that meets all of our goals. When ordering a DAQ we selected one that included software that would interface directly with Microsoft Excel. When the package arrived, I installed the software on my computer and quickly found that it did not meet expectations. While the software did indeed interface with excel, it only dumped the voltage readings into a spreadsheet. It did not allow us to convert the voltages in to meaningful values. Whenever the user tried to interact with excel while the DAQ was reading voltages the software would crash. This created a large problem, how can we view meaningful data in real time with out the program crashing.
At first, I decided to write a VB macro that would convert the voltages as they came in. I used a user form (dialog box) as the interface for displaying the converted values. This did not work. The user form conflicted with the data acquisition and caused the software to crash, which sent me back to square 1. When examining what went wrong I realized that the DAQ software was basically a macro and the user form was a macro, and that I could not have two macros running simultaneously on the same sheet. The obvious next step was to have the voltages sent to a second spreadsheet in real time and work with that data. This second spreadsheet now holds the converted data, no longer in units of voltage but converted to meaningful pressures and speeds.
Once the values were in second spreadsheet I found another problem, it was difficult to view the data in real time; also, any graphs that I was able to create had to include all data points. Including all data points made the graphs to hard to read. So there I was, major problem number two. I needed to com up with an interface that would show only the current values of the data, as well as graphs that functioned as strip charts. Strip charts only show the past 5-10 data points in real time, thus allowing the user to quickly see what has happened in the past few seconds. To solve the problem I made another spreadsheet, this spreadsheet contains many macros whose main job it is to grab the most recent value from spreadsheet 2 every time a calculation is made in sheet 2. This setup provided a real time display showing only the current values. I was also able to write a macro that would grab the past 5 values and use those values to create strip charts of different pressures. Problem 2 had now been solved, on to the next issue, our clients wish list.
In our project kickoff meeting, our client said that ideally the software would integrate live video, the pilots com set, and the data. This was no short order. How can you get excel to stream live video, and record audio from a completely different source all while taking data from a DAQ. An even bigger issue is how you synchronize the video with the audio and with the data. It didn’t take long to realize that with our time constraints it was not possible to get excel to stream live video, o I focused on recording live audio instead. Recording the audio turned out to not be a big deal a few macros and a few push buttons on the spreadsheet and it was done; now it was time to play with the video. I decided that we should get the video, audio, and the data synchronized in a post processing view rather than while the data was being collected. To accomplish this I made a new user-form and used Active-X controls to play back the pre-recorded video and audio. I then was able to get the user form to display the collected data one reading at a time. The next big hurdle was figuring out how to synchronize the three sources. In order to synchronize the three sources I decided that the pilot would make an audio “mark” when he starts the video recording and again when he started the data acquisition. With these “marks”, I was able to set the system up with a “mark” button. The user would press the button when he wanted to mark the data source. Once this was done, the three sources would synchronize and the information could be viewed all at once. The next step was to send this to the client to get his approval.
I sent the files to the client and anxiously awaited their response. The next day during our weekly conference call, they said that it looked great but they had changed their minds. They did not feel the need to have everything synchronized so precisely and no longer wanted the hassle. Disappointed I said okay, and now plan to remove all of the synchronizing code from the software.
Getting The Job Done
By Nick Gosseen
Belshaw Silicone Boot Redesign
Our group was designed a relatively simple task of analyzing a silicone rubber boot that covered two translating metal arms to prevent leaking. Our goal at the beginning of the semester was somewhat ambitious, in that, we wanted to redesign the boot as well as the entire gearbox behind the boot (that were responsible for the arm motion). Our first mistake was assuming that our initial problem of the boot redesign was too simple. We only considered how to design a boot, but did not take into account the lead time it would take to have a boot made and what it would take to test it. Eventually the group decided that it would be too much to redesign the entire gearbox, so we were then left with our initial problem of the boot. We met with our project sponsor and he made it clear that he would want a tested design by the end of the semester. We finally discovered this with 5 weeks left in the semester. By the time we contacted the rubber company, it was decided that a prototype boot would take 6-8 weeks to fabricate. This leaves us without being able to do the proper testing in the given time of the semester. Point is, make sure you know exactly is expected to be delivered at the end of the semester. If the company asks for something that you see to be too easy/simple… GO WITH IT and don’t assume that there wont be complications along the way. Do what your asked, do it well, and just get it done
Listen to your Client
By: Gregory Curtis
Our clients asked us to redesign their vacuum hose reels and solve several problems that they had with the ones they were using. When we met with them at their company, our clients asked us for our ideas, and then mentioned some of their own. They seemed to particularly like the idea of using plastic or sheet metal for the hose reels. After we got back, we all came up with complete design concepts and went through the design improvement and selection process. We had a few conference calls with our clients during this process, during which our clients recommended plastic as a less expensive alternative to metal in the long run. Based on these calls, we created a final design that used plastic sides for the reels, and stainless steel bars for the core connecting the sides. We liked this design because the sides would be inexpensive to rotomold and the core bars were simple and easy to make.
At our next conference call, we realized that our clients had been recommending plastic because the price of stainless steel has been increasing lately. They also liked the idea of a telescoping core, and metal bars cannot do that as easily as a plastic core. This ment we had to go back and redesign our core section as a plastic telescoping core. We were not put too far behind, because our clients liked the rest of our design, but we would have had more time if we had listened to our clients' suggestions to start with.
Avoid Needless Competition
By: Nick van Schoonhoven
In spring of 2007 members of both the morning and afternoon section of ME 416 were assigned to work on a lubrication testing machine for Boeing. Both groups went on a tour of the Boeing facility together and met with the project sponsor. The project sponsor asked that both sections work independently on designs for the testing machine with the intent that one design would be selected before both teams merged to build the machine. All well and good on the face of it, but in practice it caused no end of problems. The first major problem was the wasted time. Having two separate groups meant that vendor resources weren’t shared. Also, it meant that both groups were reinventing the wheel for things the other group had already worked out. Finally, when both groups had their design worked out, it took the sponsor a few days to decide what design they liked. However, they didn’t just pick one design; they wanted parts of both designs melded together into one. This cost another week in trying to rework both group’s design. The second problem was the unnecessary conflict between group members. Both groups thought their design was the best, so coming up with a united group design meant stepping on a lot of people’s toes. Had the design group insisted initially that a competition would be a bad idea, all of these problems would have been greatly minimized. The project would have been completed much faster and with less stress and strain on everyone.
Living with someone else work
By: David Anstead
Our project sponsor, Hamilton Sundstrand, has been working with the design clinic for a while. Our specific test rig is now three semesters old and has accumulated a fair amount of documentation. The truth is documentation will not always give you some of the simple answers you need. When we started trying to familiarize ourselves with the rig we worked off a startup check list from last semester. We tested the sensor and were ready to start the data acquisition programs but couldn’t find them on the computer. This prompted us to make a call to a member of last semester’s group. His answer “They should be on the computer with the rig”. After a few days of looking and trying to rebuild the programs from what we had hard copies of we noticed that the programs save paths were in the other user account on the computer. We called our contact from the old group for what was the third time in as many days for our twentieth question “what is the password?” With the answer “It’s something like…” we got in with only four tries.
The lesson is, the answer to you problem could be very simple and easy to track down but do you know what to ask? If you are writing instructions they will never be perfect because little things that you take for granted could leave someone stuck.