President & CEO
Performance Motion Devices
In this deep dive we provide a detailed look at design choices for building a machine controller that provides precision motion control. We will answer questions such as whether it is best to build or buy motion control hardware and software, and what aspects of your application are most important for determining the architecture of your machine controller.
Designing a machine controller is all about architectural choices. Where will the amplifiers be located? Should I use a network? Can I build the whole controller on a single card?
The answer to these questions and others depends nearly entirely on five factors:
With an eye towards these five questions, we will survey the major motion control architectures in use today.
You Look Familiar
Architecture 1: Off-The-Shelf Motion Cards
The first major architecture for machine controllers is shown in Figure 1, and will be a familiar form to many. In this architecture, a purchased off-the-shelf motion card connects to external amplifiers, which accept +/- 10V analog signal input and control torque or sometimes velocity of the motor.
Figure 1: Off-the-shelf Multi-Axis Motion Card
The entire machine controller consists of one or more of these dedicated motion cards, motor amplifiers that connect to the motion cards, and a host computer – most often a PC, which holds the user code that controls overall machine behavior and user interface management.
The main choices that you will have to make if you use this approach are the motion card’s connectivity to the host, and the card’s form factor. Popular bus formats today include PCI, PC/104, CANBus, and Ethernet. Some of these formats, such as the PC/104 bus, more or less dictate the mechanical packaging of the card. The serial bus-connected cards such as CANBus and Ethernet are sometimes called ‘standalone’ cards, and come in a variety of shapes and sizes.
Off-the-shelf motion cards have a number of important advantages, primary among them flexibility. The motion controller is independent of the motor power level and often even the motor type. For example, if the motion controller outputs a single phase +/- 10V signal, this can be connected to a DC Servo motor amplifier or a Brushless DC motor amplifier (as long as the amplifier performs commutation). If the user wants to increase the power of the motor, or change the motor type, the motion card doesn't need to be changed, only the amplifier.
The primary disadvantage of this architecture is wiring complexity and cost. For a typical servo motion axis, there are 15-25 wires that connect to and from each motor axis, depending on whether differential signals are used (which is highly recommended), and whether the controller or the amplifier performs commutation. Imagine building a controller for a ten-axis system using this approach. You would need bundles carrying hundreds of wires through the machine. This is a complex, costly, and potentially failure-prone design.
Some other disadvantages are that you have to live with the form factors of the cards you can purchase off the shelf, and that servicing is generally more complicated. Did the motion card have the problem? Was it the amplifiers? Is the problem in the cabling? More parts to the machine controller mean more areas to check out if there is a problem.
Not Your Average Motion Card
With rapid improvements in the power density of switching amplifiers, a variation of the standard off-the-shelf motion card has been gaining popularity.
Illustrated in Figure 2, many motion control cards now come with optional piggyback amplifier cards. For example, a 3-axis motion card might be mounted directly with a 3-axis piggyback amplifier card, rather than interfacing via cable to discrete amplifiers.
Figure 2: Piggyback Amplifier Card
You Interconnect Me
Finally, one further variation of the piggyback amplifier card worth mentioning is a custom interconnect card that includes amplifiers.
Why would you build a custom amplifier card if an off-the-shelf piggyback card is available with amplifiers? The answer is that an off-the-shelf card comes loaded with particular connectors. By building your own interconnect card you gain the ability to install connectors that are optimized for your machine.
Design Scorecard: Off-the-shelf motion cards
Taking It To The Next Level
Architecture 2: Machine Controller Cards
The next type of architecture that we will discuss can be referred to as an integrated machine controller card.
In this approach, shown in Figure 3, a microprocessor holds the machine application code, and generally, a separate motion controller IC, also called a motion processor, generates profiles, does servo loop closure, and manages the time-critical elements of axis control.
Figure 3: Integrated Machine Controller Card
Machine controller cards may directly interface with the user through buttons or a keypad and screen, or may be sub-systems that receive commands from a host via Ethernet or other network connections.
The advantages of this approach are many-fold including easier serviceability since the entire controller card is a simple swap-out, reduced wiring since the amplifiers are on board, application-tailored form factor and connectors, and lower per controller cost.
The main disadvantage is that there is more design work compared to an off-the-shelf motion card. Even here though, you have options to purchase the motion processor to simplify the task of building a machine controller card. This will be discussed in the next section, as will the question of designing your own amplifier and the power levels available from various amplifier approaches.
I See Motion
When designing a machine controller card, you will quickly come upon the question of whether you should purchase a motion processor IC off-the-shelf, or whether you should build a motion control IC from scratch by programming a microprocessor or DSP.
Figure 4 shows a picture of an example IC-based general purpose motion processor IC. These units provide profile generation, servo loop closure, commutation, and a myriad list of time-critical functions such as automatic safety responses, programmable breakpoints, and automatic motion axis management.
Figure 4: IC-based General Purpose Motion Processor
The chipset shown provides 4 axes of control simultaneously, but versions are available from one to four axes. There are a number of vendors of such chip-based products, including Performance Motion Devices (PMD).
These chips saves you the considerable time involved in designing your own profile generator algorithms and writing code for servo compensation filters. Even if you get libraries for those functions from the DSP vendor, you will likely have to tailor them for your own use. And you will still have to deal with putting everything together with the right timing. Servo update routines should calculate and output their values with metronome–like consistency to minimize unwanted harmonics in the motion output.
Another advantage of using something off-the-shelf is that these products come with example schematics for connecting to various encoders and amplifiers, and software packages that help you develop your machine by providing motion oscilloscope functions and automatic setup of axes connections.
So That Would Be Wrong, Right?
So you would be crazy to work directly with a microprocessor or DSP to do the motion control right? Not necessarily. There are plenty of cases where writing everything from scratch, or starting with DSP or microprocessor vendor-provided libraries is a good approach.
For starters, the cost of general purpose microprocessors is usually lower than for dedicated motion processor ICs. So if the volume is high enough, that can become important.
Also, if the motion profiles are fairly simple, and the machine controller that you are building won’t need to be used in a lot of different designs, writing your own motion code may be the way to go.
Show Me The Amperage
When designing your own machine controller card (or designing a custom piggyback amplifier card) you will need to have the right answers for how to provide amplification.
There are three major approaches that you can use. Which one will work best depends on the motor type you are driving and the power level you need. Table 2 provides some useful guidelines for your amplification design choices:
Single-chip IC refers to low cost (~$5-15 per axis) solderable ICs provided by major semiconductor vendors. They generally max out at about 150W. Some of these units can provide current control, some cannot, depending on the motor type.
Solderable module refers to a small (think a deck of cards or smaller) unit that costs in the $50 - $100 range per axis. These handy items come from a variety of motion control vendors including PMD. They provide current control and amplification, and can drive to higher power levels of 350W total output or above.
Discrete design means a switching amplifier circuit with pre-drivers, current sense circuitry, MOSFETs or IGBTs, and additional control and protection circuitry. Cost per axis for the assemblage of parts is from $15 - $35 per axis.
As a general rule of thumb, unless your volumes are very high, or your space and power requirements very exotic, you should buy off-the-shelf components for amplification. So look to use single chip ICs or solderable modules wherever possible.
Design Scorecard: Integrated machine controller cards
Little And/Or Big Black Boxes
Architecture 3: Standalone Motion Controllers
Another architecture for building a machine controller is the standalone motion controller, aka intelligent amplifier, aka indexer. In this approach the motion controller is a 'box', and is generally rack mounted or DIN-rail mounted. These drives are usually but not always single axis, and are fed with a DC bus voltage, or for higher power versions AC from the wall. This architecture is shown in Figure 5.
Figure 5: Standalone Motion Controller
You can think of each of these boxes as an off-the-shelf motion card packaged inside a box. But in reality these products tend to serve specific industries, and have specific interfaces to the outside world. Another difference is that the machine that is constructed tends to be physically spread out.
A classic example of such a ‘machine’ is a factory-scale continuous processing facility such as a bottling facility or candy manufacturer. Materials move down a line and interact with a large number of motion drives that execute small, simple, local function such as ‘push’, ‘pull’, ‘chop’, fill, etc. One or more PLCs or PCs provide overall control but each drive is triggered by local sensors for maximum speed and accuracy as the manufactured item moves past them.
To make this work, each local standalone motion controller has an ‘indexer’ or PLC input connector with I/O control bits. These input bits can control functions such as moving to a pre-programmed location, or executing a specific CAM profile. See my previous Synchronized Motion Deep Dive for more information on cam profiles and synchronization of drives.
Modern variations of standalone motion controllers include the ability to download programs to an on-board memory, so that each drive can execute an autonomous sequence of actions such as, "start the motor at speed x, when signal y goes high then coast to a stop, after that wait for...".
Standalone controllers work well when the behavior of each axis is fairly simple and more or less autonomous. In addition, compared to off-the-shelf cards that use external amplifiers, wiring is simplified. Each unit contains one complete functioning single axis controller, so the wiring used to interconnect a motion card to an amplifier is ‘in the box’ and out of sight.
The central disadvantage, at least historically, is that standalone machine controllers tend to be big, relatively expensive, and use PLC-centered programming languages. For some applications this is exactly what you want, since these units are easy to service and very robust. But if you are building a machine that is the size of, for example, a car or smaller, this architecture may not be the best option.
Design Scorecard: Standalone motion controllers
I’m Good To Go
Architecture 4: Distributed Drives
The final motion architecture that we will discuss uses strings of motion modules known as distributed drives, combining the synchronization ability of multi-axis motion cards with the reduced wiring and increased robustness of standalone motion controllers.
Shown in Figure 6, distributed drives use a network to communicate with a central host, but still have all the standard drive features of profile generation, amplification, and internal AC or DC power management.
Figure 6: Distributed Drive
Depending on the application, two kinds of distributed drives are used. The first can be referred to as a tightly coupled drive, and uses high speed, deterministic networks such as SERCOS, EtherCat, or Ethernet/Powerlink. The second can be referred to as a loosely coupled drive, and uses slower speed networks such as Ethernet, CANBus, and RS-485.
Tightly coupled drives require a motion card or a PC running special software to synchronize and coordinate the motion of each axis. Each drive receives rapid position and/or velocity updates, generally several hundred, or even several thousand times per second.
Loosely coupled drives are also controlled from the host, but utilize more profiling capability in the drive. In this architecture, commands are sent to each drive such as "move the axis to position x using a point-to-point s-curve". Interactions in those drives tend to be more autonomous, using local sensor inputs.
The advantage of distributed drives, whether tightly or loosely coupled, is reduced wiring and increased reliability. Another big advantage is scalability. Adding one more axis to a distributed drive network is a simple matter of plugging in another drive. In multi-axis motion card architectures, adding another axis can require a whole new card purchase when (for example) a fifth axis must be added to a four-axis card.
Is that An Amplifier On Your Motor Or Are You Just…
An important variation of the distributed drive architecture is locating the drive on the motor itself. This approach eliminates all wiring from the drive to the motor, and therefore has an advantage of connection simplicity.
A challenge area for this approach is that the electronics, when mounted on the motor, will have the added heat output of the motor to contend with, along with whatever vibration environment the motor operation introduces. Bear in mind that if the electronics fail, you will end up replacing the entire integrated controller/motor unit, which may or may not be workable for your machine and its access points for servicing.
Cost for these all-in-units can be both a positive and a negative depending on your application. Cost advantages stem from the reduction of wiring and associated construction cost. Cost disadvantages stem from the fact that electronics that can operate in the demanding physical and heat domain of the motor are tricky to design and package.
Design Scorecard: Distributed drives
Can You Repeat That Please?
When is one architectural approach used over another? There is no easy, simple answer, and sometimes two architectures can be used equally well for a given application.
In broad terms, the more cost sensitive the application, the more likely it is that you will design your own card, and if possible, integrate on-board amplifiers. Since you are designing your own card you can choose exactly the connectors you want, and set the form factor of the card for your own application.
Highly synchronized applications such as machine tools will gravitate toward a tightly-coupled distributed drive approach. While not cheap, these drives allow a lot of flexibility in motor type and power range. Don't forget that you will still need a motion control card for overall path generation, or you will use a PC running dedicated g-code software.
A large middle ground of applications such as medical automation, semiconductor automation, scientific instrumentation, and low-power general automation, can be served by several approaches including off-the-shelf motion cards, custom built machine controller cards, and loosely-coupled distributed drives.
To The Laboratory!
This month we struggled to create a video that illustrates different architectural approaches to motion controller designs. What we came up with instead is a simple video that shows the power of connectivity in the modern era!
In the video below, David Marks of our California office runs PMD’s Pro-Motion software, which sends motion commands via the internet to an ION Digital Motor Drive located in PMD’s East Coast US headquarters. Two webcams simultaneously broadcast the action at both ends.