The first of these schemes closes servo position, velocity and torque loops in the drives themselves, while the controller still executes motion commands, manages I/O and generates the trajectory profile for the networked drives. “In earlier architectures with analog interface drives, typically all the servo loops, with the exception of the torque loop, were closed in a dedicated motion controller,” notes Bob Hirschinger, principle application engineer for Rockwell Automation.
Another scheme pushes the trajectory path planning down into the drive. “Instead of sending trajectory planner profile information to the drive over the network every millisecond or so, we just send the motion move command data to the drive, and the drive executes the trajectory path planning,” says Hirschinger.
In yet another scheme, the drive executes the high-level motion command logic directly. “Distributed programs execute locally in the drives, and the machine or line controller synchronizes the drives through a network connection,” says Hirschinger.
Besides having the ability to boost performance of the machine, networked drive distribution also has ramifications for maintenance. “If a device fails, you can plug in a replacement device and have the system automatically detect it, flash the drive to the proper revision level, download the drive configuration parameters and any resident local programs, and bring it online without any user interaction,” explains Hirschinger.
Although he reports success with these distribution schemes, other automation vendors frown on them. “Let’s be clear: intelligence—for example, an amplifier—on a motor does not equal decentralized control,” says Matt Lecheler, motion specialist at Beckhoff Automation. “Strategies that require a program to run inside each motor or amplifier are frankly not efficiently using engineering time or money.”
He prefers to base centralized and decentralized architectures on central processing units (CPUs) engineered for the job at hand. “In centralized control, the engineer programs one CPU to control the motion profile for many axes of motion,” he says. “In decentralized control, on the other hand, the engineer programs many ‘islands’ of motion.” Sometimes, the CPU and program are dedicated to just one axis, and other times, they control more than one.
He believes that decentralized motion control is most useful in applications where supervisory-style CPU coordinates a number of semi-autonomous islands. In fact, he sees no other reason to go with a decentralized architecture. “For example, if I have a single machine with 150 axes, then why wouldn’t I used a centralized multicore industrial computer with powerful PC-based software that can control everything in one place?” he asks. Besides running the motion control profiles for all axes, multicore computer can also run simultaneously the PLC code for the general machine logic, the HMI, databases and higher-level communications to the plant network.
>> Read Automation World's complete coverage, "Decentralized Motion, Driven by Intelligence"
