The heart of any automated system is its controller. This is where the decisions are made to signal actuators in the system to launch into action based on feedback supplied by sensors.
But choosing a controller requires a series of decisions by the integrator or end user based on the application. A key controller decision revolves around which type of controller to use—a programmable logic controller (PLC), a programmable automation controller (PAC), or industrial PC (IPC).
Nate noted that the primary difference between a PLC and PAC is that a PAC is similar to a PLC but with additional features. An IPC can run the same software found on a PAC, but with the full features of a PC.
A feature typically associated with a PAC is its ability to be programmed in languages other than ladder logic. “Languages such as structured text, function block diagrams, and flowcharts can be used to program a PAC,” said Kay. “The memory is typically tag-based, whereas in a PLC the memory structure is often address-based. PACs also tend to be modular and use standard communication protocols so they can efficiently communicate with a wide variety of network devices such as remote I/O, remote panels, and drives. They can also handle complex applications like motion, advanced process control, and integrated safety.”
Highlighting the difference between address-based and tag-based memory structures, Kay said address-based structures—which can be found in most major PLCs—such as those from Allen-Bradley, Siemens, and Mitsubishi, come with a predefined range of integers, timers‚ or Boolean addresses. A tag-based controller is not restricted to using only the predetermined address ranges. “You can give an address any name you want,” said Kay. “It more closely resembles higher level programming languages like C, where you create variables as needed.”
Kay explained that an IPC can be programmed to run the same control software used on a PAC, but it runs on a full-blown industrial computer; and with that comes an operating system familiar to most end users and the IT department, such as Windows or Linux.
Making the determination
Ultimately, the application should help dictate which type of controller you choose. Kay said, PLCs are well-suited for standalone machines because they're robust and simple, which makes it easier for maintenance personnel or technicians familiar with technical drawings—the basis for ladder logic commonly used in PLC programming—to troubleshoot rather than the PC programming languages often used in PACs and IPCs.
PACs are commonly preferred for controlling larger processes and integrating safety, motion, distributed I/O, and network communications.
You can get a PLC to talk to network devices like a PAC, said Kay, but you often “have to add on hardware modules to perform those type of types of tasks; whereas a PAC is designed to communicate with network devices. For example, PACs come with function blocks that deal specifically with motion and safety.”
Ultimately, Kay said to choose the type of controller that lets you achieve the best and simplest design for your application. “If you're looking at a standalone machine, a PLC may be the right choice,” he said. “But if you want to also address motion and safety or controlling remote I/O, a PAC is often the way to go. And if you need to layer on additional features and software beyond what a PAC can do, that’s when you might start looking at an IPC.”
Leaders relevant to this article: