Evaluating the Control Platform Choice

June 11, 2013
Faced with an array of control platform options for discrete manufacturing—including PLCs, PACs and PCs—how can end users decide which technology is most suitable?

When shoppers come across 28-packs of bottled water, few marvel at the number of bottles in them as a feat of engineering prowess. In fact, most give the packs little, if any, thought as they load them into their shopping carts.

But that’s because they don’t know what Terry Davis knows. As CEO of Production Automation Inc. (Montgomery, Ala.), he oversaw the engineering that went into his company’s new line of flexible palletizing machines that assemble individual bottles into packs and cases. Because a new control platform proved critical to the flexibility of the new line, he is among a growing body of users testifying to how control platforms are helping them to design increasingly more sophisticated manufacturing automation.

At Production Automation, specifying a programmable automation controller (PAC) held the key to the development a new line of hybrid robotic gantries that retain the speed of old palletizers, but are gentler and more flexible. Gentleness became an important issue at Production Automation because high-speed collisions against the diverters in the previous generations of machines could break the thinner walls of today’s plastic bottles. Plus, greater flexibility was required to accommodate a growing demand for an increasingly larger variety of pack sizes, beyond the traditional 6, 12 or 24.

>> The Software-Centric Approach to Control: Click here to read how some users choose an architecture that is common to several kinds of controllers and also programmable with the same software.

In traditional designs, the diverters sort and arrange the bottles into specific patterns for packaging. Because each configuration requires a new pattern, technicians must add, remove or rearrange the diverters and other components to change the size of the package. Not only do these changeovers typically require three days of downtime, but the bottler also must maintain an inventory of components worth tens of thousands of dollars.

Although robotic arms can solve these problems because they are flexible and can be gentle at high speeds, they bring with them a number of complications. For example, they are often expensive to install, run and maintain. They also tend to require separate control platforms and even separate communication networks to carry out high-speed motion with precision.

PAC Capabilities
To overcome these limitations, Production Automation worked with Kendall Electric Inc. (www.kendallelectric.com),an electrical distributor based in Portage, Mich., to develop a hybrid palletizer around the ControlLogix PAC from Rockwell Automation Inc. Using EtherNet/IP for communication, the PAC uses what Rockwell Automation refers to as its Integrated Architecture, which it says consolidates communications onto one network to simplify machine design, control and integration.

Perhaps the most fundamental of the enabling technologies has been the continual improvements in chips and their cost-to-performance ratios. “The control platform now has the horsepower to do more in a small package,” explains says Paul Whitney, commercial program manager for Integrated Architecture at Rockwell Automation (www.rockwellautomation.com). Consequently, automation vendors have been able to offer a scaled-down version of their PACs, whose cost had once limited them to automobile assembly lines and other large-scale applications. Repackaged into smaller units, PACs have been finding their way into smaller applications, such as the new palletizers from Production Automation.

In each palletizer, one of these PACs integrates two robots into a dual-headed gantry crane that moves above a conveyor carrying a steady stream of bottle packs. A robotic arm extends from each crane, gently reaching down to grab a case and put it into a predetermined pattern for palletizing. Guards are raised at various points along the conveyor to assist in generating the required patterns. Cases can flow into the machine at variable rates, depending on need. When both cranes are running, the machine can process more than 80 cases per minute.

In the PAC, EtherNet/IP uses time synchronization to deliver the performance and precision that motion control demands. Time reference is distributed across nodes so the network does not have to be scheduled. Network traffic is dramatically reduced because the size and content of data packages can be changed dynamically.

“Our customers can connect the machine through one single channel to other machines, to the entire line and even up into the business level,” notes Production Automation’s Davis. “So, we didn’t need to consider separate network requirements and specifications when designing the motion application. Plus, for my company, replacing a multitier networking strategy with one standard network architecture reduced engineering, commissioning and deployment time, as well as integration risks.”

Because these benefits appeal to end users as well as to machine builders, the trend among automation vendors is to develop platforms that perform functions that used to require separate controllers.

“It seems like the trend is towards a PAC that has motion and I/O capabilities within one package,” observes Dave McFerren, a project manager at Corp.’s Electromechanical Automation Div. Parker Hannifin (www.parkermotion.com/ips), for example, is planning to release a PAC that integrates motion control, I/O and a human-machine interface (HMI) in one package late this summer or early fall.

The result of this trend toward greater consolidation of control functions into one box has been a blurring of traditional distinctions between the different kinds of controls. “In the past, you had motion controllers for motion control, and PLCs [programmable logic controllers] handled I/O,” explains McFerren. “Now, it seems like motion control companies are starting to include I/O and PLC capabilities within their motion controllers. Conversely, PLC manufacturers are adding motion to their PLCs.”

To match the right controller with the job at hand, however, he still recommends that users pay attention to the core competency of the control manufacturer. Because motion control, for example, can be complex, it would be best to turn to a control vendor whose roots are in motion control when that is the overriding concern for the project.

>> On The Horizon: Network-Enabled Control Platforms. Click here for more information.

As controls gain functionality, the difference between a PAC and PLC can be fairly subtle these days. In the end, though, the chief difference lies with the communications, according to Tom Edwards, senior applications engineer at Opto 22 (www.opto22.com).“A PAC starts with a communication device and builds a controller around it, whereas a PLC is a control device with communications ‘taped’ on the back,” he says.

Although he makes this distinction half in jest, he does not see it as an incorrect way to view the situation. “A fairly significant portion of users of our equipment have getting the data out as their primary goal—to know what’s going on minute by minute, or even second by second,” he explains. “PACs really come into their own and justify the higher cost of a controller with communications in systems with perhaps more than 24 I/O points, where getting data is important.” The PAC makes that easy, as well as cost-effective, because it can talk to SQL, Access and other databases.

“In discrete manufacturing,” Edwards continues, “some machines don’t do anything but cut wire to length or bend component leads. The very inexpensive PLCs down in the few hundred dollar range are more than adequate for those jobs.”

The PC-based Option
Although PC technology has proliferated into nearly all industrial control technologies, as it has everywhere else, most vendors still consider PC-based controllers to be a distinct class of control platforms. Like PACs, the PC-based architecture can consolidate several controllers into one. Industrial PCs have the added advantage of being able to run Windows-based applications, such as those for visualization, vision inspection and supervisory control and data acquisition (SCADA), notes Daniel Ghizoni, senior solutions engineer at B&R Automation (www.br-automation.com).

To give their PC-based controllers a deterministic nature and the ability to run a real-time operating system over Windows, B&R has engineered its industrial PCs to run programs in a cyclical fashion. “The underlying operating system schedules and prioritizes the execution of each task, creating a true cyclic and predictable system,” explains Ghizoni. “This allows applications that are more critical to run faster, while others, such as visualization control, can be left to run at slower rates.”

For this reason, the CI Vision business unit of Mettler-Toledo International Inc. has chosen a different path to consolidating controls than companies like Production Automation. Rather than using PACs for its vision-based inspection systems, Mettler-Toledo’s engineers have specified an APC910 PC-based platform from B&R.

The platform replaced a control architecture that had been using three kinds of controllers—a commercial PC, several conventional PLCs, and a stand-alone motion controller—to coordinate the activity of each machine. Because each PLC was able to oversee a maximum of only four inspection stations, the number of PLCs would necessarily increase with the inspection stations required for the application. Every PLC added to the machine meant additional engineering to coordinate the handshaking among the PLCs and the distribution of the collected data.

Wanting to simplify the architecture in a way that reduced the limitations on performance, yet enhanced their flexibility to tailor the systems to the applications, the engineering team looked at other platforms. They found that soft PLCs running Windows were too unstable for vision inspection and that PACs were too big and expensive, according to Stephen Dryer, product manager at Mettler-Toledo. Another disadvantage of using PACs was the incompatibility of code across platforms, which would have made developing new capabilities difficult and expensive.

“We discussed creating a proprietary embedded controller as well, but determined it would be too expensive, slow to develop and difficult to maintain,” recalls Dryer. “It would have been a distraction from our core business.”

Replacing the old complex of controllers with the industrial PC platform from B&R reduced the overall architecture to just one controller running the automation vendor’s real-time operating system over Windows. Not only does the new architecture provide more motion control without the hassle of integrating multiple controllers, but it also can handle as many as 32 inspection stations. “Our controller is no longer a limiting factor in building more complex vision solutions,” reports Dryer.

“We are able to use a more powerful programming language that integrates more easily with our vision software, and using industrial PCs means that the software runs much faster,” he adds. “Code is not platform-specific on the B&R platform, so we are able to port software from controller to controller, giving us the ability to take advantage of hardware improvements as they occur."