Вы находитесь на странице: 1из 2

PLCs | A PLC by Any Other Name | Control Design

Page 1 of 2

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


03/02/2010

By 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 systemsfor 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

http://www.controldesign.com/articles/2010/PLC1003.html

21/06/2010

PLCs | A PLC by Any Other Name | Control Design

Page 2 of 2

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 lowcost 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.

Contact Us | Advertise | Privacy Policy | Legal Disclaimers, Terms and Conditions


Copyright 2004 - 2010 Control Design All rights reserved
P: 630-467-1300 | 555 West Pierce Rd., Suite 301, Itasca, IL 60143

http://www.controldesign.com/articles/2010/PLC1003.html

21/06/2010