Programmable logic controllers (PLCs) have been a mainstay in industrial automation since the 1960s. Most platforms are more of a computer that can use ladder logic or higher-level programming languages like C/C++ or Python scripting. This is called a programmable automation controller (PAC).
Some generalized comparisons between the PLC and PAC can be categorized under purpose, programming, memory, application and costs. As you might guess, the PAC has more memory and more versatility as far as application and programming languages. PLCs will cost less, but the PAC may be used to source the ladder logic, run the human-machine interface (HMI) and have a small historian for data forwarding. Which platform is the best choice for machine builders? This is probably based on the application and discussions with the customer and what platforms they are using in their operations. However, there are some options.
PACs are more integral in system safety, as well. Some control architectures set up a card in the rack to be dedicated to safety. Others modularize the software, so the safety is separated out modularly via memory on the controller. Simple PLCs would not have this capacity. In this way, PAC technology has allowed us to advance to smart relays and safety PLCs. One manufacturer has created a safety PLC that can be programmed with CoDeSys and meets safety-integrity-level (SIL) and performance-level (PL) requirements as high as SIL3/PLe.
Since CoDeSys can be programmed with C++ there is the capacity to do safety with C++. So, technically this small PLC is a PAC because of C++ capacity and higher memory capacity.
The other highlight of PACs is the increased remote input/output (I/O) capacity. PLCs may be single-racked and have limited I/O capacity, but PACs generally can handle 200 or more remote I/O nodes. This is dependent on which vendor system you choose, but the amount of I/O interface with PACs is higher than with PLCs. Much of this is due to networking, and, if the PAC has layered control, then it will have more network capacity.
PACs could be utilized with instrumentation that is Ethernet-compatible and skip the remote I/O racks. For instance, with IO-Link and a proper Ethernet server, a PAC can become an edge computer utilizing inputs, networking signals and controlling the machine.
As the trend has been and will continue to be, the PLC, PAC, local vs. distributed control system will continue to be a debate and under constant change. Why? Technology is advancing and industrial automation is becoming more open, more modular and more integrable. Advancing the PLC to the PAC is allowing this versatility to grow.
Imagine using a Linux-based system with container software like Docker. Picture breaking out the control inputs, the control processing and then the outputs to the machine, and the overall-equipment-effectiveness (OEE) and enterprise-network type of outputs. PACs will allow this kind of activity. The increased modularity pushes industrial automation forward into Industry 4.0 and more plug-and-play applications. Many controller manufacturers have offered container-type applications on their PACs. Others are following suit with Linux-based real-time control.
No matter the platform, machine builders have expanding options as PACs continue to develop. This is also exciting as far as adaptive automation. PACs allow the integration of AI modules and designs that can adapt dynamically.
About the Author
Tobey Strauch
Arconic Davenport
Tobey Strauch is currently managing brownfield installations for controls upgrades at Arconic Davenport. She has previously worked as principal controls engineer and before getting her bachelor’s in electrical engineering, was a telecommunications network technician. She has 20 plus years in automation and controls. She has commissioned systems, programmed PLCs and robots, and SCADAs, as well as managed maintenance crews. She has a broad mix of mechatronics with process control. She enjoys solving problems with Matlab and Simscape. Contact her at [email protected].
