I don’t want to belabor the difference between PLCs and PACs. OK, maybe I do.
Why did the industry feel it had to rename a functional device that has been around forever to a name that is supposed to change the functionality of the device in question? I have wondered about this, and it has kept me up at night—well, almost!
I am most familiar with Rockwell Automation platforms, so I will use them as examples. I used to work for Rockwell when it was Allen-Bradley and started in the PLC world at the genesis. Yep, I’m that old.
A PLC in the 1980s was a device that had a universal I/O system with remote I/O, as well as local I/O. The platforms, of which there were many, mainly consisted of the PLC-2/3/5, as well as the new SLC 500/MicroLogix lineup.
While it is true that the industry was moving toward a more open I/O structure using industrial Ethernet and various bus systems, it was also moving toward smaller CPU form factors with much more computational and control power.
However, they were still PLCs.
One of the largest debates that raged onward was the application of a PLC to a process system. PLCs had analog connectivity, as well as the ability to be accessed by HMI/SCADA systems using various communication methods. Distributed control systems, which were expensive and sometimes clumsy, were being upstaged by the PLC because they could have all the necessary capabilities to perform the actions needed.
[javascriptSnippet ]
Fast forward to the 2000s. Enter the programmable automation controller (PAC). What does this new device bring to the table?
[pullquote]In my opinion, not all that much in its infancy. The ControlLogix platform, which was introduced in the late 1990s, created a brand-new approach to the control functions of any application. It wasn’t cheap, nor was it easy to configure at first. But what it did was introduce the concept of electronic data sheets (EDS files) for integrating third-party devices into the system.
Trying to connect a Keyence color camera to an SLC 500 would be a chore. With the Control/CompactLogix [CCL] platform and EDS files the integration is very easy. Score one for the PAC.
The other main issue a PLC had was the inability to have multiple communication methods. The PLC-5 Ethernet versions supported Ethernet/IP and Data Hiway+ and serial communications. The PLC-3, the predecessor to the Control/CompactLogix platform, had a similar form factor as the CCL with the ability to have multiple processor and scanner cards, but the communications options were very limited. Due to the movement of technology, the development cycle for the PLC-3 stopped since the CCL platform was the platform of choice.
The CCL platform introduced the concept of a processor bus and an I/O bus. Multiple communication cards could be used, as well as having built-in communication systems. By this point it was really all Ethernet and all protocols that ran on Ethernet. DeviceNET and ControlNET took a back seat.
Most devices were Ethernet/IP-compliant, so third-party I/O systems, such as those from Murr, could be used. Third-party devices exploded due to the use of the EDS system. Autoconfiguration of external devices made the transitions easy. Score two for the PAC.
The Industrial Internet of Things (IIoT) with MQTT protocol is not available with a standard PLC as such. The PLC-5 cannot be used with that protocol unless there is a separate module created by a third-party to fit into the I/O system. That’s not going to happen over the brick wall that comes up when you try and join legacy into modern day and are met with a you-have-to-upgrade-your-PLC moment.
So, what are you going to upgrade to? Another PLC? The answer is yes. But it is also a PAC. When you replace a SLC-500 or PLC-5 with a CCL product, you are not redesigning the application, so you are replacing it with a PLC.
However, if you are adding new functionality and/or different I/O configuration and communications issues such as IIoT, then it migrates to a PAC.
When the PAC was first introduced the industry veterans needed a moniker to differentiate standard control from advanced control. Motion for instance is a breeze with the CCL. Programming is IEC-61131 based, which the global market was screaming for because it includes function block for DCS applications.
Score three for the PAC.
So what’s in a name? Seems that it really doesn’t matter what we call something; it is about what is does. Whether you call it a PLC or a PAC is immaterial. They both mean control at the highest level with programming software that would make the engineers from the 1970s and 1980s froth at the mouth.
Today’s functionality buries that of the availability of functionality from devices of yesteryear. It deserves a different name. Kudos to the veterans.
