PLCs Run With the PAC

In the 1960s, most process or assembly line controls were based on electromechanical relays, which were robust but not particularly flexible. Soon, engineers grew tired of having to rewire their relays every time they made a change to their line and switched to an electronic control solution that leveraged microprocessor technology - the programmable logic controller (PLC). Today, that technology has matured into a $9 billion market, with PLCs vying with motion controllers and PCs for motion control dollars.  Let’s take a look at the current state of PLCs, the role they play in motion control, and where the technology is likely to go in the future.

Crunching numbers
Early PLCs were designed to take over equipment control tasks, for example on assembly lines or in process tools.  As such, they were good at handling timing and counting operations, as well as managing inputs and outputs.  Because of their origins and functions, they typically used ladder logic, the language used to program electromechanical replays.  Although they were effective, their use was somewhat limited.

One of the drivers of PLC growth was the International Electrotechnical Commission (IEC) and its 61131-3 standard.  The 61131-3 standard defined the languages PLCs should support, broadening them from ladder logic to include function block, instruction list, sequential function chart, and structured text.  “Having the availability of all the languages opened up the possibility of what people could use programmable controllers for, beyond just the relay replacements they started out as,” says Robert Nelson, controller marketing manager at Siemens Energy & Automation (Norcross, Georgia).  In the United States, for example, ladder logic tends to be common but in Europe, engineers are more likely to work with a function block approach. Language choice is also driven by industry, Nelson says.  “Function blocks are much more prevalent in the process-control industries and motion control applications.  Having these languages and the 61131-3 language standard broadened the use of programmable controllers.”

More choices meant that more engineers were turning to PLCs for their control needs.  At the same time, assembly lines and equipment were becoming increasingly sophisticated.  In addition to a PLC for discrete control, an assembly line might incorporate a motion control system, a process-control system, a sequence-control system, and so on, each with its own programming tools and each requiring its own design, hardware, software, and commissioning.  Often, the process of integrating multiple controls became a time-consuming and costly challenge, as control architectures became increasingly byzantine.

In response, designers began enhancing PLCs to allow them to control other types of systems such as motion and process.  Over time, a new name arose for these augmented devices: the programmable automation controller (PAC).  “There’s a migration taking place,” says Craig Resnick, director of research at the ARC Advisory Group (Dedham, Massachusetts), which coined the term.  “Now, instead of deploying three separate systems, you can just deploy one.  That's really the justification of the PAC - changing the application focus from a single PLC that's turning things on and off and performing timing and counting applications, to something that offers traditional PLC operation as well as the ability to do motion control and process control on the same platform.”

PAC mentality
Whether PACs constitute a new class of devices or just a new name for an existing one depends on who you ask.  To some, PAC is just a buzz word, and yet that doesn’t lessen its usefulness - the term provides an important tool for thinking about a unified approach to control and automation.  The power is in the notion of an integrated development environment.

“PLCs are really focused on discrete control, whereas PACs are focused on integrating multiple control disciplines,” says Robert Hirschinger, product marketing manager at Rockwell Automation (Milwaukee, Wisconsin). “It makes program development, commissioning, and maintenance much easier if you can do it under single control architecture and don’t have to worry about trying to integrate multiple controls together.  You get to program, configure, commission, and maintain the machine with a single software tool. You have a single view into the process.”

In addition to removing some of the headaches of integrating multiple control systems, such an approach can assist in making a cost argument for enhanced functionality. Consider, for example, a system that would benefit from one or two axes of motion control but with a cost structure that can’t tolerate the price of adding a separate motion system.  “Now that it's part of an integrated platform, you’re getting all the bells and whistles for one price with one development tool, one programming tool, one HMI, and one system to wire and maintain,” says Resnick.  “We’re seeing motion control getting into applications that were maybe not within its reach before because people didn't want to have to run or maintain or train people on multiple systems.  It gives the user all this power that they didn’t have before.”

It’s a trend that’s not limited to PACs, Nelson observes.  The OEM/user community has increasingly indicated a desire to move away from separate control systems, and the vendor community has responded.  “All the various types of controllers have broadened their scope to include the other control disciplines,” says Nelson.  “PLCs have expanded their capabilities to include motion control and process control, drive-based motion controllers have expanded their capabilities to include more PLC-logic kind of functions.  All of these controllers are starting to look more and more similar.”

Moving forward
Today, PLCs extend from low-end, commercial, off-the-shelf products that cost a few hundred dollars and run one or two axes, to comprehensive PACs sophisticated enough to control robotics and motion simultaneously with logic control and process control. Have they become commodities?  Not exactly.  Certainly, in the low-end devices, the programming is so simple that price may well be the biggest differentiator.  “Maybe you'd consider that a commodity,” says Nelson, “but I think pretty quickly you start to get into more complex applications, different functionality, different networking requirements, interfacing to different devices.  While some programmable controllers are very similar, they’re not really interchangeable.”

The use of flash cards, or smart cards, adds plug-and-play capabilities.  If a PLC fails, for example, the user can simply take out the flash card, swap in a new PLC, and install the flash card for rapid redeployment.  “It saves an OEM a great deal of money when they don’t have to send a field-application engineer to the customer with a laptop and programming software to update the PLC,” says Sloan Zupan, Controller & Network Section product marketing manager at Mitsubishi Electric Automation Inc. (Vernon Hills, Illinois).  “A lot of OEMs today are sending CompactFlash cards to their customers with updated programs.  The customer simply inserts the memory card in the front of the PLC, cycles the power, and it updates the PLC program.”

There are other options, as well.  One current trend is to leverage the processing power and memory of the HMI to support the PLC.  The customer directs the HMI to back up the PLC program and parameters.  When the PLC fails, maintenance installs a new PLC, and then restores its programming directly from the HMI.  There is no need to use a flash card or even download the parameters over the Internet.

PLCs, PACs, motion controllers, PCs. With all the options, it’s natural to wonder which is the best approach.  The answer, not surprisingly, depends on the application.  Engineers today have a range of technologies to get the job done.  In many cases, the choice of controller comes down not to specifications and capabilities but to the experience of the user.  If they’re comfortable with PLCs, and a PLC can handle the bulk of their needs but they want to add motion, then they’ll most likely choose a PLC with motion capabilities. If they have a motion control background and a motion controller can cover most of what they want to do except for a certain amount of logic, then they’ll look for a motion controller that includes more basic logic capabilities.  It’s not a question of right or wrong, it’s a question of what will get the job done most effectively and efficiently.

“It's not about what you call a controller. Really, this is just an industrial computer that you program,” says Nelson.  “Who cares what it's called?  What matters is whether the user needs to go to through extensive retraining and a shift in their mindset or whether they can start with something they're comfortable with that will take them where they want to go.  I advise customers to make sure they fully understand the needs of their application.  Once they understand that, there is a whole world of potential solutions out there.”