PACs versus PLCs

The consensus among both users and automation suppliers is that use of PACs is on the rise, driven by the move to multidisciplinary control. But the PLC is still finding application in systems design by adding advanced features and capitalizing on its roots as a low-cost controller.

"Five years ago, the line was more distinctive, but today PLC makers are adding more and more functionality to their hardware to make PACs and PLCs more similar than different," says Ben Orchard, an application engineer with Opto 22.

He says a good example of this functionality that once separated PACs from PLCs is communications. When PACs arrived on the scene over the course of the last decade, they utilized standard network interface protocols like TCP/IP, OPC and SMTP to achieve a high degree of enterprise connectivity. This included, for example, the ability to communicate data across a networked plant floor control system and even up to enterprise applications and databases residing on the corporate network.

"Despite the fact that some PLCs now incorporate this level of communications technology, some distinctions between PACs and PLCs persist. For example, PACs continue to be better multidisciplinary devices and more naturally suited for a wider variety of uses, including process control, sequential logic, string handling and data acquisition," Orchard says.

"The main distinction is the PAC's ability to easily integrate traditional PLC logic and I/O control with higher performance features of purpose-built motion controllers, along with data management and networking capabilities of PC-based control systems," says Paul Ruland, automation systems marketing manager for Siemens Industry Inc.

Controller CPUs with more built-in communication ports for both Ethernet and fieldbus connectivity can reduce the system cost by eliminating separate communication add-on modules. Additionally, upgrading to a controller that includes a built-in Web server for Internet connectivity saves on an additional PC in the system as a Web server.

"The trend we are noticing is more of an emphasis on advanced software programming packages for controllers that offer reduced engineering costs, along with easier machine connectivity for automation networks, enterprise reporting and remote troubleshooting," says Ruland. "The programmable controller can no longer be a silent black box."

He says Siemens is seeing greater demand for advanced programming software capabilities from the OEM market that are scalable for a full range of controllers, regardless if they are categorized as a PLC or a PAC. Machine builders are always looking for ways to improve efficiencies in their software development tasks.

The demands automation suppliers typically see in the market include unified engineering tools to develop system-wide automation software projects with one user program, and one engineering software tool for machine logic, motion control, safety, process control, HMI screens and network management. These tools enable automation engineers to spend less time on repetitive software coding and focus more on improving their machine design. It also preserves the intellectual property that keeps them competitive.

End-users and Designers Speak Out

On the LinkedIn "Automation & Control Engineering" group, a discussion among PLC and PAC users and systems designers focused on selection of appropriate controllers for specific applications and concerns about technology obsolescence.

Joseph Stevenson, president of ICA Engineering, writes that he thinks PAC is merely a marketing term for the more capable PLCs. He adds that the selection of one platform or another is highly contingent on the size of the process (I/O count, required scalability) and what the control system needs to do with that process.

"In a manufacturing setting, compatibility with the rest of the facility is a key feature," says Mark B. Strube, PE. "I personally think that PACs are the next logical step to keep systems up to date and allow you to take advantage of the latest control technology."

Paul Sinclair, electrical general foreman at PotashCorp., writes that his preference is to go 100 percent PAC if possible, but that small amounts of I/O can be handled effectively by lower-end controllers. He says he likes to keep logic continuity and structure, one programming language and one logic style such as Ladder since the average electrician understands it. He also looks at market penetration in selection of the controller of choice. "Cheap is nice but a euro ~here today, gone tomorrow' is not nice."

"I have been using the Rockwell PACs for a number of years now, and have not found an application where a traditional PLC would do a better job," writes David Kaylor, controls engineer at Red Gold LLC. He says that machine OEMs have been a little slow adopting the newer technology and, as a former OEM and integrator, thinks they are missing out on some advantages in ease of reuse. Along with specifying the Logix5000 platform, he has had to convert OEM SLC programs in order to get the desired platform. But hopefully this will change in the future, since it is still valuable to have a common platform wherever possible.

"Many automation suppliers offer both PLC and PAC controllers because there are distinct differences between the two, but the application will dictate whether a PLC or a PAC is best suited," writes Sloan Zupan, product manager, controllers and HMIs, for Mitsubishi Electric America.

He says a PAC really refers to automation platforms that typically combine multiple different control disciplines onto a single rack. As an example, Mitsubishi Electric offers a product called the iQ Platform, which enables users to select any combination of the following CPU types: sequence, motion, robot, CNC and C controller. The CPUs can be mixed and matched to fit the requirements of any application. By leveraging the same power supplies, racks, I/O and communication interfaces startup, normal operation and maintenance becomes much easier. That is the value of a true PAC, according to Zupan.

Needs-Based Determination

Despite the clear advantages to PACs, many systems designers find that a PLC is appropriate for stand-alone applications where sequence and positioning control are all that is needed. PLCs are flexible in their networking capabilities and the same software can be used for both the PLC and the PAC because the instruction sets are the same.

"A PAC is a controller that looks similar to a traditional PLC system, but has features and capabilities that are typically associated with a PC-based control system," says Jeff Payne, product manager for PLC, I/O and PC Control at AutomationDirect. "These features include integration with corporate databases, tag based addressing, more memory, faster processors and more built-in communications options."

Payne says that PLCs are still being utilized in the majority of the control applications at AutomationDirect. But there is an increasing demand for OEM customers to collect and obtain more data from the plant floor into the enterprise environment for analysis. The built-in capabilities of the PAC allows for a seamless method of data collection without the need for additional hardware or third-party software.

"For those needing more data exchange such as transferring data between the PAC and a corporate database, the PAC makes this much easier," says Payne. "Many times, the PAC will have preconfigured instructions that allow you to interface with a third-party server that handles the SQL, Microsoft Access or an ODBC-compliant database."

According to Fabio Malaspina, marketing manager, component design software, architecture & software - control & visualization business for Rockwell Automation, buying behaviors indicate that some customers purchase integrated system solutions while others buy individual automation components. Customers buying integrated system solutions prefer PACs. But some OEMs such as those producing simple, low-cost, stand-alone machines, prefer to buy individual automation components because they are simple to use, reliable and, most importantly, cost effective.

There is also agreement that the PACs' use of standard networking interfaces and protocols, their powerful control features, extensive communications capabilities and compact size are increasingly making an impression on OEMs. Machine builders tend to find PACs easy to embed and use not only for control, but for other purposes as well such as gathering machine or system data and monitoring the health, status and performance of the machines they build and deliver.

On the flipside, what many OEMs require is a small-sized, basic controller that they can embed in a machine to perform simple control functions. The price points on these devices can get quite low, so the OEM customer sometimes opts for this in place of a more powerful and versatile PAC. What the OEM market is often looking for is compactness, easy configuration and low cost. Often the functionality required is very limited and doesn't vary much from installation to installation.

Scott Tenorio, marketing manager, controller & visualization business for Rockwell Automation, says that the term "PAC" is often used to denote an evolution of the term PLC. He says a PAC is more than just the controller, but rather is a complete system architecture that encompasses controllers, networks and software all designed to communicate seamlessly. As a result, PACs provide a single multi-disciplined control platform for applications that span an entire plant floor.

Weighing PAC Benefits

A key benefit of the PAC platform is it provides a single common development environment. This common development environment allows the integration of varying applications that previously used multiple hardware and software packages.

"PLCs primarily provide machine control logic capabilities using a fairly standard instruction set, such as what is defined by IEC 61131," says John Dart, program manager, global OEM solutions business for Rockwell Automation.

PACs have advanced capabilities, such as the ability to integrate the programming of motion, robotics, safety, process and drives into one common programming environment. This eliminates the need to have several disparate controllers and separate interfaces between them. For applications having multiple control disciplines, a PAC can provide a lower-cost architecture than a PLC and also reduce complexity, improve performance and lower support costs.

Both PLCs and PACs are relevant in today's markets and will be for the foreseeable future. The choice is typically driven by market conditions and each machine builder's business model. Designers of lower performance, high-volume machine types will lean toward PLCs, while higher-performance, lower-volume machine types will lean toward PACs.

"There is demand, especially in emerging economies, for PLCs that have "just enough" PAC-type features to enable mid-range performance at near the cost of low-end solutions," Dart says. "This demand is a significant trend and could actually be considered an enabler to PAC adoption rather than a constraint. As machine builders come to understand the benefits of some PAC features that are included in a low-cost PLC, the tendency could be to move more toward PACs."