The argument of programmable automation controller (PAC) vs. programmable logic controller (PLC) rages on. In my humble opinion, it needs to stop. There is no difference as such.
They both do the same thing only differently. Granted, the ability to get to where you needed or wanted to go with either platform is possibly easier with a PAC, but it doesn’t take away the usage equation of both: they control automated processes and machines. End of story.
Marketing allows for a new buzzword, but, in reality, it is a need to create a new buzz. PLC was long in the tooth, so let’s create a new energy by using a new name.
As I was researching and investigating programming languages and the differences between a PAC and a PLC, I can report that there is nothing different between the two, from an application-software point of view.
That is a generalization of course, but in the 1980s Allen-Bradley’s PLC-5—a PLC, not a PAC—had an option to program in sequential function chart (SFC). Forty years later, SFC can be found in any controller that supports the IEC 61131-3 specification—I refrain from using the word “standard.” Vendors may or may not add functionality to SFC to make it their own, but I digress.
I was the surprised recipient of a new Arduino industrial controller—notice it is not called anything but. It has the normal Arduino programming interface, which is nothing like anything in the industrial world. The Arduino organization developed an IEC interface to the controller. I haven’t delved into the environment yet, but it is a winter project. Note that I live in Canada.
On another front, however, a similar controller that I have delved into does have a full IEC 61131-3 interface. The company name is Altus, and the form factor is exactly the same as the Arduino unit.
The software environment is very comprehensive. It supports the IEC specification to a T. There are additional libraries that support the hardware, of course, but also some additional programming constructs that are bound within the IEC environment.
Heaven forbid, it even has a built-in human-machine-interface (HMI) functionality.
So, let’s put the PAC/PLC argument to bed; they are effectively the same. The one major software difference is the fact that the PAC hardware and firmware, which is effectively Version 5.0 of the PLC, but still effectively a PLC, has a different hardware and firmware platform, as well as a different operating system (OS).
Aha! That’s where the difference is. The PAC can run computer-based software, such as Windows and/or Linux. It is not a proprietary OS as such. It doesn’t use Analog Devices’ bit-slice processor technology, and it doesn’t use electrically erasable programmable read-only memory (EEPROM).
Flash memory changed a lot of the thinking in the way that operating systems can in fact upgrade in real time by overwriting flash under program control. Rockwell’s CompactLogix system can be upgraded in a flash—pun intended.
Because of this ability to adjust on the fly, the newfangled PLCs are really now full-bore computers running computer-based software and firmware, with the additional ability to run software from universal-serial-bus (USB) devices. Yep, a legacy PLC cannot do that.
Because the fundamental environment of the hardware can support other facets of software, this allows the PLC to have a wider range of application. Beckhoff PC-based control runs Linux and runs IEC-61131 software on top of it. The built-in HMI that runs on Linux allows it to be an all-in-one.
Rockwell’s new CompactLogix allows for up to four virtual machines running on the same hardware, which can include Windows Embedded, part of Windows IoT OS, and can host HMI software running on the same hardware. Yep, legacy cannot do that.
But does it control the process? Yes, it does. As a controller it does. The Altus hardware platform does the same thing, as well.
IEC-61131 software runs on just about everything. CoDeSys is the main engine for most. What that does is in effect make the software that runs on various controllers similar. PLC vs. PAC is a moot point.
I was once the managing director of PLCopen, whose main function in life is to support the IEC specification, and I have to say it was an uphill battle in getting the marketplace to wean itself of proprietary functional programming environments and software. Modicon vs. Allen-Bradley was always a conflict.
Now it doesn’t matter, since most mainstream hardware platforms support the IEC specification at some level. IEC-61131 is the platform that most, if not all, use on some level.
The abilities we have, regarding application software’s use on our controller platforms, are wide-ranging, and the effects are wide-reaching. Imagine communicating to a cloud-based database directly from your controller using a message-queuing-telemetry-transport (MQTT) broker in real time.
Yep, legacy controllers can’t do that. Long live the PAC.
