My first job as a mechanical engineer was with the office products division of a huge corporation. I was assigned to fix the design of a spring clutch that failed prematurely on a copier. The spring clutch design worked for hundreds of millions of cycles in an application in another office product the company made. On this particular copier, the clutch consistently failed at around 20K cycles. Conventional wisdom suggested that the torque was the same between the copier and the other product, and thus the application was almost the same.
This spring clutch transmitted torque from an input arbor to an output arbor, through a helical clutch spring, all mounted concentric on a shaft. When the input end of the clutch spring is held off of the input arbor, the input arbor spins freely, as there is no contact with the inside diameter of the spring. When the input end of the spring is released, the helical spring wraps down around the arbor. Friction between the input arbor and the spring starts the spring spinning with the arbor, like the “rope around the tree” concept for transmitting torque.
The clutch spring is clamped to the output arbor, so when the spinning input arbor gets that spring wrapped around it, all three components are rotating at the same angular velocity in short order. In this application, the load the output arbor drove had a significant inertia. The conventional-wisdom data was collected by multiple sets of previous engineers who worked on this clutch.
The process they all used was similar. They estimated the torque by multiplying the calculated rotary moment of inertia of the load being accelerated by the angular acceleration. Even back in the stone ages, we had DC tachometers that gave a dynamic angular velocity output with a reasonable frequency response that we fed into our storage scopes and took Polaroid pictures of. Theta dot vs. time –- lay a ruler down, and you can figure out acceleration. But something wasn’t right in this picture. Why would the same load yield only 1/10,000 the life in a new application? Sherlock Ohms, help?
I agree. It is important to learn from your mistakes, but there is just as much importance to not be too complacent in your sucesses. Just because something worked once does not mean it will always work in all applications.
Of course, the first failure was with those who assumed that since the application was similar, that the torques would be the same. That kind of thinking is lazy, with no excuses. Of course, there is a lot of lazy going around. Ignoring the deformed clutch spring is even worse, since that is such a very obvious indication of an overload. Making your own torque sensor was certainly one way to find out what actually was happening, I guess that was what you had to do, because there did not used to be any source for torque sensors. But making your own sensors like that would be expensive.
Probably it would have been useful to study the previous design that had a good track record and find out what was so different, since possibly it would be something that could be used in the newer design, (except that there were lots of them already in the field).
I have seen a few disasters caused by people thinking that something was the same as the previous version.
I may be having a slow day, but I saw no explanation about why the clutch that had worked for years was now failing. I would infer that the new application required more start up torque and therefore overstressed the clutch more than previous applications. Is that right?
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 radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.