Keeping Control

All the power in the world means nothing if you can’t control it. Today, control is performed in motion systems using everything from augmented programmable logic controllers (PLCs) to intelligent drives in conjunction with PCs. Systems can operate with centralized control or control that’s distributed down to the individual nodes. Which approach to take depends on the application and the performance and cost requirements. Let’s take closer look.

Centralized versus distributed control
Control architectures can be roughly classed as centralized or distributed. In a centralized control system, path planning, position loops and velocity loops are handled by a centralized unit, whether that’s a dedicated motion controller or a PLC fitted with a motion card. In such a system, the controller hands down trajectory commands and the drive’s role is to close the current loop and provide commutation commands to the motor to generate the required motion.

In a distributed control architecture, a great deal of the intelligence moves into the drive. The new smart drives feature sophisticated digital signal processors (DSPs) and onboard memory that allows them to generate their own trajectory commands. Indeed, some drives are now powerful enough to perform path planning. With the aid of networking software such as CANopen or Sercos, they can treat other drives in the system as slaves, eliminating the need for dedicated motion controllers entirely.

According to George Procter, vice president of Copley Controls Corp. (Canton, Massachusetts), a motion system essentially performs five fundamental motion tasks: sequencing through a set of moves, e.g., pick up the bottle and put it on the conveyor; planning every point in space through which the robot must move (path planning); and closing the position, velocity and current loops with the motor. The current loop compensates for the physical parameters of the motor, and so does not vary by motion task -- once it is tuned for a given servo motor, it remains steady. The path planning, position loops and velocity loops, however, change in real time with load.

“The difference in centralized control and distributed control is where those three tasks are divided up,” says Procter. “In centralized control, you’ve got the path planner, position loop and velocity loop in the controller. For coordinated distributed control, you have the path planner in the controller, and the position loop and velocity loops in the drive. Then you have this third kind of distributed control for uncoordinated motion where the path planner goes in the drive.”

It comes down to the level of coordination required, he explains. “When the path planning is in the drive, you don’t have tight coordination between axes because each drive has its own path planner. The next level up in coordination is a centralized path planner, which sends position increments to the drives every millisecond, giving good synchronization between drives. The highest level keeps the position and velocity loops in the controller, where it can alter the dependency between axes.”

Of course, the distinctions continue to blur as hybrid architectures pop up. An uncoordinated distributed control architecture with smart drives may still require a PLC, for example, but not one with an additional motion card. “There are different flavors of it, depending on where the task is running,” says Procter. “Many PLC applications are using distributed control, but the actual path planner is embedded in the servo drive. Instead of the PLC telling the servo drive, ‘At this one second you should be here,’ it's saying, ‘You should now move your axis 5 inches at this speed.’ In that kind of architecture, you don't really need a separate processor unit [motion card] in the PLC.”

Performance tradeoffs
So how do you decide which architecture to use? It comes back to performance requirements, cost constraints and operating conditions. Carlos Melo, senior product market manager for motion control at Omron Electronics (Schaumberg, Illinois) points to centralized control as a simpler solution. “It’s much easier to just keep all the advanced programming and advanced functionality in one place and then send the signal or the commands to the nodes,” he says. “The advantage of centralized control is that there is only one [layer of] software, one connection for your troubleshooting and monitoring. With distributed control, you need to look at different entities within the machine, so it’s a little bit more cumbersome to troubleshoot the system.”

To counter this problem, intelligent drives typically provide detailed error codes that simplify maintenance and troubleshooting. Taking full advantage of distributed control does require a bigger skill set from integrators or machine builders, however. “When the path planner is in the drive, it's a very easy transition -- I download to the drive, ‘Move 3 inches at 2000 rpm,’” says Procter. “The harder transition is when you're trying to eliminate the motion control card. Now you’ve got to create this software task on this multitasking operating system on a PC. That requires a much higher level of expertise and not everybody has the guys to do it. These are typically C++ programmers, control people, motion experts.”

Distributed control offers the advantage of modularity -- if a smart drive goes out, even one that controls other drives, it will still only take out a portion of the machine. “There has been a push in the packaging and food and beverage industries for distributed control,” says Melo, though he is careful to add that centralized control remains the dominant player. “When you have a modular system in which you can actually replace one section of the machine with another, [distributed control] makes a lot of sense because there is no centralized control, so if the controller fails, it's only one section of the machine, not all of it.”

The distributed control approach tends to be more economical than the centralized approach. It not only eliminates the need for motion controllers or motion control cards, it minimizes wiring, which reduces design and build costs while eliminating points of failure. Of course, all the cost and efficiency savings in the world don’t help unless you can get the performance you need, which brings us back to the question of which applications work well with distributed control -- and which ones don’t.

The classic example where distributed control breaks down used to be the exercise of drawing a circle. These days, that is easily accomplished. “We can draw circles and do wonderful things having the servo loops in the drive,” says Procter. “For the 90% of the applications we come across, distributed control works just fine and there are clearly some significant advantages in terms of expandability, cost and offloading the processing burden from the main controller.”

The challenge comes when the motion needs to be tightly synchronized. “Most of our customers are using centralized control in their very high end applications where there are tightly coupled loads, such as a robot arm where the movement of one axis changes the parameters on another axis,” says Procter. “It helps to have the servo loops actually in the controller, so as one moves they can adjust the parameters in real time, adjust a different servo loop on another axis, etc.”

Hybrid systems
A prime example of a tightly synchronized application is printing. A typical printing machine may feature as many as 100 axes, all of which have to be closely synchronized to maintain web tension. At the same time, the rollers must also be adjusted so that the various colors of ink are registered to each other. With such high axes counts, even the fastest communications bus introduces too much of a time lag to allow synchronized updates to all nodes, however. So what is the answer, centralized or distributed control? The answer is yes.

“If you’re talking about a printing line, you would probably like to have a master controller that basically could issue these position commands to all the axes in the line,” says Ray Seifert, director of applications engineering at Baumuller Inc.  (Bloomfield, Connecticut). “That means you have one position command set going on and all the slaves just pull that information off the field bus and then synchronize to that master command.”

That approach can handle web tension but the system also needs to maintain print registration. “Ideally, you’d like it to be part and parcel of the centralized control, but because you have these high update times, the field busses have a hard time handling the bandwidth required for every axis to have its own unique position command,” says Seifert. One approach Baumuller takes is a PLC that can act as a master or a slave, and those slaves can even act as masters to other axes. “That’s where you make it into this distributed control where a field bus may only be able to handle four unique axes of position commands, so you might have one of those commands go to another PLC and then split that off into four more just to get the bandwidth.”

Ultimately, the decision of whether to use centralized, distributed, or some sort of hybrid approach comes down to the requirements for the application. Know your performance specifications, know your cost and operations constraints, know your path forward. Once you have gathered that information, you’ll be able to find a control architecture that will best suit your needs.