What OEMs Don't Tell End Users about PACs

Don Fitchett is president of Business Industrial Network, an industrial training company. Learn more about the company and Don's extensive background at www.bin95.com or contact him at [email protected].

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.

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.

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.