Time, torque, and inertia

Steve Meyer
Contributing Editor

Edited by Leland Teschler

Bring up the subject of time, torque, and inertia with a mechanical engineer, and his or her eyes are likely to light up. Most engineers, during their undergraduate career, get a firm grounding in these basic subjects. They come out of school knowing the rules and how to manipulate the equations.

Interestingly enough, these same individuals may run into troublemaking trade-offs among the three parameters when the context is motion control. Part of the problem is that motion-control applications in the real world can, at first glance, seem quite complex. There are numerous interrelated variables, some of them mechanical, some electrical, and some in the realm of control theory.

Complicating matters further is that a motion-control problem can look wholly different when viewed from the mechanical, electrical, and software domains. It is a little like the fable of the three blind men who each tried to describe an elephant. Each came up with a wildly different portrayal because they could only experience a small portion of the animal.

Motion control is similar. It is not uncommon, for example, to find that starting from the perspective of the mechanical power needed to move the load leads to a different conclusion than if one began by assuming a motor and drive of a given size. And as often as not, the control system that would provide the desired load behavior levies requirements that conflict with those obtained from the mechanical and electrical points of view.

Software in the last few years has helped designers make some of the necessary trade-offs. Several motor makers now provide free programs that size motors and amplifiers given a speed and load. The quality of these programs is actually quite good. Nevertheless, they can lead to a bad end if the user violates a few unspoken assumptions of the software creators.

Reaching a "good" solution
Most motion-control applications involve a design or sizing process that is not intensely analytical. But designers sometimes make matters need-lessly complicated by getting ahead of themselves: They begin entering numbers in servo-sizing programs without stopping first to identify the real objective of the design, though the latter seems obvious.

In many cases, the overall objective of a motion-control project is so simple that it is overlooked. It is often to maximize throughput. Spelling out throughput as the primary objective is a more powerful idea than might initially be apparent. Its value is that it provides a litmus test for making trade-offs.

For example, when throughput is the first priority, accuracy must be secondary, even though accuracy indeed may be very important. By setting priorities, the designer knows he or she can compromise the accuracy requirement if doing so produces higher speed.

Problem is, sizing software on its own can't judge trade-offs. It cannot shed light on whether the chosen combination of motor and drive can be improved.

There is another dark side to servo-sizing software. It makes recommendations that are valid only for motors from the vendor who wrote the program. Using software from one source to spec a motor from somewhere else is fraught with peril. In addition, any attempt to compare vendor catalog data will be misleading at best and may result in a system that can't perform desired tasks.

The reason is that the method for rating motors varies from vendor to vendor. Some vendors rate motors more conservatively than others in the areas of thermal transfer, acceleration, and operating temperature. A motor vendor will build these assumptions about thermal ratings into its sizing software and into the specifications it lists in catalogs. All in all, sizing software can make motors from a different vendor look much worse or much better than they really are.

Defining the load
The goal of finding the "best" motion solution involves variables that lie outside the scope of most sizing programs. There is a simple method that helps serve as a framework for examining these variables. It involves what might be called a time, torque, and load inertia triangle.

The triangle comes out of the idea that the first step in designing the system is to define the load. The main variables that define a load are the time available for the move and the load inertia. However, the underlying relationships between the two are not necessarily clear. It is helpful to view torque as a "connecting" variable in the overall solution. Thus, parameters of time, torque, and inertia can be depicted as three corners of a triangle. Solutions will consist of some combination of them that lie within the triangle's area.

For purposes of analysis, consider one corner of the triangle as fixed for a given iteration of the problem. That leaves the other two variables available for tradeoffs. Iterating on each corner of the triangle this way results in a combination of motor, drive, drivetrain, and load that provides the best performance.

There are relationships among the three parameters worthy of discussion. First, notice that time and inertia are proportional. For a system with a fixed amount of torque, the time needed to move a mass increases if the mass itself increases. Applications with large inertia masses may need a large amount of time to bring the load to speed simply because sufficiently large motors may not be available or cost effective.

In cases of a load with large inertia, a gear reducer might mitigate the need for an oversized motor. Adding a gear reducer also boosts system cycle time by the gear-reduction ratio, usually not a problem with large loads. The benefit is that torque is multiplied by the ratio of the gear reducer (minus frictional losses) and reflected inertia drops by one over the square of the ratio.

Second, also notice that torque and inertia are proportional. For a system with a fixed move time, the torque needed to overcome the inertia rises in step with any increase in inertia.

Third, consider that time and torque are inversely proportional. For a fixed inertia, the torque needed increases arithmetically as the time allowed for the move drops. The formula defining the relation-ship is:

where Tacc is the torque needed to accelerate the load and TL is the static torque of the load, both in lb-in.; Js is system inertia, lb-in./sec ² ; V is load speed, rpm; and t is move time, sec.

Inspection of this relationship provides one insight in particular: Inertia is the enemy in systems where speed (i.e., through-put) is the goal. To speed things up, reduce inertia. A mistake many designers make is to treat inertia as a constant when there are, in fact, ways of reducing it.

The point sometimes forgotten is that components that move the load are themselves part of the load inertia. Substitute lighter material whenever possible. Aluminum, for example, has about one-third the density of steel. And some newer structural plastics have densities that are half that of aluminum. If all else fails, consider extreme measures: whip out a hole saw and start cutting.

What's tough
Finally, though most motion problems can be solved without a lot of number crunching, it is interesting to examine the exceptions. Most of these fall into the category of special, high-volume applications such as disk-drive-spindle motors and drivetrains for high-efficiency washing machines. For example, consider the typical system requirements for a modern-day disk drive — operating speeds of 7,500 rpm with starting and stopping times on the order of 2 msec, achieved for no more than $10/unit for motor and drive.

Several aspects of this particular problem require close study. The small physical size and low-dollar threshold make it difficult to hit the relatively high acceleration rate. Moreover, the time constant of the tiny motor is relatively large in light of the need for 2-msec acceleration. The equations describing motor performance contain terms, such as mechanical and electrical constants, that have dependencies far more complex than for less-specialized motors.

These extreme performance criteria take motion analysis for these special cases out of the realm of simple relationships and into the domain of specialized modeling software.