Choosing the most effective controller for your application depends on a number of factors. The worksheet below serves as a checklist of things to consider when determining programmable controller requirements. It lists the most important areas to consider when choosing a system, as well as, provides space for recording determinations of your system needs. To print a copy, here is the PDF version of the Worksheet for Choosing a Controller.
If you prefer a more interactive selection process check out our online PLC Selector Tool.
Click here to learn more about AutomationDirect’s affordable programmable controllers.
Step 1: Proposed System
Determine whether your system is new or existing. Will your system be installed from scratch or are there existing products already installed? The rest of your system will need to be compatible with new components.
Why this is important: Certain controller products may not be compatible with others. Making sure your existing products are compatible with any new products you are researching will save you time and money.
Step 2: Environmental Issues
Consider any environmental issues that will affect your application (temperature, dust, vibration, codes specific to your facility, etc.).
Why this is important: Certain environments may affect the operation of a controller. For example, typical controllers have an operating temperature of 0-55 degrees Celsius (32-130 degrees F). If your application will include any extreme environmental conditions, or you have specific codes at your facility that must be met, you will need to either research products that meet those specifications or design the installation to meet requirements.
Step 3: Discrete Devices
Determine how many discrete devices your system will have. Which types (AC, DC, etc.) are needed?
Why this is important: The number and type of devices your system will include is directly linked to the amount of I/O that will be necessary for your system. You will need to choose a controller that supports your I/O count requirements and has modules that support your signal types.
Step 4: Analog Devices
Determine how many analog devices your system will have. Which types (voltage, current, temperature, etc.) are needed?
Why this is important: Same as with discrete devices, the number and type of devices your system will include is directly linked to the amount of I/O that will be necessary for your system. You will need to choose a controller that supports your I/O count requirements and has modules that support your signal types.
Step 5: Specialty Modules or Features
Determine whether your system will require any specialty features. Will your application require high-speed counting or positioning? What about data logging, a real-time clock or other specialty feature?
Why this is important: Specialty functions are not necessarily available in all controller CPUs or in standard I/O modules. Understanding the special functions your system may perform will help you determine which CPU to choose and whether or not you will need to purchase additional specialty modules.
Step 6: CPU Requirements
Determine the type of CPU you will need. How much memory will your system require? How many devices will your system have (determines data memory)? How large is your program, and what types of instructions will your program include (determines program memory)? How fast a scan time do you need?
Why this is important: Data memory refers to the amount of memory needed for dynamic data manipulation and storage in the system. For example, counter and timer instructions typically use data memory to store setpoints, current values, and other internal flags. If the application requires historical data retention, such as measured device values over a long period of time, the size of the data tables required may determine the CPU model you choose.
Program memory is the amount of memory needed to store the sequence of program instructions that have been selected to perform the application. Each type of instruction requires a specific amount of program memory. Applications that are basically sequential in nature can rely on the I/O device rule of thumb to estimate program memory (five words of program memory for each discrete device and 25 words for each analog device); complex applications will be more difficult to judge.
If scan time is important in your application, consider the CPU processor speed as well as instruction execution speed. Some CPUs are faster at Boolean logic but slower with data handling instructions. If special functions such as PID are required, the CPU you select may make those functions easier to perform.
Step 7: I/O Locations
Determine where your I/O will be located. Will your system require only local I/O, or both local and remote I/O locations?
Why this is important: If subsystems will be needed at long distances from the CPU, you will need a controller that supports remote I/O. You will also have to determine if the remote distances and speeds supported will be adequate for your application. Ethernet-connected I/O hardware is becoming one of the more popular communication standards. This I/O may also be referred to as distributed I/O, and may require a particular
protocol, such as Modbus.
Step 8: Communications
Determine your communication requirements. Will your system be communicating to other networks, systems or field devices?
Why this is important: Communication ports (other than the programming port) are not always included with a controller. Knowing your system communication requirements will help you choose a CPU that supports your communication requirements, or additional communication modules if necessary.
Step 9: Programming
Determine your programming requirements. Does your application require only traditional programming instructions, or are special instructions necessary? Do you prefer fixed memory addressing or tag name based control? Which programming language are you accustomed to?
Why this is important: Certain controllers may not support every type of instruction. You will need to choose a model that supports all instructions that you may need for a specific application. For example, built-in PID functions are much easier to use than writing your own code to perform closed-loop process control. Typical instructions such as timers, counters, etc., are available in most controllers. Also, many variations exist when it comes to the programming language (ladder logic, structured text, etc.) and memory addressing (fixed or tag name based). Choose the programming package that you are most comfortable with and that will offer the most ease-of-use when developing, troubleshooting and maintaining.
Something to Consider: Open-source Control
With the growing popularity of low-cost single-board controllers and the “Maker” communities that support them, it was only natural for them to find their way into the industrial realm. Off-the-shelf single-board controllers are intended for hobbyists and students but the automation industry needs an open-source controller that can handle extreme conditions. The ProductivityOpen controller (P1AM-100) is an industrial open-source controller designed for harsh environments that is programmed using C++ code for utmost controller customization.
Originally Published: Dec. 1, 2007