In the world of automation, PLCs and PACs are often at the center of the action. But where did these machines come from, what are the functional differences between the two, and what applications are they best suited for?
In the 1960s, computers were ruggedized for industrial environments where they were implemented to automate simple processes by controlling inputs and outputs. These digital controllers were quickly replacing large arrays of electro-mechanical relay switches — devices that mechanically open or close a circuit depending on whether or not they are energized with an electrical current — that had been hardwired to perform the same logical function as the new digital controllers. If the end result was the same, why then were manufacturers changing to a different technology?
Utilizing PLCs in Place of Relays
The answer for the switch from relays to these new programmable logic controllers (PLCs) lies in the fact that PLCs were vastly more versatile than their hardwired relay cousins. Because the relays were hardwired, making a simple change to the logic involved laborious tracing and rerouting of wires which was time-consuming and prone to error.
Figure 1. A pre-PLC relay room
The PLC allowed engineers to instead make these changes digitally within the programming of a controller and immediately see a change in output.
Figure 2. The Emerson VersaMax is an example of a typical PLC.
PLCs radically improved efficiency and took up a fraction of the cabinet space compared to relays.
PLCs and Ladder Logic
A typical PLC is programmed in ladder logic. Ladder logic is a visual programming language that graphically mimics the way circuit diagrams were drawn for the hardwiring of relays. Notice the similarity in the symbols below used to indicate normally open and normally closed contacts:
Figure 3. Ladder logic vs. traditional circuit symbols
PLCs tend to be proprietary in nature and therefore can limit the end-user with regard to communication and bus options. Their processors are slow by modern PC standards (yet are fast enough for most typical applications) and have slower clock speeds which allow the PLC to run cool without the need for large heatsinks and dedicated ventilation.
PLC Applications
To this day, the PLC is excellent for standalone, discrete processes. Imagine applications such as elevator controls, car washes, the automatic filling of a reservoir with ratios of ingredients and mixing them in a manufacturing process, or running a conveyor until a specified number of products have been counted by a sensor. Where simple, repeatable processes need to be performed — and can be controlled by simply managing I/O (inputs and outputs) via written logic — you will likely find a PLC.
Transitioning from PLCs to PACs
By the late 1970s and into the 2000s, the PLC was morphing into something much more than just a programmable logic controller. Technology was quickly advancing and the production of PLCs with more advanced features and capabilities was on the rise. A new term was coined for this advanced type of PLC to distinguish them from the simpler variety. These would become known as programmable automation controllers (PACs).
What is a PAC?
There is no hard definition for what a PAC is exactly. However, there are several general criteria a controller should meet to widely be considered a PAC within the automation engineering community.
Figure 4. The PACSystems™ RX3i rack-based controller.
A PAC should be:
- Multi-domain
- Multi-tasking
- Multi-language
- A modular open-architecture design
These points all push the PAC towards being a controller that is universal in nature and centralizes all operations onto a single device platform. Let’s expand on what each of these terms actually mean.
Multi-domain
Multi-domain refers to the PACs capability of performing sequential logic control, process control, and motion control, and exchanging this data between other devices in the field.
PACs require enhanced operating systems that allow them to perform many different types of functions such as PID controls, supervisory control and data acquisition (SCADA) and data logging, or executing high-speed, vision-based, multi-axis motion control operations, as examples. To do this, PACs must have significantly greater memory and processor capabilities than an ordinary PLC. This is a key reason why PLCs are generally insufficient for motion control applications—not only are they too slow for the precision needed in high-speed applications, but, due to their single-domain nature, the resultant motion can vary in time which is a definite limitation.
Multi-tasking
Multiple processor chips within a single CPU module allow the PAC to perform multiple operations simultaneously. This greatly enhances the efficiency and performance of the controller. In this regard, a PAC is more similar to a PC than it is to a PLC.
Additionally, because the PAC is expected to communicate and act on data quickly between multiple devices, a high-bandwidth backplane is an essential feature of PACs to facilitate this data being processed efficiently.
Multi-language
Where PLCs tend to support ladder diagram and structured text programming, a PAC should support all IEC 61131-3 international standard languages:
- Ladder diagrams
- Structured text
- Function block diagrams
- Sequential function charts
- Instruction lists
One language may be easier to use when programming a certain type of operation or more common within a particular area of engineering. Including all IEC 61131-3 languages makes a PAC equally convenient to use for engineers of varying backgrounds who have different goals for their controller.
Modular Open-architecture Design
PACs have a backplane where modules can be freely added or removed, making the controller highly customizable to a particular application. This design also reduces cost when expanding a project since only the necessary modules of the PAC need to be changed, rather than the entire system.
Modules attached to a typical PAC backplane include a power supply, backup battery pack, CPU, analog and digital I/O, comms modules (for communications over standard protocols such as serial or MODBUS/TCP ethernet in addition to any proprietary protocols such as Profinet), and more special-purpose modules such as temperature controllers or power transducers.
PAC Applications
A PAC could be found performing any of the applications a PLC could do. However, you could also find a PAC operating in more advanced applications such as controlling high-speed multi-axis robots in real-time, vision systems, large-scale data logging, and interacting with SCADA systems and HMIs. In fact, a PAC could do all of these things simultaneously.
So Should You Use a PAC or a PLC?
So if a PAC can do everything a PLC can do but better, what’s the point of a PLC? Like everything else, it comes down to cost. PLCs are substantially less expensive. A PLC may cost several hundred dollars, whereas a fully outfitted PAC may cost a few thousand. There are still many applications for which having a standalone controller of the PLC variety is perfectly sufficient, so we certainly will not see PLCs disappear from the market anytime soon. However, as technology improves and continues to offer better performance at a lower cost, it could be expected that the already somewhat fuzzy line between PLC and PAC will continue to blur.
Ultimately, the take away from this is not what defines a PLC and what defines a PAC today—who cares what a marketing team decides to call a piece of hardware at the end of the day? Not all PACs and PLCs are created equally, after all. The important thing is to better understand the range of capabilities of the various controllers on the market so that you recognize what your practical options are as an engineer in the field.
Copyright Statement: The content of this website is intended for personal learning purposes only. If it infringes upon your copyright, please contact us for removal. Email: admin@eleok.com