Distributed vs. Centralized Motion Control Systems:

A Round-Table Discussion

—by Richard Mandel

Dr. Jacob Tal Galil Motion Control	George Procter Copley Controls	Bob Parente Intelligent Motion Systems	Robert Bigler Animatics
Ryan Lin Lin Engineering	George Ellis Danaher Motion	Perry Marshall Author,  Industrial Ethernet  Pocket Guide	Larry Sifers Oriental Motors

The original intent with this roundtable was to demonstrate that there were distinct choices to be made in system configuration. To address the differences, we assembled a panel of manufacturers and experts: Dr. Jacob Tal, Galil Motion Control; George Procter, Copley Controls; Bob Parente, Intelligent Motion Systems; Robert Bigler, Animatics; Ryan Lin, Lin Engineering; George Ellis, Danaher Motion, and author of Control System Design Guide (Academic Press); Perry Marshall, author, Industrial Ethernet Pocket Guide (ISA); and Larry Sifers, Oriental Motor. After nearly 60 minutes, we found that exceptions and shades-of-gray existed, not just in systems, but in the definitions themselves…

Tal: For years, we’ve been struggling with the concept of how to structure the systems. Historically, central control has always been effective for various reasons. I would define central control as one piece of electronics controlling all the motors in the system. We know that the number of axes in industrial systems typically varies from one up to eight, with central control closing the position loops. Central control addresses this in 99% of the cases.

All along, there’s been an effort to distribute things, with a set of electronics controlling each motor, placing the electronics immediately adjacent to the motor. By doing so, the wire lengths are reduced to a minimum.

Those are the two extremes. For the sake of completeness, let me add one more “middle of the road” choice, one that we at Galil call “flexible distribution.” You create “islands” of control. For example, an eight axes system may be broken into islands of, say, 3, 3 and 2 axes. This way, you get most of the benefits of the distributed system, while keeping the tightly coordinated axes under one central control. This allows different degrees of distribution.

Procter: That’s a very good assessment of the situation. Another item to consider is software. One of the driving forces behind distributed control is to simplify software. You can have one supervisory CPU with one piece of software on one piece of hardware controlling the entire machine. This is possible because the drive is closing all loops, removing the computational burden from the supervisory processor. When you have islands, you have different programs running on different pieces of hardware. These programs have to be able to communicate to be coordinated.

Parente: That’s similar to the IMS MDrive, where the program can reside in it. The times that it gets into a distributed system, is when the central piece is communicating and executing simple commands with it over a bus of RS485.

DFX: Is it, then, a factor of communications, of Ethernet, Fieldbus and RS485 lines? Let’s discuss pros and cons in the complexities of the systems.

Parente: The 485 was IMS’s first simple line that could go distances of hundreds of feet, in the sense that it was a differential system, as opposed to RS232. What’s coming is CAN and CANOpen, for added complexity. 

The benefits of 485 are that it’s simple. It’s a multi-drop, so you can’t have unit #1 talking to unit #2, since the transmits are all connected together and the receives are connected together. It’s important that the central piece of equipment — CPU or PLC — is listening to everybody and keeping everyone coordinated. You can’t have two units talking at the same time — you ask information from axis #6 and it comes back with a response, then you can go to axis #7. You’re limited with what you can do, but there are applications where this configuration works extremely well and this is cost-effective.

Bigler: We have a similar product to that of IMS, where the control intelligence is at the motor. Even with that product, our customers are still choosing between centralized or distributed control functions. This view contrasts with Jacob’s definition of centralized, of a single piece of electronics at a central location. Perhaps we can expand the definition — regardless where the electronics are, where is the actual control? Which electronics are performing the control? In the IMS and Animatics products, it’s just software running in a $10 processor. Even when the user has the option of keeping all the control in a centralized PLC or PC, or maybe in one of the motors and having it command all the others, or all the motors reacting to their own individual I/O directly and locally — there are a lot of advantages and headaches. This configuration does reduce the amount of cabling, as well as localizing the power electronics and interface to the differential encoders and Hall sensor signals to the motor itself. The price of copper wire is not going down.

I think it would be interesting to look at this topic in the scope of time, because what is true of localized, distributed control today is changing. As communication interfaces get faster, approaching virtually infinite communication rate, and the cost of implementing them gets lower and lower, it’s going to completely change the landscape and the trade-offs.

Lin: Going forward from Robert’s comment, we can learn from the examples of the PC industry, where the desktop units had a lot of power and expandability, while the laptop industry had limited power and expandability. With miniaturization, many of the desktop features were translated to the laptop. Even today, we don’t have a completely separated configuration network in the PC industry, where you have a centralized network server that manages certain components and you have your own individualized islands (as Jacob mentioned) to perform site-specific tasks. That analogy would best describe the difference between distributed versus centralized control systems.

Bigler: An excellent analogy. You can go back further to when mainframe computers gave way to desktop computers…

Tal: Let me go back to what Robert said about PC central control. This point we need to discuss thoroughly, because it’s essential to the whole discussion. If we assume that the PC is the central control, then there is no distributed system — all controls are central. That situation is not the reality. I think we need to tighten the definition and say central control is where one piece of electronics closes the position of the motors. In distributed systems, the closed loop is accomplished by having separate pieces of electronics next to the motor, with coordination done by the host computer. The discussion of the pros and cons of the different methods will depend on where the loop is being closed, where the profile is being generated, and the communications associated with that.

Bigler: I’ll take a step back and say, are we talking about centralized versus distributed control, or motion control?

Ellis: We look at distributed control across three layers. There are distributed programs, where separate programs reside in different parts of the machine, like Jacob’s islands. Then there’s distributed intelligence, which has a central controller but the drives take on a great deal of intelligence for tasks like trajectory planning, as in many Fieldbus applications like CANOpen, ProfiBUS and Ethernet. Thirdly there are distributed servo loops, where the central control is doing all the planning, but enough intelligence remains in the drives to handle the loops. The latter is only for servo systems, and Sercos is the only example of it that I’m aware of.

Procter: A correction on that — CANOpen is like Sercos, in that it operates like a slave, in that it accepts trajectories from an external CPU.

Ellis: That’s true. We have products that offer CANOpen both ways. Most of the applications with CANOpen use it like a DeviceNet or ProfiBUS.

Tal: So from this discussion, we can define Central Control in different ways. In a way, every system is centrally controlled, but let us look at the levels. For example, where is the closed loop done? Is it in the central control, or in a piece next to the motor? Secondly, where is the trajectory generated? In a PC, or in a separate piece of hardware? For the sake of this discussion, I suggest that as long as the closed loop is being done in a separate piece of hardware next to the motor, it is a distributed system. “Central” would be when you have one motion controller that closes the loop of all the motors and coordinates and generates the profile for all of them.

DFX: This kind of complexity is similar to choosing between different communication bus systems.

Marshall: My point of view comes as someone selling Fieldbus systems before it was fashionable — we would say to the customer, “What is the benefit we’re trying to achieve? Is it the modularity, or the saving of copper wire? Or is it the diagnostic capability?” Adding a network blurs all the lines — in the discreet side of the world, it has become popular to have PLCs at local locations, where once there was just I/O. The PLCs are connected together with Ethernet, which is then tied to a supervisory controller. The intelligence is spread around — the question seems to be, “How much intelligence do I want outside of a central location?” A lot of the decision is based on economic reasons, where a PLC can be bought for the same price as a piece of I/O.

DFX: Where does the rest of the group stand, as far as the definitions that Jacob just gave us?

Procter: I agree with Jacob’s definition. There are overlaps — you take a typical machine, with three axes of coordinated motion, and you want some central path planner for that. Then you have a bulk loader of wafers, which can be a simple indexer, where the central controller tells it, “Move three inches up and down.”

Parente: I like the definition asking, “Where is the profile being generated?” If it’s coming centrally, it’s central. If it’s local, like in the MDrive, then it’s distributed.

DFX: So generally, what determines one system over another?

Procter: Generally, money. [all laugh] We’ve done some analysis…if you could eliminate the motion controller, and have the main supervisory CPU handle the trajectory generation, then you save 40-50% on hardware costs. With centralized control, you need breakout boxes and high-density cables. When going from four to five axes, you need another four-axis breakout box. Or with expandability — if you need to add a couple of axes, with centralized control you may need to add another controller, whereas with distributed control you just add two more drives.

Tal: To address “What would you look for” with a choice of architectures, maybe the best step would be to list the pros and cons, and then the answer would be obvious…

Historically, the main motivation for distributing control was simplification of wiring — not just the cost of the wiring, but the time and work involved in installation and debugging. The biggest problem that prevented us from using distributed systems 20 years ago was, there was no good solution for coordinating systems…The plus of distributed systems lies in wiring and noise [reduction]. A fully distributed system, with one controller for each axis, would have the minimum wiring and minimum noise coupling. The central control, with all the wires going back to same piece of hardware, would be the opposite — a maximum of wiring and noise coupling. Whereas, the flexible distribution system would be somewhere in the middle, because putting the controller near three motors reduces wiring, but not as much as in the distributed system. The biggest disadvantage of a distributed system lies in the question, “Who is responsible for the coordination?” If it’s fully distributed, coordination is the task of the host. If we say, “How much work has to be done by the user to coordinate the systems, and how large is the amount of data that has to be sent, refined and perfectly synchronized?” then a centralized control is best, for its central command and central program. Distributed would be the least suitable, and flexible would be somewhere in the middle.

Another issue is, how does the system deal with emergencies? If, for example, you have three axes and one failed, the central controller would have all the data in one location, giving it an advantage. In a distributed system, the information has to travel through the other axes. Again, flexible would be in the middle.

In so far as cost, we address two parts. First, cost per axis. Central would be the cheapest, with one card controlling up to eight axes. With a fully distributed system, it’s one card per motor. If you examine a system with combined controller and amplifier, the flexible distribution system is least expensive because of the combined groups of three amplifier/controllers and two pieces of hardware.

Ellis: Jacob, where in your structure does the Fieldbus drive fit in? We have customers using PLCs and can speak to our drives on the Fieldbus for free, such as CANOpen systems.

Tal: Once PLCs enter the picture, things start to blur…are we talking strictly motion, or are we talking intelligence? Let’s address these two points. Fieldbus is a fully distributed system — it just happens that Fieldbus doesn’t cost a whole lot.

Procter: I used to work with a company that had PLCs with motion controllers embedded in them. Taking away a motion controller in the PLC rack, and the associated wiring, and just having a Fieldbus connection to an intelligent drive, was less expensive — plus, it simplified the software.

Ellis: We found the same. The only limiting factor is if there’s many axes of tightly coordinated motion in the application, here we have a difficult time getting the Fieldbus to work. Otherwise, it’s the cheapest solution for distributing intelligence.

Parente: If it’s coordinated motion, like laser cutting or laying down glue, I think it should be a centralized piece controlling all the axes. If it’s point-to-point, you can go distributed, because the cost issues are very competitive.

Sifers: One aspect we’ve seen is the ability to upgrade the machine in the future. Many times, the user has designed their own host controller, and they want to run one software rev in the machine. Distributed intelligence allows for that choice by making all motion commands reside in the host controller. Motion profiles are then sent to the distributed motion controllers via a communication network such as RS232.

Tal: It’s rare to find all eight axes tightly controlled in an 8-axis machine. More often there are two doing circle, with a third controlling a stepper going up and down. It may be better, then, to break six axes into three and three, and run a partial distributed system.

DFX: So besides cost, the decision of a system rests on the complexity of the end result one is seeking. One of the aspects touched on is “safety factor” — can we expand on that?

Tal: It requires the highest degree of coupling between the critical axes. If it’s done within the same processor, it’s faster. 

Bigler: Safety has to be hardwired into the drive electronics. Typically, even in a distributed system, each system member has an input hardwired into the drive electronics for cutoff.

Tal: You may have a situation where the host is stuck with a certain task, and may not be available to receive all messages at all times.

Bigler: Sometimes it’s not stopping you want to do, it’s recovering without damage to the part being worked on. OK, I make my money selling distributed controls, but I can see an argument for centralized controls creating more safety for the part being produced. Distributed systems are easy to shut down in a millisecond, but they’re a little trickier to establish recovery and try to save the part.

DFX: Is there an application that is most obviously better suited to Centralized control, as opposed to distributed?

Bigler: I think so. The more exotic the motions — high bandwidth, multi-axis trajectory generation and high bandwidth PID — that situation will be the stronghold for centralized systems. But, if you’re just cutting an aluminum part to within three-thousandths accuracy, we can do that with three integrated motors and an RS232 interface, at 50 inches per minute.

Tal: Any place where you have master-slave relationships — for example, if you have one axis precisely following another one, in stitching machines or canning operations — for the foreseeable future, they always will be centrally controlled. If error has to be a fraction of a millisecond, it should be central control. If higher, then it should be distributed control.

Procter: I can understand why customers have difficulty deciding between centralized and distributed control. The answer to which is the best solution is often application dependent, although there are gray areas. For complex coordinated motion with advanced robotic algorithms and some electronic lineshafting applications, centralized control may deliver the best results. For mainstream applications, distributed control is the way to go.