Really great explanation on the basic principles that cause fatigue failures--one which even non-engineers like myself can understand. Beyond the key equations you provided at the end of your piece, are there other sources of information about materials properties or specific design tools (perhaps CAE software) that can help engineers with this design challenge?
@Beth: There are a number of CAE tools for fatigue analysis. I don't have direct experience with any of them, but some I've heard of include fe-safe, MSC Fatigue, and nCode. I'm sure there are others. Some companies have their own in-house fatigue codes.
As far as sources for fatigue data, the American Iron and Steel Institute has an excellent, free, on-line database of fatigue data for a wide variety of steels. (Registration is required). Of course, it's important to understand what you're looking at. Not only do you need to find the data for the correct steel; it also needs to be the correct condition. I've seen engineers use data for a given steel in the annealed (soft) condition when the actual part is hardened, and vice versa.
Often, though, it's worthwhile to do your own testing rather than relying on published data. The main drawback of this is that a solid fatigue testing program can take months to complete. For example, at 30 Hz -- which is pretty fast for a hydraulic load frame -- a single 20 million cycle test will take over a week, and you need to perform several such tests in order to have statistically valuable data. The advantage, though, is that you can test the alloys you actually use, in the conditions you actually use them.
That extra info will be extremely helpful to the community. Thanks so much for providing it, Dave. Your point about having to do your own testing rather than rely on third-party material stuck me, however. Given that so many companies across industries are dealing with time-to-market pressures and there are so many aspects of a product that need vertification and testing, how do you prioritize what's required for fatigue testing, vs. say what's necessary for structural testing or something else? Can development teams really afford to take the time to do this, but I guess the bigger question is can they afford to not?!!!
@Beth: We try to do the best we can using published data, while at the same time accumulating our own body of test data about the materials we use most often. This way we don't hold up the development cycle waiting for test results; we just constantly fill in the gaps in our knowledge. I suspect that this is what a lot of other companies do, too.
We also try to avoid component-level fatigue testing where possible. For example, if you understand how die-cast 380 aluminum behaves in fatigue (and the effect of casting porosity on the properties), you can apply that knowledge to any die-cast 380 component; you don't have to repeat the test for each part. But for some components, like crankshafts, component-level testing is a must.
Thanks, Dave, for such a complete intro to fatigue failures. I also find it especially interesting to read about all the CAE tools for fatigue analysis. Beth's second question and your response is also intriguing. It sounds like there's a need for more centralized fatigue databases of materials and/or parts made with them. Each company doing all this on its own and building up its own database seems awfully wasteful of time and energy. Is this info just too hard to centralize and keep updated?
Dave, loved the article, and this response. I think you should qualify the use of software further though. You pointed out you need to use the right material, in the right condition. Anyone who reaches for fatigue software is likely NOT to find the correct material for their analysis at one point or another. Using a similar material as "close enough" is also likely to lead to erroneous and dangerous results.
In a bid to boost the viability of lithium-based electric car batteries, a team at Lawrence Berkeley National Laboratory has developed a chemistry that could possibly double an EV’s driving range while cutting its battery cost in half.
Using Siemens NX software, a team of engineering students from the University of Michigan built an electric vehicle and raced in the 2013 Bridgestone World Solar Challenge. One of those students blogged for Design News throughout the race.
Robots that walk have come a long way from simple barebones walking machines or pairs of legs without an upper body and head. Much of the research these days focuses on making more humanoid robots. But they are not all created equal.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.