What OEMs Don't Tell End Users about PACs

Many end users don't really know what PAC is, or what the differences between PLCs and PACs are. The reality is, OEMs and machine designers need to educate users better.

By Don Fitchett, Business Industrial Network

If asked, "Is there really any difference between programmable logic controllers (PLCs) and programmable automation controllers (PACs)," the machine end user will likely answer, "No."

Or that person might ask, "What is a PAC?" You may even get a few that will argue that no difference exists between the PLC and the PAC. Additionally, users may claim the PAC is just a new name and acronym created by the PLC vendor sales department to generate new sales.

The fact is a PAC is very different from a PLC, and it is important for original equipment manufacturers (OEMs) and designers to educate their end users regarding the differences between a PLC and a PAC prior to purchase and again during customer training on any new equipment.

Machine designers should prioritize educating their customers on the difference between a PLC and a PAC. Doing so will create significant benefits for both parties by:

  • Lowering warranty period cost.
  • Increasing customer satisfaction.

Success in achieving these two benefits is multiplied when OEMs write programs that provide the appropriate level of detail for end users who might lack prior knowledge and experience with PACs. Clear and detailed program documentation is often more important when using a PAC to control a machine.

There are some major differences and special considerations an OEM should take when machine control uses a PAC instead of a PLC. An equal analogy that any equipment customer can easily visualize is: A PLC is to a PAC as a digital clock radio is to a computer.

Sure, computers have clocks built into them, but computers are structured differently and, with all the added functionality, are much more complicated than a digital clock radio. The clock/computer and PLC/PAC comparison can be applied to the intended end-user consideration in PLC/PAC design, too.

See More: PLC vs. PAC Comparison

Simplified, PLCs are designed with the electrician in mind, and a PAC is designed with the IT/computer programmer in mind. With PLC designs, simplicity and user-friendliness take priority over functionality. Therefore, the PLC design focuses on ladder logic, which electricians could easily understand from their knowledge of working with electrical diagrams, and the PLC has a very specific control purpose. In contrast, the PAC is designed to handle multiple control purposes, not just a PLC, but also a motion controller, a DCS, four additional high-level programming languages, and more.

The primary purpose of automation control is to improve quality, efficiency and uptime. Over the years, PLCs have evolved to serve these purposes well. Nevertheless, the PAC is still greatly lacking in these three areas in circumstances where plant personnel working with PACs are involved in maintenance or troubleshooting the machine or process. Therefore, it is the responsibility of the OEMs to compensate for the PAC’s shortcomings in these areas.

Table 1 shows a side-by-side comparison of the PLC and PAC. The major differences are easily identifiable. Machine designers would do well to consider their end users, who will have to maintain, operate or otherwise work with equipment controls, specifically related to important differences in device architecture, ease of access and version control.

Regarding architecture, a PLC has a single scan cycle, and a PAC multi-tasks as a computer does. End users no longer have quick and easy access to the organized data tables that PLC software provided, as the PAC uses only created tags. With a PAC, end users now have to be aware of firmware versions, and even access software revision numbers due to lack of backward compatibility and maintaining current functionality.

There are other drawbacks including configuration of a PAC, which is much more difficult than it is for a PLC. PLC configuring cards are plug-and-play with the click of a button. PACs comprise several options that often need to be set manually and firmware versions to look for, creating additional complexity.

Some of the most helpful ways an OEM can help their customers to reduce downtime and reduce demand for additional support include:

  • Recommending training for maintenance specific to PACs and mastery of PLCs before moving on to PACs
  • Using PAC software’s documentation functionality, such as rung comments, to document in great detail
  • Abandoning the use of higher level programming languages, such as structured text, blocks and user-defined instructions, unless it is required to obtain the desire control and then only where it is required
  • Carrying over best practices in PLC programming to the PAC programming (cross-reference subroutine, startup subroutine, all HMI in its own subroutine)
  • Creating a subroutine for key and commonly used processor status data (end users no longer have processor status data files in PACs, as they do in PLCs, for troubleshooting).

Manufacturers and designers of PACs should make their primary objective to be considering the maintenance and operating personnel who will make minor modifications to the PAC, and they simplify those processes during every phase of the PAC program design. Additional consideration should be given to end users facing stark differences between the PLC and the PAC and to assisting in the awareness of disparities in the two systems.

Machine manufacturers should keep in mind during control programming and design that the end users may not be strong in PAC/computer architecture, computer programming knowledge or experience operating them. If they address the end-user needs for the additional level of detail required, they will see less warranty calls and happier customers.

Like this content? Get it delivered straight to your inbox! Click here to sign up for free e-news alerts.


Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • <p>I think it is important to clarify that not everyone needs a PAC. For instance, the image in the example architecture shows and SLC-500 versus Contrologix. The newer Micrologix platform uses the same SLC-500 programming style but includes real time clocks and Ethernet connections. I simplify the selection process down to one thing, do I need motion or don't I. Motion equals PAC.</p>


  • <p>Good advice Rick. That is what we tell our customer while delivering PLC training. Thanks</p>


  • <p>I find that PACs (CompactLogix) are much easier to use and setup versus PLC (PLC-5, SLC-500, and ML). Some of this is due to improvements of the programming software. A CompactLogix processor costs more than a MicroLogix for a small project but if money isn't the primary concern I would pick a CompactLogix every time because of its flexibility and included communications (Ethernet IP) which is very useful when doing integration (external I/O, communications to robots).</p>


  • <p>Long term maintainability by the lowest common denominator skill set should always be a design consideration for control systems on capital equipment.</p> <p>I was questioning the graphic, however, as the PLC's I have used in the past have had every conceivable communication option. I have even used them as protocol converters in some simpler cases.</p>


  • <p>Gary, the chart is generalized comparisons, details may vary slightly among different PLC/PAC manufacturers. Yes you could buy modules or adapters for every conceivable communication need, but typically came default with only one communication option, later evolved to 2 by default. So on the chart, the communication is a weak point, as you pointed out Gary. Also a heads up to Thomas's comment, you can place almost every PLC in ethernet, there has always been communication modules and adapters. Where the PAC shines in respect to ethernet is its architecture is built on ethernet so unlike the PLC where it is converting slow rs232 or rj 485 to ethernet which in turn become a communication bottleneck, the PAC goes straight to ethernet. Which in 90+% of applications, that extra high communication speed is NOT needed. (A high speed machine needing data from another high-speed machine being the exception to the rule.) A better description of the communication difference between a PLC and a PAC than the chart can provide is a PLC is typically converting from a slower protocol to a faster one. A PAC is converting from a faster protocol to a slower one (like ethernet to rj485, so no comm bottleneck).</p> <p>Also Thomas, when you compare PLC to PAC, it needs to be apples to apples. The SLC 500 is equivalent to the Controllogix. And the ease of use and configuration between a SLC 500 and a Controllogix is like night and day. With the SLC 500 you just plug and play I/O click autoconfig, your done. With the controllogix, you have many additional parameters and have to choose manually each. Much more difficult to configure and learn all the additional aspects of a Controllogix (PAC) than it is for a SLC500 (PLC).</p>


  • <p>The Schneider Electric M580 PAC supports both Modbus TCP and Ethernet/IP and does not require any gateways in between to other PLC vendors that support Ethernet/IP. It is programmed by Schneider Electric single programming software Unity Pro and supports IEC based languages. The tag database consists of both located Modbus address and unlocated (native) tags and can be stored on-board the PAC. In addition, M580 has the remote IO Head built-in into the CPU for remote IO architectures providing additional savings in hardware cost. It is truly a great PAC for multiple OEM and process applications.</p>


  • <p>Patrick: Basically the same can be said for most other brands of PACs, like AB/Rockwell's, etc. Most of what you describe for Schneider's is what differentiates any brand of PAC from a PLC. But I will spare everyone here reading this, from viewing the links to all the other brands of PACs. :) </p>


  • <p>I somewhat disagree. I used to teach Programmable Air Controls (PAC) and basically it was sequential and repetitive. For every action, there had to be a reaction. The design was fairly simple: A would happen and when A was completed, the sequence would go to B and so on. </p>


RSS feed for comments on this page | RSS feed for all comments