A PLC by Any Other Name

A PAC Is a PLC on Steroids. Anything a PLC Can Do, a PAC Can Do

James IngrahamBy James Ingraham

A PLC implies control of discrete signals. PLCs, however, evolved long ago to handle more than just on/off sequences. Math functions, PID loops and even motion control now are handled by one processor, which has led to the advent of the programmable automation controller (PAC). Having distinct terms separates the classic on/off control of PLCs with the modern all-in-one approach, but fundamentally, a PAC is a PLC on steroids. Anything a PLC can do, a PAC can do.

So, is there a place for the traditional PLC? In a word, yes. Many applications really are just on/off logic. With microprocessors pushing size down, even smart relays can execute ladder logic.

Programming language is another area of distinction between the two controllers. PACs generally can handle any of the IEC 61131-3 languages, namely relay ladder logic, instruction list, structured text, sequential function chart and function block diagram. Some PACs can be programmed in other languages as well, even in 'real' programming languages such as C.

The idea of the PAC is to take advantage of decades of improvement in computing power to give automation professionals multiple tools in one platform.

Another advantage of PACs is their tendency to have more memory than traditional PLCs. This isn't necessarily a limitation of PLCs, just a reality of the market. Coupled with math functions, this can allow PACs to grab data that was once the domain of the HMIs and SCADA systems—for example, keeping a log of a measurement, along with the average, standard deviation and histogram data.

Sophisticated ASCII string manipulation also is useful for preparing messages for the HMI. This opens up new opportunities for measuring performance of systems. Data can be kept at the controller level, giving finer-grain control and more precise measurement. This data can be time-stamped and human-readable, ready to ship up to the HMI as a simple string.

Motion control isn't necessarily an inferior bolt-on. Electronic line shafting, camming and even six-axis kinematics are available on some PACs. Advanced motion control in ladder logic or another language often is easier for end users to support and troubleshoot than traditional stand-alone motion controllers would be. Likewise, auto-tuning, trend graphing or other built-in augmentation to straight PID loops can make life a lot easier in certain instances.

Still, for all of the advantages the PAC has, there are times when it's overkill. This is particularly true at the low end of applications, with a handful of discrete I/O points and control of simple machinery. While PACs are coming down in cost, they still cost thousands of dollars, whereas simple PLCs are in the hundreds. The programming software for low-cost PLCs also is much less costly than programming software for PACs. This difference can be substantial when you consider the cost of enabling every technician to go online to troubleshoot equipment.

The line between what a PAC is and what a PLC is nevertheless remains quite blurry. When exactly is the jump made between a high-end PLC and a low-end PAC? In the end, the distinction is less about naming convention and more about application needs. 'Do I need a PAC or a PLC?' is not the question. 'What functions do I need for this application?' is the proper place to start.

A straightforward conveyor application is probably best-suited to ladder logic and, on the surface, doesn't need more than discrete control. However, even a conveyor system might have barcode scanners, encoders and other sophisticated devices with which traditional PLCs don't necessarily work well. A conveyor system able to make on-the-fly product changes might even need motion control.

In the end, deciding whether to use a PAC, a PLC or some other automation controller hasn't gotten any easier. There are just more options. Look at the application, see what's required, and get the best fit. Increasingly, devices marketed as PACs are the obvious choice.

James Ingraham is software development team leader at Sage Automation (www.sagerobot.com), builder of robot systems in Beaumont, Texas.