How to choose an industrial automation controller

Choosing the most effective controller requires careful evaluation of multiple requirements.


Figure 1: In this block diagram, each module is a machine that can be controlled separately by a smaller programmable logic controller (PLC), or together by a larger PLC. Courtesy: AutomationDirectThere are many important items to consider when choosing a controller for machine and process automation. Breaking down the equipment's operational needs is a starting point and will help evaluate the range of controllers specified by OEMs or machine builders. Depending on how the equipment fits into the larger manufacturing environment, the automation system can provide a complete solution or just control individual parts.

The controller specified, such as a programmable logic controller (PLC) or programmable automation controller (PAC), can control a single station, a machine, a process unit, a whole assembly line, or an entire plant. If an integrated manufacturing system is being automated, a single large controller using multiple expansion and remote input/output (I/O) bases communicating via Ethernet can provide end-to-end control. However, another application may require compartmentalizing the automation by breaking the system into multiple, logical sections. In this case, the automation may be split and spread among smaller PLCs or even micro PLCs, depending on the demand and functionality (see Figure 1).

Figure 2: These AutomationDirect Productivity Series 1000, 2000, and 3000 PLCs are different size controllers, but each uses the same programming software. Courtesy: AutomationDirectMost automation engineers would see this as an irreversible decision since these two choices suggest vastly different platforms, but such does not have to be the case. Some controller families offer several different size options, each using the same programming software (see Figure 2). The single programming environment provides application flexibility while saving time and money because programs easily can be converted or moved from one PLC to another PLC for compatibility among projects.

The difficult part can be deciding whether to run a single program on a large PLC, or to deploy the same project on multiple smaller PLCs, each only executing the parts of the program needed to run the specific subsystem.

It's more complex than picking a PLC, PAC, or PC-based controller-size, capabilities, and functions enter into the discussion. To help decide which is the best controller to use in your application, consider the following factors:

  • Automation new or existing system
  • Environmental issues
  • Discrete devices
  • Analog devices
  • Loop control
  • Specialty modules or features
  • I/O locations (local and remote)
  • Communication
  • Programming.

Whether the system is new or existing often dictates many of the critical factors for selection. If there are products already installed, it's a good practice to make the new system compatible with them. Some controller products, even from the same manufacturer, are not compatible with others.

If extreme environmental conditions exist, ambient temperature limits can be a big issue. A typical controller has an operating temperature range of 30°F to 130°F, but actual conditions on the plant floor or specific codes in force at the facility may demand a product that has been designed to a tougher standard.

Number, types, and location of I/O

With some of the system-level items out of the way, defining the I/O count and field device types is next on the list. It is good practice to list all the discrete inputs and outputs on a spreadsheet-and to define each type, such as analog sensor, digital sensor, solenoid, actuator, control valve, and so on. Include the signal type, power requirement, communication protocol, and other considerations.

The number of I/O points and types defined has a big effect on the control platform selected. A common mistake is to select a controller able to handle immediate needs but without room for future expansion. Including room to accommodate an extra 20% I/O can prevent major difficulties down the road. At the same time be aware that some controllers limit certain types of I/O, especially analog and specialty I/Os, such as high-speed inputs or outputs. These may be just as problematic a constraint.

The I/O spreadsheet also should list function and signal level for all the analog devices needed. This includes individual totals for voltage loop, current loop, thermocouple, and resistance temperature detector (RTD) inputs-with summary totals for voltage and current outputs. The controller specifications must be checked to ensure the total number of analog inputs and outputs are supported, as well as the signal levels.

Specialty I/Os, or intelligent modules, also must be broken down and listed in the I/O spreadsheet. Specialty items include real-time clock, high-speed counter, high-speed output, positioning, servo/stepper motors, and others.

The specialty functionality needed for an application may not be supported by a controller. Don't assume every controller can tell the time or has advanced or even simple motion control functions. Understanding the application requirements and controller capabilities is a must to ensure all features needed now and in the foreseeable future are available.

The physical location of the I/O terminals with respect to the field devices also should be defined carefully and added to the spreadsheet. This modular breakdown will help lay out the local and remote I/O needs, and help determine what real-time communication protocols may be required. Some installations keep things local, whereas others rely heavily on remote I/O, or a combination of both.

If there are long distances between the controller and subsystems, remote I/O is a good option instead of long wire runs to individual field devices. The communication method and speeds supported must be adequate for the application. Serial and Ethernet-based I/O are just some of the options. Industrial Ethernet protocols such as EtherNet/IP are popular, along with various versions of Modbus and others.

It's time to communicate

Figure 3: AutomationDirect Productivity Series CPUs offer the ability to communicate via industrial Ethernet, serial, and USB connections. Courtesy: AutomationDirectIn addition to distributed I/O, communication among multiple PLCs, peripheral devices, and enterprise-level systems may be required. The extent of these communication needs must be determined early in the process with the expectation that whatever they are now, they will only get more complex going forward. Some controllers may have only one or two communication ports, one of which may be used for programming only. The controllers also may not support the most popular protocols, or a specific protocol needed for a critical application.

Communication to other systems, human-machine interfaces (HMIs) and field devices via industrial Ethernet or serial communication, needs to be defined. With the rapid growth of Internet of Things applications, more comm ports, and communication options are always better. Make sure there are one or two extra Ethernet ports, a serial port, a USB port, and other configurable options available (see Figure 3).

Specify which Ethernet protocols—such as EtherNet/IP, Modbus TCP, and others, along with serial and ASCII protocols—are needed. This will help select a controller able to support current and future requirements.

Hardware requirements

Some hardware requirements to consider are the amount of memory, scan-time speed, and battery backup. The controller will need sufficient system memory to support both data and program requirements.

Determining how many devices need to be supported by the system helps with the required data memory estimates. Data memory is used for both variable storage, and for dynamic data manipulation. Preset setpoints, accumulated time/counts, and other internal flags in timers and counters are examples of data memory users.

The need to store historical data in the controller can call for a much larger data table size. Careful detail of data logging requirements, access methods to get to the data, and interfaces to HMI/supervisory control and data acquisition (SCADA) and historian databases should be specified. Networking, protocol, and the memory needs are all import requirements for connection to the Industrial Internet of Things (IIoT).

The program size and the types of instructions used also affect program memory needs. Larger programs with many sequences, sophisticated control functions, and fault logic may increase memory needs. Estimating controller memory needs based on the number of program rungs and data files may be possible, but some controllers have tag-name based programming, while others have fixed but expandable data tables of different types. Some controllers also store documentation in the controller program memory.

Different program instructions have different memory needs, usually noted in the programming manual. The amount of memory used by programs and data tables varies widely between controllers. A useful rule of thumb suggests five to 100 words of memory for each discrete I/O device, and 25 to 500 words of memory for analog I/O, but complex applications make it difficult to estimate. A better way is to develop some preliminary code for a portion of the application and check actual memory usage.

Fast cycle times on a machine need all the help they can get from the controller. Often, a fast controller scan time is a requirement. The controller CPU speed and instruction execution speed are both factors as a controller may have faster Boolean logic, yet be slower when executing data-handling instructions.

Software requirements

Courtesy: AutomationDirectWhile the software platform and programing methods are often a matter of personal choice, functional requirements are not. The availability of proportional-integral-derivative (PID) loops, floating-point math, drum sequencing, program interrupts, and subroutines must be considered in the selection process.

Some controllers don't support all program instructions necessary for a specific application. An example of this is PID loop function. It's much easier to use built-in PID instructions, if available, instead of writing custom code to support closed-loop process control needs. The number of PID loops required often is underestimated, so the application and controller support should both be checked. Look carefully at all programming functions required.

Drums, sequencers, and real-time clocks are other programming needs that may also be necessary for a successful control system and application. Many other factors may enter into the discussion but performing a thorough analysis of the points presented here will be a good start to selecting the right controller for your application.

Jeff Payne is the automation controls group product manager at AutomationDirect. He managed, designed, programmed, installed, maintained, and repaired a wide variety of highly automated equipment before starting at AutomationDirect 19 years ago on the technical phone support team. He has been working in and around the world of industrial automation for almost 30 years.

This article appears in the Applied Automation supplement for Control Engineering and Plant Engineering.

- See other articles from the supplement below.

Top Plant
The Top Plant program honors outstanding manufacturing facilities in North America.
Product of the Year
The Product of the Year program recognizes products newly released in the manufacturing industries.
System Integrator of the Year
Each year, a panel of Control Engineering and Plant Engineering editors and industry expert judges select the System Integrator of the Year Award winners in three categories.
October 2018
Tools vs. sensors, functional safety, compressor rental, an operational network of maintenance and safety
September 2018
2018 Engineering Leaders under 40, Women in Engineering, Six ways to reduce waste in manufacturing, and Four robot implementation challenges.
GAMS preview, 2018 Mid-Year Report, EAM and Safety
October 2018
2018 Product of the Year; Subsurface data methodologies; Digital twins; Well lifecycle data
August 2018
SCADA standardization, capital expenditures, data-driven drilling and execution
June 2018
Machine learning, produced water benefits, programming cavity pumps
Spring 2018
Burners for heat-treating furnaces, CHP, dryers, gas humidification, and more
October 2018
Complex upgrades for system integrators; Process control safety and compliance
September 2018
Effective process analytics; Four reasons why LTE networks are not IIoT ready

Annual Salary Survey

After two years of economic concerns, manufacturing leaders once again have homed in on the single biggest issue facing their operations:

It's the workers—or more specifically, the lack of workers.

The 2017 Plant Engineering Salary Survey looks at not just what plant managers make, but what they think. As they look across their plants today, plant managers say they don’t have the operational depth to take on the new technologies and new challenges of global manufacturing.

Read more: 2017 Salary Survey

The Maintenance and Reliability Coach's blog
Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
One Voice for Manufacturing
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Maintenance and Reliability Professionals Blog
The Society for Maintenance and Reliability Professionals an organization devoted...
Machine Safety
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
Research Analyst Blog
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Marshall on Maintenance
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
Lachance on CMMS
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.
Material Handling
This digital report explains how everything from conveyors and robots to automatic picking systems and digital orders have evolved to keep pace with the speed of change in the supply chain.
Electrical Safety Update
This digital report explains how plant engineers need to take greater care when it comes to electrical safety incidents on the plant floor.
IIoT: Machines, Equipment, & Asset Management
Articles in this digital report highlight technologies that enable Industrial Internet of Things, IIoT-related products and strategies.
Randy Steele
Maintenance Manager; California Oils Corp.
Matthew J. Woo, PE, RCDD, LEED AP BD+C
Associate, Electrical Engineering; Wood Harbinger
Randy Oliver
Control Systems Engineer; Robert Bosch Corp.
Data Centers: Impacts of Climate and Cooling Technology
This course focuses on climate analysis, appropriateness of cooling system selection, and combining cooling systems.
Safety First: Arc Flash 101
This course will help identify and reveal electrical hazards and identify the solutions to implementing and maintaining a safe work environment.
Critical Power: Hospital Electrical Systems
This course explains how maintaining power and communication systems through emergency power-generation systems is critical.
Design of Safe and Reliable Hydraulic Systems for Subsea Applications
This eGuide explains how the operation of hydraulic systems for subsea applications requires the user to consider additional aspects because of the unique conditions that apply to the setting
click me