One (or more) Controller for Every Application

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.

By Gary A. Mintchell, Control Engineering February 1, 2002
  • Machine control

  • Embedded control

  • Process and advanced control

  • Controllers

  • Motion control

  • Robotics

Compare logic control frameworks
Criteria for selecting PLC supplier
Scan these 10 issues to pick a robot controller
Introductions: controller, software

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 .

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.

Multiple applications

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?

Seek reliability

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.

Pick a platform

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 (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.”

Know the geography

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.

Compare logic control frameworks

Logic control remains a critical component of manufacturing systems, but programs are still written much the same way that they were 30 years ago, one ladder rung at a time. Unlike progress made in process industries with standards like ANSI/ISA S88, discrete control theory lacks such a theoretical framework. It also lacks the rigor of computer science taught programming.

C. K. Gollapudi and D. M. Tilbury of the University of Michigan Engineering Research Center for Reconfigurable Machining Systems (Ann Arbor, Mich.) have released a paper entitled “Familiar and Emerging logic control Frameworks: A Critical Comparison” to further academic and industry discussion toward such theoretical rigor in discrete manufacturing controls. This paper is the result of further study by the authors. Control Engineering previously reported the work of the ERC in Dec.’00 issue, available at

The paper, seen in its entirety at Control Engineering Online, details the four design needs of development, debugging, maintenance, and reconfiguration. Different existing frameworks for logic control programming are investigated and compared.

The authors state, “The life cycle of a logic control system can be broken into four stages: development, debugging, maintenance, and reconfiguration. Ideally, good software tools should lower the cost contributed by logic control elements in setup, maintenance, and operation, and should increase the human efficiency factors related to control at all stages of the life cycle.

“No conclusion on the ‘best’ method for logic control can yet be drawn, but Petri nets and modular finite-state machines show very good potential. This brief comparison of logic control frameworks will hopefully inspire further work and lead to better and more powerful tools for logic control design and verification. Through academic-industry cooperation, these new tools can reduce the lead time and ramp up time for logic control.”

For more information on S88, see Control Engineering Online, Web Exclusives, Aug.’01, “Accelerating Product Deployment with Inter-Enterprise Recipe Management.” Also visit

Criteria for selecting PLC supplier

Commercial issues

Quality of products

Quality of pre-sales service

Local presence

Wide range of products

Supplier reputation

Discount price

Willingness to customize products

List price

Technical issues

Quality of tech support

Reusable programming code

Integration with third-party devices

Uses IEC 61131-3 languages

Supplier reputation

Supports open networking standards

CPU scan time

Wide range of related products

Scan these 10 issues to pick a robot controller

Joe Campbell, Adept Technology (San Jose, Calif.) vp, notes 10 issues to consider when choosing a robot controller.

Is the application path intensive or pick and place? Software optimized for path functions will not deliver the performance required for high-speed applications.

How fast is the required I/O response? While most I/O devices respond happily in milliseconds, some functions like stop-on-force or motion latching require microsecond response.

Where is the sensor? If the sensor is external to the controller, assure enough processing and communication bandwidth.

Are you safe? Assure compliance with safety standards including ANSI 15.06.

Going international? If so, make sure controller (or systems) has the CE mark.

Is your “open” architecture closed? If you plan to add third-party boards or software, make sure the vendor allows it.

Do you know your networks? Make sure you know exactly what hardware connections and software protocols are available.

Need dual robots? If using two robots in a single cell, determine if you can live with one controller or if two will be necessary.

9 Do you have enough software power? Match software power to the application.

0 It’s just another controller, isn’t it? Apply traditional control engineering guidelines in determining I/O capacity; selecting and designing the graphical user interface:, and providing power isolation and backup, enclosures, and other interconnects.

Introductions: controller, software

Two products were announced just in time to make the controller survey.

Control Technology Corp. (Hopkinton, Mass.) announced Blue Fusion 5100 series. The small, DIN rail-mount controller combines configurable I/O points, motion control, and enterprise connectivity. 10/100 Mbps Ethernet is built-in. The controller supports standard Internet protocols including HTTP (hypertext transfer protocol, the standard transport protocol), SOAP (simple object access protocol, an XML-related protocol for communicating information), SMTP (simple mail transfer protocol, for transporting e-mail), and RMI (remote method invocation, a Java-based messaging protocol that provides web-based read/write access to controller variables. Six internal bays for function modules allow up to 50 digital and analog I/O points and up to 6-1/2 axes of stepper or servo control. Programming is in CTC’s state language, Quickstep.

Opto 22 (Temecula, Calif.) has released version 4.0 of FactoryFloor industrial automation software suite. The significant upgrade is scripting capability within the flowchart programming editor. OptoScript is similar to C or Pascal languages, and enables creating math expressions, defining control loops, conditional branching, and manipulating strings.