Blurred lines: PLCs and PACs converge

When selecting a PLC or PAC, specify the controller that best fits the applications. The controller specified should be based on controller capabilities and the application requirements, such as machine control, motion control, process control, test and data acquisition, distributed control, enterprise connectivity, or some combination.

By Jeff Payne, AutomationDirect May 25, 2015

Much has been written about PLCs versus PACs, but is there really a difference between these terms, and does it matter? Maybe not, as PLCs continue to evolve and are matching the functionality and capabilities of PACs in many instances.

A PLC-based PAC, to coin a term, can effectively replace a PAC in most applications because there is considerable overlap between the two with respect to features, capabilities, and suitable applications. Although there are many similarities between the PLC-based PAC and the PAC, there are also a few key differences to discuss, but first, let’s look at the evolution of the PLC for some clues regarding how the PLC-based PAC came to fruition.

What’s in a name?

Back in the days of the first PLCs, when they were used to replace hardwired relays and pneumatic timers, PLCs were in fact called programmer controllers, PCs. But then, the PC name was claimed by the personal computer in the early 1980s, and the term PLC became common. The PAC moniker emerged about 15 years ago, perhaps as a way to distinguish the most capable PLCs from their more humble brethren.

The PLC-based PAC is probably a better name for the PACs because these controllers encompass what has emerged over the last few decades in terms of PLCs and other technological advances. Manufacturers have taken proven, rugged PLC hardware designs and incorporated new, low-cost technologies from both the PC and mobile device worlds. They are combining these technology advances to meet the ever changing needs of users and delivering PLC-based PACs (see Figure 1). 

Common capabilities

Today, it’s difficult to find an industrial controller that doesn’t display many of the characteristics that might be found in either a PLC or a PAC. But, the definition of a PAC varies greatly, and many manufacturers are still having difficulty distinguishing between a PAC and a PLC because there are many important, shared characteristics. These shared characteristics and capabilities include:

  • High-speed CPUs that provide fast scan times
  • Tag-name-based capabilities
  • Significant onboard memory
  • Documentation stored on the controller
  • Task Manager program organization
  • Multiple built-in Ethernet protocols
  • Data collection.

Several shared characteristics are more a factor of newer technology than they are a division of class. For example, consider decreased scan times. The latest PLC and PAC processor chips are clocked at a higher frequency than most PCs at the turn of the millennium. This technology advance is available for any class controller. It is more of a preference of the manufacturer when considering the performance and cost of the CPU. These high-speed CPUs are desirable in many machine control applications and in other circumstances requiring very fast execution speeds.

Other shared capabilities are part of a natural progression or evolution of the PLC. Tag-name-based controllers are an example of this. As PLCs were becoming more of an integrated part of a system—as opposed to a stand-alone controller—it made sense to move from a fixed-address design to a tag-name-based system. This allowed multiple platforms within the same control system to share a common tag-name database, often significantly reducing upfront development efforts.

These tag-name-based systems were made possible by lower cost memory. Tag names consume more memory than a typical fixed address PLC, so they require more total memory to accomplish an equivalent application. More memory also opened the door for suppliers to store all program documentation on the controller. This is a tremendous benefit for troubleshooting in the field and eliminates a common problem: losing the tag-name descriptor file when it’s not stored in the controller.

The task manager in some PLCs and in PACs has a common feel as well as common methods to organize the programs. This program organization capability is ideal for larger projects that span multiple machines/processes. 

Common communication

Providing integrated or optionally available communications protocols has always been more of a supplier preference than a function of technology limitations. While there are still some high-end controllers with a single communication port, many low-to-medium range PLCs-even from the late 1990s and early 2000s-have multiple communication ports built in. Many options are also available for additional ports and protocols.

Common Ethernet protocols shared by PLCs and PACs include EtherNet/IP and Modbus TCP/IP. These protocols provide easy connection to a variety of devices and systems, including ERP and business systems. Many PLCs and PACs also provide serial Modbus and ASCII communications. These communication methods are still popular for barcode scanners, message displays, scales, VFDs, temperature controllers, timers/counters, and other devices.

Although there are many similarities between PLCs and PACs, there are some key differences. 

Important differences

There are some key differences between a PLC-based PAC and a PAC, most of which are related to high-end functionality. Some extremely large and complex applications may require a PAC due to the number of instruments, remote equipment, extensive amount of process control and monitoring, and/or other requirements. Generally, the differences are related to hardware configuration, expansion capacity, and cost 

Table 1: Key differences between PACs and PLC-based PACs

Capabilities PLC-based PAC PAC
Maximum I/O 1,000 to 2,000 > 100,000
Footprint Slim form factor Larger form factor
Local expansion capability Medium High
Remote expansion capability Medium High
Programming languages Ladder logic with some speciality blocks Multiple: ladder, structured text, function block, etc.
Programming software cost Free-to-low Medium-to-high
Hardware cost Medium High
Program memory High Very High

Overall application size is often a major dividing characteristic. Many smaller PLCs do have the capability of adding a bus protocol master module to greatly expand the native boundaries of the control system. However, PACs have a much greater capacity for native I/O. This is true for both local expansion using multiple racks and for dedicated remote I/O—both of which can be used to expand I/O counts to 100,000 or more. This can greatly reduce the man-hours required for development and system configuration. Newer PLC-based PACs typically have a slim form factor and in many cases are significantly smaller than PACs, allowing for addition of external I/O.

There are also some crossover characteristics that typically were previously separated into a class of specialty controllers, such as redundancy, ability to program in multiple languages, and certain hardware specifications.

While PLC-based PACs may have only ladder diagram and some specialty function blocks to simplify motion control, most PACs can accommodate all five IEC 61131-3 programming languages:

  1. Ladder diagram
  2. Function block diagram
  3. Instruction list
  4. Structured text
  5. Sequential function chart. 

PLC-based PACs in action

Today’s PLC-based PAC can satisfy a very broad range of applications, ranging from simple machine control to much higher-end PAC applications (see Figure 2). To accomplish this, newer technology is used to provide better controllers at a lower cost, compared to legacy control systems.

Technology advances are enabling suppliers to provide faster controllers with more features in a smaller form factor. This makes the PLC-based PAC suitable for a wide range of machine control applications. Many of these machines require moderately fast scan times for their builders to be competitive and to meet required design specifications.

In the past, machine builders were faced with trying to use smaller PLCs that fit well into the I/O requirements and physical space constraints, but were marginal with regard to performance. The alternative was to switch to a larger PLC or to a PAC. In most cases, the larger controllers were overkill for the simple machine control requirements but were necessary to meet certain application requirements.

Although the PLC-based PAC is a good fit for smaller, cost-critical applications, it can also work in applications requiring hundreds of analog channels. Many of these controllers can log data points to a file on an integrated memory port and then allow access to those files with a standard browser via a built-in Web server.

The typical PLC-based PAC’s large memory capacity makes it ideal for creating 1-D or 2-D arrays to track product, quality attributes, shipping data, and customer information. The tag-name-based attribute of the PLC-based PAC means interfacing with HMI/SCADA, OPC servers, and databases is simplified.

PAC meets high-end challenges

With more specialized areas of integration, a PAC environment can provide unique benefits. Advanced motion control and vision applications are two good examples of applications that often require the power of a PAC. Using a single PAC platform to integrate multi-axis coordinated motion, trigger vision systems, and collect inspection results does have its advantages.

The larger and more expensive PAC platforms are also where manufacturers typically provide options for programmable safety and other specialty functions. These very specific needs may represent a relatively small portion of the market, but they are critical to a certain segment of users.

Selecting a solution

When designing a control system, one should not select a controller based its designation as a PAC, a PLC, or a PLC-based PAC. Instead, the user should identify the controller requirements for his or her particular application and select the best product.

Whether the application is machine control, motion control, process control, test and data acquisition, distributed control, enterprise connectivity, or some combination of these features, the controller specified should be based on the application requirements and the controller capabilities.

This article appears in the Applied Automation supplement for Control Engineering and Plant Engineering

– See other articles from the supplement below.

Jeff Payne is the automation controls group product manager at