Recent strides in computer and communications technology, combined with falling prices in electronics, have led to a situation where motion control systems are as varied as the applications they serve.
Behind all this variation, however, are three basic motion control architectures:
PC-based ... embedded ... and distributed.
In the past, when controllers and amplifiers used to cost more than motors, motion architectures tended to be more centralized to minimize system cost. Now there’s no such limitation, making it easier than ever to adequately solve motion problems.
PC-based, embedded, and distributed motion are the most common architectures among machine designers. These three, in one way or another, reflect the rapid improvement in the performance of digital and power electronics, as well as a reduction in their cost.
PC-based motion
A major trend in motion architectures is the increasing use of PCs as “host” processors in motion control applications. A typical PC-based motion system consists of a motion control card located inside the PC and external motors and amplifiers.
In recent years, a growing number of systems engineers have discovered the PC for use as an engine for control-oriented applications. One of the reasons for this is that the PC has become both inexpensive and more universal. Touch screens, keyboards, monitors, and a number of other off-the-shelf I/O devices make the PC an ideal platform for communicating with the machine operator.
The motion control industry has capitalized on this widespread use of the PC, and there are a broad range of motion control cards available which provide cost-effective and powerful motion features. In general, there are three levels of PC-based motion card solutions that designers can choose from.
Fully programmable. This type of card is the most common today and is available from several vendors. Thanks to onboard processors, such cards relieve the PC from time-consuming tasks. Users download complete programs in a standard language, such as “C” or in a proprietary language, and the card’s microprocessor handles the motion-related tasks.
One disadvantage, however, is that these cards may require programmers to write code in a language that is not supported by other vendors. The cards are also generally more expensive than the other types.
Semi-programmable. These cards have come on strong in recent years. A motion engine, which can perform various motion activities such as trajectory generation, servo loop closure, and commutation, is provided on the card. However, self-executing programs cannot be downloaded to the card. These card solutions are almost always based on off-theshelf motion chips which form the basic motion engine. In this approach, the PC provides the high-level sequences and serves as the “host” machine controller.
Consider a typical application where the host downloads a move command to the card such as, “Move axis #3 trapezoidally to location X.” After receiving the command, the motion card executes the entire move, performing all profile generation and servo loop control, and finally, signaling the host that the move has been completed. At this point, the host sends a new command, and the process repeats.
Semi-programmable cards are generally less expensive than fully programmable cards. And they don’t require code written in a vendor-specific language. The disadvantage is that the PC code may become more complicated, since it has greater real-time responsibilities for the system operation.
Nonprogrammable. In this approach the PC performs all motion-related activities, including profile generation, servo loop calculation, pulse generation, and real-time signal management. The card supplies quadrature encoder feedback and hardware-generated signals such as analog outputs and PWM generation. The advantage of this system is the simplicity of the hardware and its low cost. The disadvantage of this approach is that it requires a very detailed understanding of the PC’s operating system to be effective.
Embedded motion controllers
With an embedded approach to motion control, the three major elements of the machine controller (the host CPU, motion engine and amplifier) are combined onto a single embedded printed circuit card. This approach is used in situations where the machine controller must be low-cost, compact, and simple to maintain. Although some embedded motion controllers can be purchased off-theshelf, most are designed and assembled by the machine builder.
Embedded motion control has become more popular over the last ten years, largely due to the emergence of off-theshelf intelligent motion integrated circuits (ICs) known as motion processors. These processors are generally built around a digital signal processor core and often have an associated peripheral circuit to handle motion-specific interface tasks. Motion processors are available from a number of manufacturers for dc servo, brushless dc, and step motors. Designing an embedded motion controller is relatively simple, because the motion-calculation and signal-processing functions have been standardized. Many manufacturers of motion ICs provide example schematics, which show how to interface the chips to various microprocessors.
Embedded motion controllers have a big advantage in that they can be built to exact specifications. In addition, they also make it possible to design cards with the exact physical shape that is required as well as the input power scheme that is needed. Embedded designs also eliminate much of the inter-card and intermodule connections, which are often the cause of machine failures.
A number of factors, including time to market, projected sales volume, and development resources, determine whether it is worth the effort to design and build an embedded motion control card.
Distributed motion
While PC-based and embedded motion techniques give the machine designer important options for building a motion controller with the characteristics they want, neither of these techniques directly attacks the reliability problems associated with high wire count and with long encoder line and motor leads. Both PCbased and embedded motion control are centralized control systems. Distributed control systems have a local controller at each motion node close to the actuator.
The nodes talk to each other over a multiplexed “local operating network” or device-level network, receiving high-level commands from the host processor. Motor signals associated with each axis are processed locally, and, in one form or another, a local processor manages the motion problem, thus eliminating the need to physically return encoder and motion signals back to the host.
This approach may seem wasteful because of the duplicated controllers at each axis. However, there is less wiring than in a centralized approach. In a distributed control system, “smart” amplifiers receive signals from a bus that travels a single network wire from a controller. This setup is cheaper and easier to maintain than a centralized system with its plenitude of wiring. The advantage is generally modest for systems with three or four axes. It pays off big, however, for systems with 8, 12, or more axes, reducing both system complexity and cost.
The distributed approach is used not only for motion control, but for general automation applications. Witness the recent developments of DeviceNet, SDS, ARCNET, Profibus, and other network systems.
There is, however, a two-fold problem with distributed control. First, no one protocol has achieved dominance over the others. Thus, there is a wide variety of networks to choose from. Second, there is no universally accepted standard by which motion nodes can be told what profile to execute.
But there is progress. One protocol, Sercos, has gained acceptance in one class of control problem, namely highly synchronized machine tools such as CNC milling machines. And it is only a matter of time before other protocols become de facto standards for the remaining classes of problems.
Counting the cost of embedded control
It is seldom the case that cost issues are the only factor when considering embedded motion solutions, but for purposes of illustration, it is useful to make a cost analysis to show the breakeven points.
The development cost for a typical embedded card is around $200,000. This includes the price of two or three engineers for about a year. Since the per-unit cost savings is around $2,000, the break-even volume to justify such an effort is 100 units. However, after factoring in time to market, availability of resources, and flexibility considerations, the real break-even point is more likely in the 200-to-1,000 units range.
There are other reasons besides economic constraints to develop a custom card from IC components. One compelling reason is that off-the-shelf controllers often do not have the exact mix of features required. Another reason is that the final product might have to fit into a compact space, and will not allow a PC or bus-based approach. (This article originally appeared in print as Brushing up on motion architectures.)