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.

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.

Figure 1: Typical PLC-based PACs combine the ruggedness and reliability of PLCs with many of the advanced features of PACs. Courtesy: AutomationDirect.com.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).

IFS

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.
Automation Update