It can be, as the experience of thousands of users has demonstrated since the technology was developed a decade ago. For this reason, most robot builders offer controller models that can manage two robots, and the number of suppliers offering controllers that can oversee as many as four robots is growing.
Fueling this growth has been a desire among users to do more with less. Controlling multiple manipulators from one interface, one central processing unit (CPU), and one set of communication ports not only eliminates costly redundant hardware, but it also tightens the integration of the robots and the devices supporting them. The one controller and the person operating it know immediately where every device is in space, without an elaborate communications scheme.
The tight integration also can enhance the speed of the operation because processing on one CPU is generally faster than transmitting information over a network (although it can be nearly the same with today’s high-end networks). Consider two welding robots working on an indexed positioning device, such as a servo-driven table. The typical multi-controller hierarchy has Robot A running the table and being master to Robot B. Before the table can index, Robot A must go to its safe position, tell Robot B to do the same, and wait for Robot B to report that it has reached safety. After the table moves, Robot A relays that information to Robot B, and both can then move toward the work. This “handshaking” and movement can take a few seconds.
The sequence is simpler and faster when one controller supervises all three machines. Because the single CPU knows the position of each unit, the robots need not report to an established position and wait there for the table to index. Rather, the robots simply move away from the table and begin moving into position for the next weld, as the table is indexing. The movement can occur simultaneously because the CPU knows where everything is and can check for interference in real time.
Eliminating the safe position can cut cycle time by as much as a second. Although that might not seem to be much, it can add up quickly in production. “When you’re at 53 seconds per component and trying to get it down to 50, every half second is extremely valuable,” says Erik Nieves, senior manager, technology advancement, Motoman Inc. (www.motoman.com), West Carrollton, Ohio.
Despite the advantages, controlling several robots from only one CPU is not always optimal. For example, robots working in different cells need separate controllers to avoid confusion. More than one controller is also best when the number of robots exceeds four. “That is the point of diminishing returns,” explains Nieves. Programming and managing more than that becomes too complex from one point of control.
Putting too many robots on one controller also can slow the process if the tasks are computation-intensive. “When four to six robots are linked closely in this fashion, there is a point where you’ll start degrading the operation because there is only so much CPU power,” says Gary Zywiol, vice president, product development, Fanuc Robotics America Inc. (www.fanucrobotics.com), Rochester Hills, Mich. “The robots will be tightly coupled, but the controller will run out of horsepower.”
Another argument against relying on only one controller has been that the strategy lacks redundancy. Having a controller for each robot and allowing them to talk to one another over a network would at least allow some of the robots to continue work when a problem brings one of them to a halt. Of course, the redundancy helps only when the other robots do not depend on the idle one for helping them with their work.
Redundancy is “a valid argument in theory, but we just didn’t see it helping very often,” notes Motoman’s Nieves. “In fact, reducing the number of boards, pendants, and other components actually drives reliability higher.” Moreover, software that allows separating a disabled robot at a moment’s notice makes the fear irrelevant. So shedding redundant controllers could be worth the savings.
James Koelsch, [email protected], is an Automation World Contributing Editor.