Has the PLC Met Its Match?

For example, temperature and gas detection in a nitrogen-annealing oven might be important, while data about humidity or vibration may offer less or no benefit. Adding extra data makes systems more complex than needed. Thus, reducing that complexity becomes crucial, as it decreases the effort needed to program, troubleshoot, or adjust a process.

Next, the central processing unit of the controller, which acts more or less like the human brain, will process information from the sensors and make decisions based on algorithms and programs. If a value is outside a set limit, the controller will send a signal to an actuator to adjust the process until the error returns to an allowable tolerance. Actuators are like the muscles of the control system. They are the hands that operate modifications dictated by the controller onto the physical system. Common components for actuators are motors, drives, and pumps, but also include pinions, pulleys, and chains.

“The controller knows what is going on and it is able to make decisions accordingly. The king of controlling devices in industrial automation contexts is surely the PLC,” says Matteo Dariol, product support engineer for Bosch Rexroth. “The acronym contains ‘programmable logic’ because at the beginning of the electronic revolution (1960s-1970s), controlling devices where obtained with discrete electronic components in a fixed topology. Changing project specifications meant redesigning and reengineering the whole control logic, with physical components shuffled and moved around. With PLCs, the design efforts for the control algorithm are confined almost entirely into the software.”

Whereas PLCs are robust and their programming language standardized, their development environments still lack a defined standard—all major players offer their own unique solutions. Programming and troubleshooting a PLC can be easier than a personal computer (PC) that implements more complex or open-source software. PLCs are modular and able to plug into various setups according to the needs of each project: additional I/O ports, safety modules, and specific Ethernet-based communication cards are just some examples.

Modular design allows for expandability, which is one advantage of using a PLC. Other advantages include cost, simplicity, and robust design. When replacing older technology such as relays, another benefit emerges in the reduction of moving parts. Integrating a more complex system, such as a PC controller, can add other benefits, but one must also consider the added cost and training.

As a result, many production lines that already use PLCs will likely continue to work in the same manner for years to come. Familiarity and simplicity gives existing momentum that will carry the PLC for some time into the future. However, we are starting to see an evolution of the industrial computer. As production lines incorporate machine vision and more complex robotics, the controls are branching out.  

Limitations of the PLC

PLCs restrict memory, software, and peripheral capability when compared to a personal computer (PC). Motion control (e.g., automation and robotics) can have many inputs and outputs, requiring extra PLC control modules or outside electronics. However, a PC processes more data faster, which can reduce the physical size and better handle machine vision, motion control, and data flow. Additional data is increasingly important as more companies integrate lines and plants with the industrial Internet of Things (IIoT) into production lines and plants.

Original equipment manufacturers (OEMs) are able to maximize plant productivity by allowing machines to simultaneously perform multiple operations. Computationally intensive and/or time-critical processes running simultaneously might cause a PLC to become overloaded. To keep less time-critical tasks from affecting those with a deadline, machines can use multiple computing platforms. Typically, these incorporate one or more motion controllers, and one or more supervisory processors that support the operator interface for programming, machine operation, data collection, and maintenance functions. However, using multiple processors is costly. New software specifically targeted at PC platforms can help solve this problem, though.

Engineers are able to overcome some of these hurdles with a PC. But a PC is not as robust and can’t survive harsh industrial conditions like dust and extreme moisture. Using a PC with complex software, or more software options, can take longer for technicians to learn and thus increases training time. Advanced software may also need to have a programmer on-site for maintenance, troubleshooting, and upgrades. A PLC’s software may be basic, but having its time-tested standard languages can ensure longevity of a device despite its speed and linear nature. 

PLCs typically employ an industry-standardized set of programming languages (IEC 61131-3), including a “ladder diagram.” Electrical diagrams read similarly to ladder logic, reducing training time and simplifying maintenance, troubleshooting, need for a programmer, etc. Another language from the IEC standard is Structured Text, which looks and operates more like a “high level language.” However, the use of other non-standard high-level languages, such as C++ or Visual Basic, can be difficult with a PLC. Only recently have new software tools allowed users to talk to a PLC as if it was a normal PC.

A PLC sequential program scans all of the instructions every scan cycle. A scan cycle will take about 10 ms or more to complete. Only upon completion of all instructions within a deadline will the program move to the next scan. If a deadline isn’t met in a set time, it will cause an error and the program will stop. This hard-time software can limit the length of a program and any input signals to a frequency less than 100 Hz.

Cypress offered the following example in a white paper: If you want to read a speed sensor input to measure 1200 rotations per minute (1200/60 = 200-Hz signal frequency), a microcontroller-based PLC cannot measure the speed correctly using this input. Integrating a custom input module with a decoder or integrated-circuit counter to read the signals at high frequency and convert them into a count value to pass to the microcontroller might be necessary in some applications. Alternatively, consider controlling a flow-control solenoid value with a pulse-width-modulation (PWM) signal at 10-kHz frequency. A PLC needs a custom output module with PWM generators. Adding such high-speed counter modules and PWM generator modules increases the PLC cost two to threefold.

The Next Generation of PLC

A system called a programmable automation controller (PAC) is helping to mitigate some of the limitations of older PLCs. Some claim the name PAC is marketing, and that it is a more software-focused PLC, but there are differences (see “Terms and Definitions” below). Unfortunately, definitions vary, so finding a definitive line between the technologies might be difficult. PACs are similar to the PC solution, but more robust like the PLC. For example, an industrial PAC can handle temperature ranges from –40 to 158°F, 50-g shock, and 5-g vibration.

A PAC typically incorporates PLC functionality. Both are digital computers, but a PAC tends to expose advanced programming capabilities and often has greater functionality, peripheral capability, and memory. PACs offers more complex system architectures when there is a need for greater I/O connectivity. Furthermore, PACs usually have more built-in connectivity capabilities, from networking to logging data to a USB storage device, and often they can interact directly with databases.

Additional software options and features sounds beneficial, but you must define your goals. Be aware controllers may not follow standard languages (IEC 61131-3) that may cause training, in addition to the issues previously mentioned. “Typically PLCs are used more for “production line controllers” and PACs are more suitable for “plant controllers”” says Dariol

There are also different models of these new technologies. PACs, for example, can offer models that focus on machine vision or others that may focus on operating multiple processes at once. Selecting a technology or model must take into account any future considerations (e.g., expansions, upgrades) and standards (e.g., safety) that may alter what technology or model is needed. Planning could extend the life of the controller by meeting future requirements, but it might also help set up a foundation for the IIoT and decentralized, also called edge computing, control systems. 

PLCs still have a place, but with machine vision, motion control, and dynamic robotic processes, the desire for more data is increasing and older PLCs might lack the required processing power or memory. Decentralized technology can help expand a legacy line by offering products such as SoCs and FPGAs that provide processing and memory directly on the sensor. This means that adding a complex process to an existing line may not require an expensive PAC, but a group of smart sensors designed for the application.

Possibly Neither, or Both

Further confusing the PLC/PAC conversation is that it is possible to build a system without either one. A network of smart sensors and software can combine to eliminate, or perhaps more accurately scatter (decentralize), the programming controller across the plant floor. SoCs are one of the technologies that can decentralize a process. However, trying to put too many protocols onto a single SoC can increase the amount of verification cycles needed to validate a process or part—similar to overloading a PLC.

In addition, it is possible for the different technologies to work together. PLCs, decentralized technologies, and PACs can work in tandem for full plant control. Some basic step must be taken to find what technology or technologies a company may need.

“First, it is important to understand the factors critical to the success of an operation and the level of obsolescence risk that can be tolerated,” says Julie Robinson, Marketing Manager, Rockwell Automation. “Once the risk is determined, users should develop a strategy for mitigating and ultimately eliminating that risk, and plan the first work-cell upgrade. Factors that drive some of these changes include:

• Meeting future production demands or improving current production performance.

• Complying with the latest safety, security, and regulatory requirements.

• Increasing flexibility to allow for efficient equipment expansion or upgrade.

• Improving asset utilization by reducing downtime.

• Enhancing safety and security measures.

Next, users must understand what modifications have been made over the years that may not be in the latest drawings and wiring schematics.”

Accurate documentation of legacy equipment will help integrate new technology. If a decentralized platform is integrated, documentation becomes even more important. Decentralized controllers have shown to improve installation time of new equipment. Traditionally, technicians and engineers are able to plug into a centralized PLC to locate the problem, or upload and download programs as needed. If a system isn’t in place to communicate from a central location or port—even if it is a virtual center—troubleshooting, upgrades, or changes may increase time and cost associated with these processes. A good system design must consider ease of maintenance, servicing, and scalability.

To make sure technicians don’t have to physically walk around to connect to a decentralized system in order to troubleshoot a problem, service companies try to connect multiple systems so that technologies can work seamlessly together. Oftentimes, this means facilitating old systems with new technology and software.

“There is little return on investment in replacing hardware that is working,” says Erik Dellinger, Kepware’s Manager for the IoT. “These decisions should be made when designing the system. In the design phase, we have noticed there isn’t always one company that has everything you need. Systems are often made up of hardware and software from multiple companies that need to work together toward a common goal.”

To select the optimal technology to fit your application, it is important to understand what technology is available, will meet your current and future goals, and offer needed features without adding unnecessary complexity. It may be difficult for a company to have an expert to answer each of these concerns, and might be why service-provider companies are becoming a trend in the PLC and IIoT industries.   

Terms and Definitions

The difference between PLCs and PACs can leak into many other technologies. For example, systems on a chip (SoCs), embedded PCs, and field-programmable gate arrays (FPGAs) represent some of technology that is replacing or expanding the PLC industry. However, it seems the definitions of these technologies are not set in stone. Bosch Rexroth’s Matteo Dariol defines the following:

PLC: A programmable logic controller is a digital computer designed for automation and industrial controls. It was created to resist to a wide range of operating conditions, including temperature, pressure, electrical noises, and vibrations. The most important feature that truly led to its success is that it is a hard real-time system.

Real-time: Most times, real-time is translated into being “as fast as possible.” This is not true. A real-time system guarantees that all inputs, outputs, and computations process within a specific time constrain, often referred to as a deadline. A hard real-time system considers missing a deadline to be a total failure. A soft real-time system, on the other hand, accepts missing some deadlines even if it degrades the output quality. Some examples include audio and video streaming, VoIP, and video conferencing. The quality may be lacking if the audio and video aren’t able to process a few frames during a conference call, but the message still comes across. This example could be similar for machine vision; a hard deadline may not necessarily be a total failure. 

Every time that a PLC program compiles, it calculates if the needed resources are available to perform all of the operations that we are commanding. Then it comes up with a solution for meeting our desired deadline.

PAC: A programmable automation controller is a digital computer that incorporates PLC functionalities. A PAC is a relatively recent innovation, being introduced around 2000. In the majority of cases, the PAC represents an evolution of the PLC. PLCs are a bridge from electric automation, made with cables and relays, to electromechanical programmable automation, where the emphasis moved into the software side of the operation (we are talking about 40 years ago).

SoftPLC: This is a soft real-time system, whereby (as specified before) it does not give guarantees on timely execution of operations. For this reason, they do not work for motion-control tasks. Instead, SoftPLCs are preferred for plant/shop-floor connectivity, for human-to-machine interface (HMIs), and supervisory control and data acquisition (SCADA) applications. It is possible for certain PACs to be SoftPLCs.

Embedded PC: An embedded PC is a non-general-purpose computer, designed and optimized for a single custom application. It is typically built with all of the components on a single board, including microcontrollers or microprocessors, memory, bus, I/O, and other custom chips. The system even includes the software or firmware (firmware usually resides in read-only memory, or ROM). Embedded PCs are truly the intersection between hardware and software, as a tight relationship exists between the two parts: one could not work without the other. Designing with embedded PCs can answer hard or soft real-time needs.

Looking for parts? Go to SourceESB.