Transcript
Defining things in our orbit can take on the look and feel of an argument. What is a programmable automation controller (PAC)? If you ask 10 people, you might get 10 different answers.
In the early days of the automobile, there were various silos of expertise in niche-based cars that forged a market rather than reacting to one. Dick Morley states in his book, “Out of the Barn,” that Alfred P. Sloan bought these silos of expertise and brought the best of each silo and created General Motors. He also stated that the modern-day markets define products based on needs and wants.
The PAC is a result of this migration of technology.
In the late 1960s, the programmable logic controller (PLC) was born. Initial designs used the available chipsets, which were not microprocessor-based. The original PLCs used a bit-slice processor. The beginning of the microprocessor-based PLCs couldn’t have begun until 1974 when the Motorola 6800 and Intel 8080 CPUs were released. As we now know, that changed the world in a heartbeat.
The ability to have the computing power in a single chip allowed designers to create magic.
The original PLC was pretty basic. It had the computing power to solve ladder logic, read inputs and write to outputs and interface with a programming device. Any additional functions were added using the I/O structure.
There was a need to interface with process-based transducers—analog. There was a need to be able to control positioning in machine control; thus, servo and stepper controls were introduced through the I/O system. There was a desire to take the I/O module subsystem to the location of the I/O in the process, and remote I/O was born.
And then and most importantly devices needed to talk with each other—PLC to PLC. Communication protocols were developed to exchange data between devices and thus machines and processes. As the PLC evolved, communication options were integrated into the hardware design.
Technology advancements such as inexpensive memory allowed vendors to create more expansive operating systems to allow for different control strategies, such as sequential function chart and function block. PLC and distributed-control-system (DCS) applications started to encroach on each other’s markets. The lines were becoming blurred.
The real challenge for the controls engineer was to design a functional system and then program the system to perform the required strategy.
To say that all of these add-ons were integrated would have been a stretch. Configuration of most devices was done by setting individual bits in a data file.
So, the historical path of the PLC was market-driven and reactionary to some degree. You could create any control system by inserting modules into the hardware subsystem and distribute them around the process under control.
Enter the PAC. ARC Advisory Group coined this acronym in 2001 to differentiate hardware platforms from the PLC.
The basic premise of the PAC is integration of all of the add-ons into one platform by design. One of the basic differences is the ability to program in all IEC 61131-3 languages. Ladder logic is still king, but function block and structed text are being implemented more often.
These languages are being used in an integrated environment. A single control strategy can employ all five 61131 languages, if desired, and the execution of the programs is accomplished due to the power of the microprocessors in the hardware.
Certain vendors allow the user to execute programs written in computer languages, such as C++ or C#.
The PAC is the result of the evolutionary path of the PLC. The keyword here though is integrated.
Motion, communication, analog, discrete and even built-in HMI with edge capabilities are integrated into the platform. The software required to program these features is integrated into the integrated development environment (IDE), allowing the developer to seamlessly create control strategies using a tag-based programmatic approach.
The PAC has allowed for complex systems to be developed. One of the major issues of past PLC-based solutions is the ability of the maintenance team to troubleshoot the connected processes. The need for the floor electrician to be fluent in “PLC speak” has been well-documented. The more complex that a PLC system became, the harder it was for efficient and successful troubleshooting.
The PAC presents all information to the user in a neat software interface to allow for efficient troubleshooting.
So, what is a PAC? An integrated PLC on steroids. And we are very thankful for this reaction to market forces.
