PLC, PAC or PC? How to know why to choose what

June 20, 2022
A healthy array of controller options turns excuses into smart choices

W5 is a Canadian news program that gets involved in issues that surround politics, climate and anything else that could be considered controversial.

W5 stands for, well, you know. One of the Ws is for why. A three-year-old’s vocabulary consists only of “why.”

But a more appropriate question of choice: Why would someone use a PLC vs. a PAC vs. PC-based control or all-in-one type controller?

Also read: How to decide between a PLC and a PAC

This is a Pandora’s box of attitudes and opinions.

I have always advocated for the best-in-class, best-in-application devices for the job at hand. You could use a crescent wrench for a plumbing job or a set of channel locks, but you risk damaging the hardware using channel locks because it might slip. It’s all about the pressure.

Certain standard thought processes are engaged when trying to choose the right approach to a control solution.

To me, it all starts at the interface to the user. Do you need/want a graphic interface to guide the user through the control strategy? Is the application a black-box solution?

Once the control strategy is defined, then the going gets going.

There are many components that contribute to the selection of hardware and software for the control strategy—number of I/O, communication issues, instruction set, digital vs. analog, distributed I/O, motion, power source and, perhaps the most important selection decision, programming software. Using a familiar platform is always the best option.

I remember when servo and stepper motion control was introduced with a standard PLC. The advent of motion into a PLC system was a boon for machine-control developers and builders. No longer did you have to have separate and isolate drive systems that had to be integrated through I/O for control and move profiles.

However, this solution was an add-on. Thus, the integration of the software had to be shoehorned into an existing system; it wasn’t part of the design of the platform.

The same goes for closed-loop control or PID. I remember a PID ladder-logic solution that was written for an Allen-Bradley PLC. Effective yes, but not so easy for floor electricians to interface with.

Then came an actual PID I/O module, which used an array of variables that required the use of an actual keyboard used with the programming terminal. For controls engineers, it wasn’t the easiest to navigate.

Programming software is a very important part of any control solution because it can make your strategy successful or unsuccessful. Integration of functions, such as motion and PID, for instance, is paramount if your application demands it.

If, however, your application doesn’t demand it, then it is not a box that gets checked.

The array of available controllers run the gamut of available functions and creative solutions. One controller has a built-in HMI and can be upgraded to another supplier’s interface software to create a PLC/PAC plus HMI in one package. This is a trend among many vendors.

Another supplier uses a PC-based system with built-in HMI, as well. It is classified as PC-based control, as well as an all-in-one. But I’m not sure that matters.

The right device for the job

A PLC/PAC argument always surfaces when discussing these two similar but different platforms. Unlike a PLC of yesteryear, a PAC has been designed with all things, as known at the time, integrated. Motion control is a big addition to the system, where it is integrated in both hardware and software.

The PAC typically has memory to spare, and it typically supports some part of IEC-61131 programming strategy. PLCs as such would be more likely to have a ladder-logic integrated development environment (IDE) with some add-on language editors.

One really big advantage of a PAC, which still could be available in a PC-based control solution, is the ability to have program documentation embedded on the controller. So often, I am called to a site for various reasons and interface with a program that has no documentation files as such.

Typically I/O causes problems, so I have to revert to old-school methods, by tracing through the software using the drawings available, hoping they are there.

We have so many options available to us in 2022. It’s so much easier to find the right platform for the right application. We have no excuse to not apply the correct approach to solve the control strategy.

The why can be answered easily. The only issue is that hopefully the vendor we are most familiar with can supply you with the best solution available.

Now what? Oh, boy.

About the Author

Jeremy Pollard | CET

Jeremy Pollard, CET, has been writing about technology and software issues for many years. Pollard has been involved in control system programming and training for more than 25 years.