There is a very thin but fine line between PACs and PLCs, but its one that is usually poorly understood by machine end users. And its not their fault; machine builders and system integrators often keep their clients in a constant state of limbo regarding the vital difference between the two entities.

The fact is that a PAC is fundamentally different than a PLC, and even though they perform similar tasks, it is important for OEMs to educate their end-users about the equipment so that its suitability can be rightfully determined. There are two major benefits of doing so:

• Lowered warranty period cost
• Increased customer satisfaction

These two benefits are amplified when OEMs write programs that provide certain level of detail to end users who may not have prior knowledge regarding PACs. Clear documentation also plays a major role in assisting in-house developers make the most out of their documentation.

In the simplest of analogies, a PLC is to a PAC what a digital clock radio is to a computer. One may argue that computers have clocks too, but their inherent structure is much more complex and have added functionalities.

A PLC is designed with an electrician in mind whereas a PAC is designed for an IT/computer programmer. While PLC offers design simplicities and user-friendliness to the electrician, with programming language such as ladder logic, a PAC is designed for greater flexibility and added features. But the benefits of PLC come usually at a higher cost and more structured programming languages.

An automation controller is integrated into a plant to improve its efficiency, uptime and reliability. For decades, PLCs have served this purpose, satisfactorily, but modern upgradations in technologies and communication mediums have fueled the need for advanced control equipment, something fulfilled by PACs.

The following table may help promote greater understanding between the two:

It is quite obvious that a PAC has the upper hand when it comes to features and functionalities. But there are drawbacks too; a PAC has configurations that are more difficult than a PLC. Moreover, end users have to be aware of the firmware versions and take care of issues pertaining to backward compatibility with PACs.

All these issues can be handled pre-emptively if the OEM follows an educational approach towards its products. Some of the tips that can help end-users with understanding PACs in a brighter light are:

• Basic training for PAC maintenance specific activities.
• Extending PAC’s software documentation functionalities, e.g. including long rung comments.
• Use high level programming language only when it is required so as to keep things simple and familiar.
• Incorporating best practices found in PLC programming over to PAC programming, bridging the onboarding gap.
• Since there are no processor status data files in PACs as apposed to PLCs, OEMs should consider creating a subroutine for commonly used processor status data.

You May Also Be Interested In Reading

• Beyond the Presets of PLCs
• How PLCs Can Improve Safety in the Manufacturing Industry
• Low Voltage Control Market Growth