Engineering conferences and publications thrive on controversy. There's nothing like a good religious debate to get one's blood flowing, and some engineering debates assume a religious air. There are the "fieldbus wars" and the "PLC vs. DCS vs. PC-based control" arguments. Technology and competition are combining to put a "double whammy" on these arguments. The result is more competition and more choices for control systems designers with less clear differentiation among the contenders.

This article is the second of a two-part series focusing on industrial controllers. The first appeared in January ("Controllers: Heartbeat of Production") written by Control Engineering senior editor, Dave Harrold. Because controllers are the central element of a control system, CE undertook an extensive survey of the latest controller offerings. A comprehensive capability matrix was developed and can be found online at www.controleng.com.

Remember when it was a big deal that a PLC had analog I/O modules? When a PID function block was offered with a company's Ladder Diagram (relay ladder logic) editor? Not only were specific controller types identified by application, often companies were, too.

PLCs were good for sequential control of an assembly line or some kinds of machines. With motion control in a stand-alone black box, many machines required a number of motion controllers plus a PLC for sequential control. These devices were all programmed differently. Some "DCS" products were good for large regulatory control applications, while others performed best for smaller process and batch applications. Certain companies were best known by their type of products, so some were typecast as machine-control companies, others as batch-processing companies, still others as regulatory control companies.

It's time to forget all these definitions. Discrete control vendors have added hardware and software to broaden their lines to include batch and other process applications. CNC manufacturers have added sequential logic and communications, so that one product can do the work that previously required three.

When the questionnaire for the CE study was composed, questions were constructed to discover what each supplier considered to be its products' strong application. The assumption was that each product would be designed with strengths in a particular application. The very first feedback from these suppliers was a complaint about being "boxed in" to one application. Results show that a full two-thirds of products are designed for multiple applications. In fact, 10% were deemed good for machine (discrete) control, batch control, and process (regulatory) control.

The idea of multi-application controllers has several implications. First, choosing one company as a primary control supplier may not limit choices or add complexity if different types of applications are added in the future. Another is increased competition. As companies that formerly were known as "discrete" product manufacturers expand product offerings and expertise into the "process" arena, engineers seeking solutions there have more options to consider when seeking the best solution at the best price.

What can we expect to see in the future? Rockwell Automation's (Mayfield Heights, O.) strategic marketing manager, John Nesi, pointed to a half-dozen items. Commercial technologies proliferate, primarily centered on processor speed and power, as well as memory enhancements. Web connectivity grows, along with an increased acceptance of Ethernet networking. Adoption of unifying architectures allows a single control architecture for use in multiple application domains. Leveraging object-based programming enables identical programming for each controller in a product line with the same set of instructions and features, as well as a similar approach to configuring I/O and other modules. Finally, Mr. Nesi sees increased adoption of industry-wide safety standards for PLCs.

Specifying the wrong product is a leading cause of problems in the field. It causes delays, additional costs, a blot on a reputation, and lost production. Considering this proliferation of competitive products from many suppliers, Control Engineering surveyed application support people from many of these suppliers to discover tips for success during that next system design.

Joe Campbell, Adept Technology (San Jose, Calif.) vp, offers a blunt assessment. "The guys that drive me crazy are those who worry about which Microsoft Windows platform is in the controller yet ignore important things like the I/O scan cycle requirement, motion latching, I/O point latching, need for a microsecond response, yet specify I/O modules on a fieldbus, etc."

So, be wise and consider the entire system next time. How fast must the system respond? What is the cycle time? Can the controller scan and update all I/O points quickly enough? Is the communication network fast enough?

Todd Walter, National Instruments' (Austin, Tex.) distributed I/O product manager, offers three criteria for choosing that next controller. "First is the reliability and form factor. Some applications, such as batch processing, may be installed in harsh industrial environments and will need a more rugged packaging that can withstand high temperatures and vibration. Second is flexibility, ability to perform advanced tasks like fuzzy logic for machine control or data logging for regulatory control. Third is speed of the processor and I/O system. Applications like machine control and CNC may require high-speed data acquisition and integration with vision and motion."

Another item to look for is compatibility with the preferences and training of those closest to the project. Joe Kimbrell, Automation Intelligence (Duluth, Ga.) engineering manager, states, "As a control system integrator, we are designing machine-control solutions for a wide variety of industries and applications. We prefer a text-based programming language that gives us flexibility to use the same platform for each of our projects."

One of the most important requirements in control systems design today is communications. Control engineers are facing ever-growing demands to provide information to a wide variety of information consumers. David Harris, Eaton/Cutler-Hammer (Milwaukee, Wis.) automation hardware product manager, says, "Since the main object of open control is to share data, consider whether the controller can take advantage of popular communication methods like Ethernet and OPC. Also, will the controller accept third-party hardware and/or software in order to provide a full solution? Regarding control software, can the program share data and tags, as well as provide easy editing and file manipulation?"

When a platform is chosen, for instance PLC or PC, decisions do not end there. There are sub-types of platforms within each of those major types. Then the kind and form factor of I/O modules must be evaluated and picked.

Alan Wells, technical marketing vp at ADLink (Irvine, Calif.), discusses pros and cons. "If you have picked PC-based control, you will still have to chose a PC form factor. This is often decided by what type of I/O cards are available. ISA/PCI cards are supported and manufactured by a wide range of vendors. PXI and CompactPCI offer a more rugged euro-card design with plug-and-play serviceability and better overall cost of ownership.

"Next consider the overall application. If the I/O devices are centralized, then a single industrial PC with pluggable I/O cards is a low-cost-per-I/O-point solution. With a large machine or manufacturing line, distributed I/O modules are required to point to different I/O form factors."

George Liao, Advantech Automation (Cincinnati, O.) HMI product manager cites system complexity as a factor. "There is not a dedicated answer about which application should use which controller. Since the processor is the core of a PC, the more complicated the application, more powerful performance of the CPU is required. The state-of-the-art processor may not be the right choice. It could be too big, too hot, and too expensive. For some simpler applications, a RISC processor is sufficient."

On the other hand, Paul Ruland, PLC and I/O product manager at AutomationDirect.com (Cumming, Ga.), discusses choosing a PLC. "Specifying a PLC has traditionally been based on the required I/O count and types. More I/O points mean bigger PLCs. Now with features like Ethernet communications, motion control, on-board PID, and remote connectivity, users have more controller choice flexibility. The most notable advances have been in nano- and micro-class controllers. Features like analog I/O points, auto-tune PID, floating-point math, multiple serial ports, and Ethernet and network connectivity blow away the old specification model."

Glenn Graney, GE Fanuc Automation (Charlottesville, Va.) marketing manager, notes, "The demands of applications are often based upon the scope of geography under the control domain. An OEM building a small, self-contained machine is often best served by a micro PLC or a combined PC/display product if HMI is also needed. A rolling mill application is often best served with traditional rack-based PLCs with inherent capability to access control LANs and coordinate the activity."

Dave Quebbemann, industrial automation marketing manager at Omron Electronics (Schaumberg, Ill.), details some specifications for various applications:

• Batch processing-check Class 1 Division 2 requirements, need for function block programming, math and analog capabilities;
• Waste water treatment-look at remote diagnostics and networking capabilities;
• Machine control-look at processing speed, advanced instructions, and networking; and
• Material handling-analyze processing speed, high-speed counter inputs, compatibility with motion control, small physical size of controller, and networking.

Some companies have standardized on one brand and model of controller, while others with a wide variety of processes within a plant require several different types of controllers. A constant headache for engineers in multi-controller plants is the problem of a different software package for every controller. This leads to cost, upgrade, and training problems.

Greg Nelson, automation products marketing manager at Schneider Electric (Raleigh, N.C.), suggests evaluating controllers from the programming perspective. "One common programming environment enables users to use the same tools and work in the same training and maintenance environment saving money, inventory, and time."

Check out online the controller capability survey, but don't be intimidated by the size. Most suppliers offer many types of controllers, but this just means that there is one (or more) controller available for every application.