A Control Design reader writes: We’ve been programming our programmable logic controllers (PLCs) with ladder as far back as I can remember. But we’re having trouble finding new blood. We’re also considering a control-system overhaul, so perhaps now is the time to shift to a PC-based control architecture. We’ve heard that younger programmers are more comfortable with these languages. And I keep hearing about low-code/no-code. Is that even worth looking into? If we stick with programmable controllers, are there resources available for training new employees on ladder or other IEC 61131 languages?
Answers
Write programming to reveal issues
A PC-based control architecture is simply not hardened enough for industrial use, and the I/O connectivity is not there. Routinely our projects consist of thousands of valves with each valve having up to three outputs and four inputs for control; hundreds of variable-frequency drives with dozens of real values; flowmeters, pressure sensors, level sensors; 15,000 I/O points is not unheard of for our needs. Response to inputs needs to be as close to immediate as possible; going through any sort of PC-based operating system will slow things down too much. Industrial processors are optimized for this level of connectivity and communications. Anything PC-based will not work, at least at this time.
As for programming languages, you must consider more than just the initial development needs. Downtime at these facilities is far too expensive to tolerate for any length of time. I once worked at an automotive plant where downtime was $100 per second, which meant that my annual salary at the time disappeared in less than 15 minutes. I cannot stress enough, programming needs to be written such that issues can be found quickly. Nothing does that better than ladder logic. At a glance, I can tell if an output is on or off, why it is on or off and what to do if something is wrong.
I have no insight into low-code/no-code. Ladder logic, however, is fairly easy to learn, especially for someone who already knows some other programming language. I think the biggest problem we have recruiting new blood is that some younger or less experienced people aren’t aware of what is required to bring the products we use to our homes. Industrial production is a complex operation requiring engineering services, and the culprit to that, I think, is the “no photography” policies that most companies have. If I can’t take a picture of what goes on inside of a plant—opening panels, pictures of SCADA systems, products going down the line—then how am I supposed to explain and share that knowledge to our youth? As it stands now, I have a hard enough time explaining to adults what “industrial automation” is.
Paul Ericksen / senior automation engineer / Gray Solutions
Your system could dictate your choice
There is obviously a growing problem of a retiring older workforce and the loss of knowledge and experience that goes with it. I keep hearing from companies that the younger generation of controls/electrical engineers have not been properly taught established programming languages like ladder logic, so much so that vendors seem to be offering more solutions that are based on structured text, scripting type languages or even low-code/no-code options.
This is great as an expansion of technology. I am not criticizing progress. Ladder logic is still dominant in factory machinery. It has gained much more versatility as vendors have added features. Built-in functions for proportional–integral–derivative (PID), motion and compute offer much greater control than the ladder logic of old. If that isn't enough, add-on instruction (AOI) programming is available in a few different languages to build the function needed. Ladder remains the base code though.
Ladder is the absolute best language for troubleshooting a machine that isn't working properly, especially for maintenance technicians that have varying degrees of programming knowledge. The real-time visualization of what needs to happen combined with what is happening is easy to follow and trace to the problem. This aspect of ladder logic should not be overlooked; in fact, it should be of high importance. It is definitely of high importance to the 2-AM maintenance tech that has to repair the machine.
Schools should be influenced to train to what is needed, rather than have industry change methods to match what is being trained. We are losing the knowledge of the older workforce way faster than we are replacing the older systems. The younger generation of engineers is going to have to deal with these systems, so education in these areas is absolutely necessary. The world, and the workforce, is what we make it.
Larry Stepniak / electrical engineer / Flint Group
The advantages of standard multi-language programming
In recent years, we have seen people and businesses alike transition to their own systems on a PC-based controlled architecture. However, within the first few critical obstacles, they quickly return to PLC-based equipment. This demonstrates that, while PC-based controllers are industrially sound, they are not specifically designed for continuous operation like a PLC-based control system.
These limited options make it harder for companies to rely on a single supplier to meet all of their equipment needs. Additionally, the lack of controller flexibility hinders companies in adapting to changing industry standards. This lack of flexibility often necessitates a hardware upgrade, which includes reteaching new programming languages, new design tools and much more. The total cost of frequently switching hardware to avoid obsolete equipment is often a deal breaker for most companies, leading them to less-effective alternatives like low-code/no-code solutions that cut corners and limit programming freedom.
Since the introduction of programmable controllers, many languages have been used to write programs for machines and processes, but none were regulated. The result of this lack of standardization is sporadic training for various equipment and the formation of brand-specific maintenance teams limited to certain manufacturers. This lack of programming regulation leads to companies losing valuable time and money.
However, to address this issue, the International Electrotechnical Commission (IEC) established a standard for several aspects of controllers, ranging from hardware characteristics and installation to tests, communication and programming. Specifically, the IEC 61131-3 standard specifies the main characteristics for controller programming. These features define the software model and cover the world's five most used languages:
- function block diagram (FBD)
- ladder diagram (LD)
- sequential function chart (SFC)
- structured text (ST)
- instruction list (IL).
This defined standard, known as the standard multi-language programming, directly benefits users by providing them with a universal language familiarity that allows companies to bypass equipment updates and the need to reteach new and updated languages. Furthermore, with the use of a defined standard, user ease is highlighted in modularizing and structuring the programming in functional elements/program organization units (POUs). This gives users the ability to define the language for specific areas of a project and provides reusable code with a functional block library, facilitating development and improving software quality.
By incorporating these programming standards into hardware, suppliers who implement their own libraries or drives will showcase the most out-of-each product while also improving feature experience and hardware performance for users.
With standard multi-language programming, individuals who take the time to learn this standard will have a basic understanding of the programming for various suppliers. This eliminates the need to reteach basic programming languages, allowing suppliers more opportunity to offer more customization and programming options to further benefit users.
Free videos are available to anyone interested in learning the new industry standard for streamlined programming, no matter the environment. Users receive free basic training to demonstrate how software works alongside standard multi-language programming and how it can be tailored to users and their many needs.
Leandro Profes / product director / Altus Sistemas de Automação
Safety vs. non-safety
Similar to what happened to the computer software industry, programming languages have evolved, and software engineers are rarely coding in FORTRAN or COBOL. They prefer to use instead languages such as Python, Java or C, whenever possible, if they are more suitable to accomplish the desired task.
IEC 61131-3:2013 specifies the syntax and semantics of a unified suite of programming languages for programmable controllers: “This suite consists of two textual languages, instruction list (IL) and structured text (ST), and of two graphical languages, ladder diagram (LD) and function block diagram (FBD).” The largest PLC manufacturers usually provide at least some of these languages in their products. My personal advice would be to program all the non-safety programs in ST and the safety programs in FBD.
Starting with the non-safety programs, when working with modern PLCs, I would avoid writing new code in IL. Continuing the analogy with computer software, programmers have not coded in assembly languages for a long time. In industrial automation, I find it difficult and impractical to troubleshoot and maintain IL code. In addition, in comparison with LD, ST code is more compact in the screen, which makes it easier to read; it is also better to work with their text-based files, when dealing with program transfer, edits or code generation via external scripts. ST is also future-oriented and scalable, and better-suited for mathematical formulas and calculations. Many leading device providers are embracing it and often supply examples of code written in this language.
Regarding the safety programs, some manufactures do not allow textual languages for this scope, so a graphical language must be used. The reason I believe FBD is a good choice is that it is easier to program and troubleshoot. Moreover, historically, some safety controllers were programmed in this language. My advice is to identify the safety functions of the application and then build the necessary FBD logic blocks for the safety I/Os and interlocks.
Many manufacturing sites are still running code on LD or IL. Refactoring a code written in one of these two languages and switch all at once to ST is probably not feasible. A possible solution is to refactor small parts of the code. In this way, the team can progressively get used to this new language and refactor the code base step by step. A good source of reference for ST programming is the book “PLC Controls with Structured Text (ST),” written by Tom Mejer Antonsen, in addition to the code examples in the PLC manuals.
Erik Cornelsen / automation engineer
Standardized configuration
The question you ask has been posed many times, pretty much since the first PC-based controllers became available in the 1990s. It recognized that PC-based control can offer an interesting value proposition in terms of the capabilities and flexibility that it offers compared to programmable logic controllers (PLCs) and programmable automation controllers (PACs). At the same time, the fundamental challenges relating to long-term support, lifetime limitations and operating-system dependency remain the same. It is worth taking into account the impact of these factors before you make your decision.
You pose the question on whether the familiarity of younger programmers might be motivation for a switch from traditional programmable controllers to a PC-based platform. The following are some factors I suggest you consider.
Have you considered the impact of your choice on the people that are involved with various stages in the lifecycle of the project? Whilst you may be able to find a computer-science graduate who is willing to work during the development phase of a project, will that same individual be willing to work in the middle of the night to diagnose a problem with a stopped machine? Will he or she be willing to travel to a remote location, in some cases for extended periods of time, to complete commissioning? What are the cost implications? A programmer with experience of C/C++ or Python may well cost more than someone familiar with the IEC 61131 languages—not least because their skills are in need in sectors other than industry. That said, there may be certain parts of an application where a user may wish to build and encapsulate functionality within a module such as function block. An example might be a specific algorithm that an engineer may wish to develop, test and protect. Here, one of the other programming languages may well be applied.
Assuming that the IEC 61131 languages are here to stay—and it can be argued that they present enough advantages to be around for a while—then it is the responsibility of those companies who build products using these languages to ensure the availability of training and resources to ensure that people are trained to use them. Looking at engagements between automation suppliers and technical colleges and universities, and training courses and material offered by the suppliers themselves suggests that they recognize this need and are continuing to support and develop young technicians and engineers who are entering the automation industry. Your observation that you are struggling to find new blood does suggest that these efforts need to be intensified.
At the same time, one aspect to consider though is the trend toward how people interact with control systems. In the past, setup and configuration was likely to be a physical process: if you wanted to set up a device, you might need to do so using physical switches on a device or by using a special configuration tool. Multiple devices might even have had their own configuration environment. Standards such as field device tool (FDT) device type manager (DTM) IEC 62453, however, have simplified the process. They have provided a standardized way to interact with devices from multiple vendors. They have also allowed configuration to be achieved through a software tool and facilitated interactions that might have historically required a programmer. Recently enhancements have facilitated the configuring and monitoring of devices and applications using mobile devices. This would suggest that the skill set required is application knowledge, rather than programming skills. At the same time, in the event that a problem does require the time of a graduate programmer, perhaps they might be more willing to solve a problem if they could complete the task from their tablet in the comfort of their homes—something that can be achieved with both secure remote access and selecting the right configuration tools at design time—rather than having to travel to a site at an antisocial time.
In summary: it is not a simple answer. PCs do have a role to play in industrial applications—but so do the traditional controllers—and a decision to move to the former from the latter should be taken only after paying attention to the whole lifecycle of a project and the people involved. Key to the process is identifying the workflows and stakeholders and then selecting the right tools to achieve your goals.
Dr. Vivek Hajarnavis
technology manager of common architecture & technology / Rockwell Automation
