For starters, splitting the equipment’s operation needs is a good place to start, which will help users evaluate the range of controllers specified by machine builders. The automation system can provide a comprehensive solution or individual control, depending on how it fits into the manufacturing scenario.
A Programmable Logic Controller (PLC), Programmable Automation Controller (PAC) or Industrial Personal Computer (IPC) can provide control for a single station, machine, assembly line or even the entire plant floor. In the case of an integrated manufacturing system, a single large controller featuring remote input/output bases, communicating via Ethernet can be used to provide end-to-end control. However, there may be times in which the application may require a modular approach, where breaking down the automation system into logical sections would be more suitable. In such cases, automation is compartmentalized and spread among smaller PLCs, depending on the workload.
Some automation experts view these two decisions as miles apart from each other, concluding that both require different platforms. But this doesn’t have to true. There are some manufacturers that have controllers offering different sizing options, all compatible with the same programming software. The presence of a single programming environment means flexibility can be instilled within the system, while costs associated with program development can be cut, as projects can be ported from one PLC to the other.
The daunting decision however is deciding whether a large PLC be employed for a single program or whether a modular approach be used. The decision is much more complex then picking a PLC, PAC or PC-based controller. Considering the following factors can help build a good base:
Whether the system is new or existing can help clear out a lot of confusions and influence the remaining factors for selection. If products are already installed, compatibility becomes of paramount importance, neutralizing number of products that are of no use.
The choice of controller is also dependent on the environmental conditions. If there are extreme conditions, such as those related to temperature, humidity, dust, etc. then the controller would need to meet these in order to remain operational.
Defining the I/O count and field device types is next on the list. Start off with listing all the discrete inputs and outputs on a spreadsheet, defining each type, e.g. digital sensor, analog sensor, actuator, control valve, etc. The parameters that must be jotted down include communication protocol, power equivalent, etc.
The type and number of I/O points has a big impact on the selection of the control platform. Machine builders often make the mistake of choosing controllers that can meet the immediate needs without leaving room for future expansion. By including room for expansion, by at least 20%, I/O can avert major crises in the future. There are also some controllers that have limited types of I/Os, such as analog, high-speed inputs, etc. This may also become a problem down the road.
The spreadsheet mentioned earlier should incorporate the functions and signal level of all analog devices, including individual totals for current/voltage loop, resistance temperature detector inputs, thermocouples, etc. The controllers’ specifications must be matched with these requirements so that all analog inputs and outputs are supported, as well as their signal types.
Moreover, specialty I/Os, must also be listed in the spreadsheet. These may include but are not limited to high-speed inputs/outputs, counters, real-time clocks and servo/stepper motors. There may be controllers that may not have specialty functionalities so be sure that you carry out a thorough analysis before making your decision. Understanding the controller’s capabilities and the application requirements is essential.
The physical location of the I/O terminals must also be defined, with respect to the field devices, and jotted down in the spreadsheet. Breaking down these requirements into smaller modules will help understand the local and remote I/O needs, which will in turn help in determining which real-time communication protocols are needed. There are some installations where locality is preferred while others are heavily reliant on remote I/Os.
If the distance between the controllers and subsystems is considerable the remote I/O would be a good choice instead of going through the ordeal of cabling each field device. Furthermore, the communication methods and speeds must be supported, whether its Serial or Ethernet-based I/O. In today’s industrial setting, Ethernet protocols such as EtherNet/IP are becoming popular along with specifically development versions of open-source protocols such as Modbus.
Communications among peripheral devices, distributed I/O, PLCs and enterprise systems may be a necessity for some plant floors. The scope of these must be defined early on, with the consideration that things will become more complex as you move ahead. Some controllers may offer only 1 – 2 ports, one of which will be reserved for programming, while others may not support specific protocols required for mission-critical applications.
The communications that will take place between the controller and HMIs or field devices must also be specified. The onset of Internet of Things has made it essential to have communication options open. Therefore, it must be ensured that there are additional Ethernet, serial, USB ports available in the controller.
Specification of Ethernet protocols such as Modbus TCP, Ethernet/IP, Profibus, etc. must be carried out, both for current requirements and future expansion.
Common hardware considerations that must be made include the scan-time speed, amount of memory and battery backup. The controller must have enough system memory to support both program requirements and data. These estimates can be made by figuring out the number of devices in the system. Data memory is used for both dynamic data manipulation and variable storage, examples being preset setpoints, internal flags in timers and accumulated time/counts.
The data table size can swell if there is a need to store the historical data on the controller. The need for data logging, interfaces to HMI/SCADA, access methods and historian databases must all be clearly specified, while in an IIoT scenario, networking, protocol definition and memory needs also become important.
The types of instructions and the program’s size itself can affect the memory needs as well. If the program has several sequences, sophisticated control functions and fault logics, then this may call for increased memory. The requirements can be estimated based on the program rungs and data files. The specifications of the controller must also be studied, as some have tag-name based programming while others have fixed but expandable data tables.
The amount of memory consumed by programs and data tables are dependent on the controller model. A good assumption is that each discrete I/O device utilizes 5 – 100 words of memory, while analog I/O utilizes 25 – 500 words. The wide range may make estimation difficult for complex programs. A better approach would be to write some code blocks and study the memory usage.
There may be applications that need fast scan time, and the controller’s CPU speed and instruction execution speed and both detrimental factors with respect to this.
Almost half of the project is dependent on the quality of software programming, which in turn is dependent on the software provided by the manufacturer. The following considerations must be made while selecting a controller programming software:
Most controllers often include a free and easy to use programming software, containing round-about 20 instructions such as timers, coils, contacts, counters, etc. which are sufficient for small applications. But as the complexity of requirements increase, things may get problematic. Advanced controllers often include comprehensive programming software that incorporate a plethora of functions to assist programmers.
The choice of programming software is largely dependent on the user’s comfort zone, making it a subjective decision. Programmers may have their own opinion regarding software selection, but these are often over-ruled by higher management that enforces a standard controller programming software as well as methods.
Regardless, a controller shouldn’t be chosen if it doesn’t have ample literature detailing its programming software. Most manufacturers have already adapted to the trend of online resources, offering detailed documentations as well as creating forums where fellow programmers can exchange their queries. However, not all have boarded this train; so careful background checks should be made before making a PLC selection.
The cost of technical support must also be accounted for as there may be times when documentations may not help get through a particular problem. There are suppliers that offer limited time free services, which may be helpful if a timeline is followed regarding program development.
Once developed, the program must be thoroughly tested, and to do so, the software must be viewable in the form of a PID loop response and motion profile. This will allow simulation to be carried out to a full extent. Modern development software is incorporated with simulators that allow full-fledge testing to take place without eliciting the need to connect to the hardware.
Conclusively, you should refrain from adopting a one-size-fits all approach, whether its for software, hardware or communications. The controller selected must meet the automation requirements fully, while having room for advancement as the designs change.