How to Choose an Industrial Automation Controller

Choosing the right controller requires careful evaluation of multiple requirements.

Jeff Payne, Product Manager for the Drives & Motors Group at AutomationDirect, authored an article for the May 2019 issue of Modern Pumping Today titled How to Choose an Industrial Automation Controller. Many OEMs and machine builders are more familiar with specifying motors for their designs than with automation topics, so this article provides some guidance for selecting an industrial automation controller. Designers may be aware of micro-PLCs, PLCs and PACs, but not be fully conversant with their unique or overlapping capabilities.

A good starting point, writes Jeff, is to break down the equipment’s operational needs and how if fits into the larger manufacturing environment.

If an integrated manufacturing system is being automated, a single large controller using multiple expansion and remote 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.


In this block diagram, each module is a machine that can be controlled
separately by a smaller PLC, or together by a larger PLC.

Automation engineers might be concerned that the PLC choice is an irreversible decision, but that does not need to be the case.

Some controller families, such as the Productivity Series PLCs, offer several different size options, each using the same programming software. The single programming environment provides application flexibility while saving time and money because programs can easily be converted or moved from one PLC to another.

Number, Types and Location of I/O

After the system-level decisions are made, Jeff recommends defining the I/O counts and types, preferably on a spreadsheet, including such considerations as signal type, power requirements and communication protocols.


These AutomationDirect Productivity Series 1000, 2000, and 3000 PLCs are different size controllers, but each uses the same programming software.

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 percent I/O can prevent major difficulties down the road.

Specialty functions such as intelligent I/O modules, high-speed counter modules, servo/stepper motor control and real-time clock availability must be determined.

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.

It’s Time to Communicate

Jeff cautions that the extent of 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.

Communication to other systems, 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.

Hardware Requirements

In addition to physical connections, add up the hardware needs for memory (both program and data), scan-time speed and battery backup. Advanced functionality like storing historical data or implementing complex sequences drives up memory usage. Most PLC vendors offer guidelines for estimating memory sizes.

Software Requirements

Jeff points out that while the software platform and programming methods are often a matter of personal choice, functional requirements are not.

The availability of 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 is often underestimated, so the application and controller support should both be checked. Look carefully at all programming functions required.

Factors to Consider when Choosing a Controller

  • 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

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.