Controller by Any Other Name

How Can a PAC Solution Help Machine Builders in Ways a Traditional PLC or PC-Based Control System Can't

By Joe Feeley

In recent years, machine builders and users have struggled to get a clear understanding of what a programmable automation controller (PAC) is, particularly since descriptions of these devices vary among automation suppliers.

More importantly, they want to know how a PAC solution might help them in ways that a traditional PLC or PC-based control system can't — or can do only with costly, messy and time-consuming add-ons.

What the hardware/software solution is called is not very important to two machine builders we'll tell you about in this article. It's the performance enhancements they enjoy compared with the older PLC or PC-based control solutions that matter. Some of this enhancement provides a competitive advantage, and some is a means to satisfy customer needs as they develop more data-collection requirements.

From PC to PAC
For 15 years, the Aagard Group has designed, engineered and built automated packaging machinery in Alexandria, Minn., including integrated and standalone flexible form fill seal packaging machines, wrap-around cartoners, endload cartoners, sleevers, retort loading/unloading systems, case packers, tray packers and palletizers/unitizers.

"We used a PC-based control system with a Sercos bus for all our product lines for about eight years, before moving to what Rockwell Automation calls one of its PAC solutions," says Daren Myren, Aagard controls engineer. Myren also is Aagard's Rockwell Automation Platform Manager across all the company's machine lines. "At that time, there weren't any PACs or PLCs out there that could handle our demand — 40 to 50 Sercos axis counts and keep the processing time reasonable — with just one controller. The driving factor to switch to a ControlLogix L7 platform about two years ago was that we now could control up to 32 axes on one controller and still maintain our performance."

Another major factor was too many failures on the PC-based system. Myren says it was a more-fragile system. "Plants wouldn't know exactly how to handle security updates, and some of them could cause issues with our control system and sometimes shut the machine down," he adds. "Since we've been using the PACs, I'm not sure we've had even one PAC failure."

When the machine automation scheme was PC-based, Aagard developed and integrated a lot of remote access connectivity technology by itself. "We wrote a lot of software for data collection," Myren recalls. "We put the PC right on the server to remotely access and control the machine. Because a lot of our customers have a Rockwell-based data-collection system, our move to ControlLogix allowed us to use the PAC data and communications capability directly with the customers' data-collection systems."

The move to a PAC architecture wasn't a big concern for Aagard's customer base. "Our customers really didn't know the PC-based system very well," Myren explains. "But at that time they knew that we couldn't handle the higher axis count with a PLC or, if we did, it was going to cost a whole lot more. The PAC is a way for us to provide that same functionality at reasonable cost, and the customers were comfortable with the Rockwell brand."

The Do-All Control Platform
The supplier community earnestly does its best to position its version of what a PAC is.

"Our PAC is a multi-discipline device that incorporates more than just PLC functions, motion, process and safety," begins Dennis Wylie, product manager for the Rockwell Automation ControlLogix platform. "It brings in more direct communication with databases, multiple field networks, and enterprise-level networks."

Wylie says it's becoming more of a server-class device that is a do-all control approach for everything except smaller, simpler installations that just don't need it all. "But we're scaling that, too," he adds. "Even the smaller CompactLogix devices have some of this capability built in for when you just don't need $25,000 worth of database integration or $25,000 of historical data logging capability."

B&R Industrial Automation's stand on what a PAC-type solution looks like these days is that the primary concern shouldn't be in the terminology. "A main difference between a PAC and PLC is that a PAC provides better control of the timing of the application programs that run on the controller," says Robert Muehlfellner, director of automation at B&R Industrial Automation. "On a PAC, the program will run in a scheduled cyclic mode. An underlying real-time operating system will schedule programs in cyclic tasks with different priorities and cycle times independent of the program execution time." This, Muehlfellner argues, allows the application to be separated into programs running in a fast cycle time for time-critical tasks such as digital I/O processing, and slower cycle times for less time-critical tasks like PID temperature control and HMI logic on the machine.

"Another difference between a PAC and a PLC is the ability to incorporate additional functionality like motion and robotic control, remote or onboard visualization, file handling, web server, etc., on the same piece of hardware, allowing consolidation of multiple controllers into a single one and offering value-adds in terms of diagnostics and data collection capabilities," Muehlfellner says.

Rockwell Automation doesn't play favorites about whether a PAC approach is better suited to PC-based control users vs. PLC users. "This really defines the hybrid controller space," Wylie contends. "We have PAC users who were accustomed to the PLC, ladder logic-driven solution. Likewise, former higher-end PC-based users like the standards-based languages and communication capabilities they had."

A PAC might not be where you need to stream YouTube videos, Wylie says. "But it does I/O control well. A PC can do that, but it's certainly not its strong suit. But former PC users like the idea that they don't have to worry about as many security patches."

After PLCs
G.A. Braun, based in North Syracuse, N.Y., makes large industrial-grade laundry and textile equipment. Its multi-chamber, tunnel-style washers can process up to 8,800 lb of laundry per hour. The company has operated since 1946.

"The individual machines have their own control systems, but we can link the washers, dryers, conveyance systems to operate as one system because we can connect them via a SCADA package we wrote ourselves in LabView," explains Matt Fenn, lead software engineer for Braun. "The SCADA system turns them from individual machines in an automated system."

Braun and B&R Automation go back some 30 years, and the machine builder migrated through what Fenn calls B&R's "blackline" traditional rack-based PLCs "with a CPU card, input and output cards, and all programmed in ladder logic with a little assembly language in there and a few of your own function blocks."

Later, Braun migrated to B&R's System 2003 CPUs and I/O. At that time, Fenn says, it was called a programmable computer controller (PCC), which still was most like a PLC, but began to have some of the capability that now defines what a PAC might be.

"One of the big differences was the Windows-based development environment they supplied," Fenn adds. "It allowed us to have distributed I/O on or between machines with CANbus, whereas machines using the old approach were pretty much hardwired." Fenn says he liked the improved flexibility as well, and the company began programming in C. "Now, if I wanted to talk Modbus out of a serial port, I could do that in software without having to buy specialized hardware."

Muehlfellner adds, "What might look more complex at first really offers much greater flexibility to any machine builder in designing the application software and achieving better production accuracy and repeatability due to a constant timing."

The migration continued to a solution based on B&R's touchscreen visualization and PLC with a real-time OS in one platform, the Power Panel 420. "The Automation Studio development platform was backward-compatible, allowing us to pretty easily port the 2003-based programming to the new hardware offering," Fenn says. "That helps us take advantage of higher-end hardware capabilities without rewriting our programs." According to Fenn, at least 95% of the machines Braun sells today are based on this platform.

Customer Support
"The amount of time we spend working with our customers on automation issues has decreased," Aagard's Myren says. "We don't get as many calls in part because they can troubleshoot a Rockwell system themselves instead of depending on our expertise with the PC-based system."

Fenn hasn't found reasons yet to use the IEC 61131-3 language options available to him, since for now, the team is comfortable in C. But he sees a few important hardware advantages that impact customer support. "The entire application now is stored on compact flash, whereas on a traditional PLC, our application was on the CPU in memory chips," he explains. "So if I wanted to do a software upgrade, I would have to send out a set of chips, which usually wasn't practical, so you had to replace the CPU or flash it onsite with a laptop, or get somebody to try to pull off an EPROM and replace it, which was pretty tricky. So now, I just burn a new compact flash drive, and send it to the company's technician who just swaps out the flash drive."

The networking diagnostics are great as well, Fenn says. "And that's something that we couldn't do before this upgrade. I can connect all these machines over Ethernet, and through our SCADA package, go in and update any of them without the need for the flash-drive exchange. During commissioning, it's very handy, since I can monitor the variables on the controller or see an on-site installation software issue from here in my office, and go into the controller and fix the problem via the SCADA PC."

What's Next?
"Going forward, this PAC solution will offer things we previously had to develop ourselves for PC-based control, like change-logging and other security aspects of the system," Myren says. "We're seeing some of this and even more coming out in newer Rockwell releases. We can get these as a module that plugs into the control rack or as a software plug-in instead of having to write it ourselves."

Wylie says that the means to secure a PAC compared with securing a PC is becoming a major topic for every customer moving forward, given recent world events, and Rockwell is putting these threads of security in at the core, the chip level of these control architectures.

As to where a PAC-like environment will take his company's machine control abilities in the future, Fenn is evaluating the newest version of the Power Panel. "Instead of doing the visualization through the Automation Studio, it runs Windows Embedded on top of the RTOS," Fenn says. "That gives us the flexibility to write our visualization with .NET and leverage some third-party Windows software. I could put a SQL database on the machine so it can do its own data collection, enable preventive maintenance databases, and I even can show repair videos on the machine."

Fenn continues, "We've come such a long way from original proprietary control software that was written by an ex-employee. The technology changes so fast that we can't be spending time away from our core business by having to write software and build our own hardware. We can ride the train of commercially available solutions and grow our capabilities that way."

The lines from PLC to PAC and PC blur depending on what functionality the underlying hardware and operating system architecture of the controller allows. "Some manufacturers are using microcontroller- or RISC-based architectures, which are in essence a 'PLC on steroids' — faster and with better timing but not too much more functionality common in a PC-based architecture," Muehlfellner states. "Some PC manufacturers come from the other direction by taking an industrialized PC with a real-time operating system and maybe a second OS like Windows and calling it a PAC or 'soft PLC.' Such systems offer great performance and additional functionality, but can't necessarily be scaled down cost-efficiently for lower-end applications because of the PC hardware overhead."