Beckhoff USA
Figure 1: Standardizing on an automation platform with flexible programming options helps companies draw from a larger engineering talent pool and pick the most fitting language for each application.

What’s the best programming language and infrastructure for control?

Nov. 29, 2022
More flexible languages and hardware can deliver the best application-specific options

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

PLC languages move to plug-and-produce programming

Ladder logic has been around since the beginning of PLCs—think, 1960s. More than 20 years ago, the PLC world embraced IEC 61131, which provided five languages available in a PLC application: ladder diagram (LD), function block (FB), structured text (ST), instruction list (IL) and sequential function chart (SFC). While many embraced FB—myself included, as I feel it’s easier—many users never made the transition away from LD.

Today many people are looking at IEC 61499 to be the next-generation platform. The goal of IEC 61499 is threefold:

  1. provide users with a platform that can adhere to universal automation and smart devices at the edge
  2. create plug-and-produce programming objects—think, no code or drag and drop
  3. create a platform capable of integrating directly into the enterprise-type software—manufacturing execution system (MES) or enterprise resource planning (ERP).

By utilizing this plug-and-produce coding style that is similar to other technologies that junior staff may be more familiar with, this will help companies find new talent and bring them up to speed faster. 

Louis Arone / manager, U.S. system architect team / Schneider Electric

Object-oriented and text-based programming

Programming has become a core skill in our education system and is being taught as early as elementary school now. The languages used are more likely to expose students to concepts of object-oriented programming and text-based programming than of relay logic.

This is causing a shift in the capabilities of those entering the workforce, as noted. There are multiple positives with this shift. One benefit is that the more advanced capabilities of the full IEC 61131-3 standard, and particularly structured text, support object-oriented programming extremely well. Another is that, as the complexity of machines grows, these languages scale much more efficiently than ladder logic and technologies of the past.

Since the IEC 61131 standard has reasonable adoption levels, there are a number of great resources for programmers to learn from. There are a few books that address the topic of programming in these languages independently of the chosen platform. There are also training programs offered by vendors who sell systems using these languages; some of them are even available online for free. Since the implementation of the IEC 61131 languages is uniform, employers can also be confident that the skills will be useful across platforms.

Fortunately, PC-based control systems bring together the best of both worlds of programming—automation and IT. This means that you can have a multi-specialty team that can program in traditional IEC 61131 languages at the same time as projects are developed in an engineering environment integrated with Microsoft Visual Studio.

In the past, engineers chose the programming language for machines based on the limited options available. Now, we choose based on what best suits the application (Figure 1). Standardizing on an engineering and runtime platform that allows you to program using the wide range of methodologies used in industrial automation—from ladder logic and structured text through to C, C++ and even Python—will futureproof your systems and continue to attract a skilled workforce tomorrow.

Casey Taylor / software product manager / Beckhoff USA

Cast a vision for future engineers

More important than ladder versus general programming languages, the biggest factor for a candidate is whether they see a future for themselves in the role. Candidates want a role that gives them future opportunity. That could be the opportunity to grow their skills by learning emerging technologies and languages, grow their careers by offering access to other desirable roles or even grow via upward mobility in an organization. If you want to attract new talent, you need to be able to cast a vision for their future.

Computer science and software engineering academics typically focus on topics that are not prevalent in manufacturing automation, and courses on PLC programming are often put in an engineering-technology or even a technician-certificate track. Unfortunately, this creates the negative perception that machine automation and PLC programming are quite antiquated, which is an incorrect perception that we somehow have to correct.

This is certainly something to change by partnering with universities to build labs into engineering and even business disciplines to demonstrate how the cutting-edge nature of automation is driving digitalization.

While that university investment is a long-term investment, I think a solution to the immediate situation is to emphasize the candidate's potential role in digital transformation and the Industrial Internet of Things (IIoT). IIoT is driving the convergence of information technology (IT) and operational technology (OT) and opening automation to edge/fog/cloud computing, meaning the line between automation programmers and software engineers is blurring considerably.

IIoT is the bridge between factory-floor automation and the more current software trends related to digital transformation. Increasing IIoT capabilities not only attracts new talent, but it also drives the capability of your business. IIoT is a growing technology; it is a highly transferrable skill set; and individuals who understand the data flow are primed to take on roles that help make decisions using that data.

Also, don't miss the opportunity to develop individuals that are already in your company. Maintenance technicians often have a highly intimate understanding of a machine, and, if given the opportunity to learn PLC programming, they can be invaluable to your organization. Some of the best engineers I have ever worked with have developed through this method because someone believed in them and gave them an opportunity.

Ladder programming has such staying power because it is the simplest solution for many machine-programming tasks. Bit-level logic is easily visualized and programmed in ladder logic. A quick glance at a ladder rung makes the logic feeding an output bit very apparent. Higher-level programming languages work well for elegant algorithms. State machines, complex math and data manipulation are more easily programmed in text-style languages.

More so than ladder, in my experience, I have found the concept of cyclical execution of PLC programs to be a harder concept to grasp for newer graduates. No matter what language is being used, being able to understand the PLC execution is foundational.

There is a misunderstanding about PC-based control. Today, a PLC is really an embedded PC—Windows, QNX, Linux—running PLC software. PC-based control systems are typically running the same software as a PLC, just in a more typical PC format that has additional operating-system features opened to the user. The decision to move to PC-based control should be driven by a decision to incorporate edge-level programming features or other types of custom user interfaces that can be written in general programming languages.

Low-code and no-code development is growing in popularity, but you will see more of that on the app and web-interface side of development. It is certainly a concept that is on the horizon, but I don't think it's ready for mainstream machine programming at this point in time.

Training is widely available for PLC programing. A big advantage of learning IEC 61131 is that you can program any PLC that is IEC-61131-compliant. There will be differences in the integrated development environment (IDE) from different automation manufacturers, but those can be easily learned.

If you want to attract new talent, cast a vision for them. Show the candidates how they can be a part of the future and bring digital transformation and IIoT technologies to your company. Give them opportunities to grow and bring new insight to your way of doing business.

Paul Anderson / technical manager / Omron Automation

IEC 61131-3 provides flexibility

When PLCs were first introduced, machines were controlled by relays wired together, resulting in the term "relay logic." PLCs offered an electronic version of relay logic, so providing a programming environment that mimicked relay wiring made sense. I remember a time or two running to inventory, grabbing a relay or two to latch a signal. Thankfully the days of fixing an incompatible signal with a relay are gone. Relays haven't controlled machines in a very long time. Why program like they are?

While there are a few tech schools that teach ladder to satisfy some local production facilities, most programmers coming out of colleges and technical schools are taught structured programming languages such as C/C++/C#, Java/JavaScript and Python. Each is slightly different in syntax—call it dialect—but they all have structured logic flow:

  • decision queries—if/then/else
  • loops—for/next or while/wend
  • assignments—let/set.

Some also offer object-oriented programming (OOP), which breaks code into objects or things. Someone who can program in Python can also program in C or Java; only how you type the if/then/else changes. But to go from a structured language to ladder logic, or relay logic, takes a lot of work and trial and error. Ask a graduate to write code for a start and stop button in Python, which should take about five seconds, and then ask for a ladder-solution, which could take about five hours.

Not all programming languages are suited for industrial machines. Some are more prone to code errors than others. Some are easier to debug than others.

Additionally, some programming styles or techniques are easier to debug than others. If your machine has a bug, it needs to be solved immediately and not necessarily by the original developer. I often ask our new hires, "It's Friday night at midnight, and the machine you helped program just stopped working and won't restart. You are on vacation. Can your coworker figure out what is wrong looking at your code in 10 minutes?"

Many manufacturers have standardized on IEC 61131-3 as the best choice for industrial controls.

IEC 61131-3 defines several industrial programming languages: structured text, function block, instruction list, flow chart—continuous or sequential—and, yes, even ladder. It even supports OOP.

If you want to move away from ladder slowly, you can do that. If your management insists on having the main machine loop in ladder because that's how it has been, you can do that. If you need part of the machine to counters/loops and complicated logic, you can do that. If your new hires can program faster in structured text, they can do that.

IEC 61131-3 does not define the hardware; you can find it on industrial personal computers (IPCs), programmable automation controllers (PACs) and PLCs. You can still choose the hardware based on your actual machine performance need.

Hardware and brand portability are huge benefits for machine builders that standardize on IEC 61131-3 languages, given supply-chain issues. Take your code, even ladder, from Brand A to Brand B without rewriting everything. Move from a PLC to a PAC or IPC; update the device.

If you want machine programmers that can bring your company forward quickly, use controllers that support IEC 61131-3. They will contribute faster with less training.

Scott Cunningham / product and application manager / KEB America

Ladder has its place

Ladder training resources: There are many options available for learning ladder, from tech schools and community colleges to online training courses. Resources that I have used include Udemy, MrPLC, MyPLCTraining and SolisPLC. There are also trainers that can be hired to come on-site, preferably for multiple students. Gary Pratt, who teaches CoDeSys-based ladder, is one that I have great respect for.

Higher-level languages (HLL): The question doesn’t mention HLLs specifically, but I assume this is behind the question about PC architecture. There is definitely a growing preference expressed by recent grads to use languages such as C++, Python and Node-Red. But the students I work with—I teach a class at a local engineering college—also enjoy learning ladder. It’s just another language to add to their toolkit of abilities.

What students don’t like is doing everything in ladder. Proportional-integral-derivative (PID) control, trig functions and multiple-choice decision-making can be a real challenge to code in ladder, while ladder offers nice diagnostic and troubleshooting capabilities.

I feel that more than a preference for HLL, new grads want to pick the best tool to accomplish the goal. Fortunately, there are a number of platforms that allow a programmer to code in both HLL and ladder.

For instance, a complex routine could be coded in C++ and “hidden” inside a ladder instruction—the best of both worlds. This code is written in the way a new grad likes, but it is easily diagnosed by a veteran ladder programmer.

IEC 61131: This is a form of ladder-logic programming that incorporates some of the benefits of HLLs, such as intuitive naming of variables and I/O, structured text program that resembles C and the ability to “make your own instructions” (Figure 2). This represents a great middle ground between ladder and HLL that is accessible to new grads and experienced ladder engineers.

Ted Thayer / principal product specialist – control / Phoenix Contact USA

Ladder logic still dominates

Controls engineers with quality programming skills continue to be in high demand and are extremely difficult to come by, and finding them becomes more difficult if travel is required. Companies need individuals with a combination of quality programming skills, hardware familiarity and sound troubleshooting experience.

As older staff retire, it becomes increasingly more difficult to fill voids at the rate needed, simply because companies need staff that can immediately perform. Instead of seeking engineers with industrial coding experience, consider engineers with programming skills in PC or embedded controller technology. They will require training in automation hardware and control schemes, but they’ll excel in machine software development. Seeking candidates with little or no ladder logic programming experience may be easier to find and be a much better fit for emerging PC-based technologies.

IPC-based solutions that use a CoDeSys Control SoftPLC runtime system provide an IEC 61131-3-compliant controller solution. Users have the freedom to utilize any and all of the available programming languages that include ladder diagram, sequential function chart, function block diagram, continuous flow chart (CFC) and structured text. The IEC 61131-3 languages empower the programmer to craft denser, less bulky code that is easier to read, reuse and troubleshoot.

Often ladder-diagram code is preferred for ease of troubleshooting and structured text for its concise power. IEC 61131-3 allows both to coexist if the programmer uses structured-text code wrapped in function blocks. The resulting function-block-diagram code is similar to modern ladder-diagram code, offering a great compromise of easy troubleshooting and concise, powerful coding.

I’ve conducted several voice-of-customer interviews with original equipment manufacturers (OEMs) the past few years at all the larger industrial tradeshows, and each time I ask what their preferred coding language is, by far, the majority choose ladder logic. I also find older controls and automation engineers prefer the use of ladder logic over other IEC-61131 code formats and feel this preference is passed on to new hires within.

However, when I speak to engineering students seeking a career in machine automation and controls, they express their interest in all the IEC language types, especially structured text.

Low-code and no-code technologies pave the way for fast code development and help non-programmers develop feature-rich solutions. The software tools require either little or no coding experience. A variety of low-code and no-code options help machine builders develop motion-capable solutions via automated code generation. Users can quickly realize a variety of solutions, including single-axis positioning to full packaging-machine motion, utilizing a graphical catalog, parameterization and industry-standard software tools. These tools help machines builders reduce development times through the use of professionally developed, tested and preconfigured software modules for implementing simple drive functions, such as speed control and positioning, to complex motion control functions, such as camming and robot control.

Software providers such as CoDeSys, a manufacturer of independent IEC-61131-3 automation software, provide training, user services, education services, online help, download and update services and comprehensive technical literature. In addition, most manufactures provide training content, often via YouTube, for their specific CoDeSys implementation and hardware configurations.

Rick Simer / technology manager machine automation / SEW Eurodrive 

About the Author

Anna Townshend | Managing Editor

Anna Townshend has been a writer and journalist for 20 years. Previously, she was the editor of Marina Dock Age and International Dredging Review, until she joined Endeavor Business Media in June 2020. She is the managing editor of Control Design and Plant Services.