As machine complexity grows, many engineers are moving beyond a one-language-fits-all approach to PLC programming. The sweet spot seems to be a combination of IEC 61331-3 programming languages to best suit the application and the end user.
Combined programming languages
“Data handling is influenced by user preference,” says Tim Hider, industry marketing manager for smart manufacturing and digital solutions at Mitsubishi Electric. “Structured text (ST) is generally favored for mathematical operations and complex data manipulation. However, many PLCs with legacy support include custom functions that enable efficient handling of 16-bit data using ladder diagram (LD). Block moves and FIFO tables make LD a viable option for straightforward data handling. Additionally, some manufacturers offer the ability to embed ST code inline within LD rungs, combining the power of ST with the readability and troubleshooting ease of LD.”
Beyond ladder logic: addressing security and flexibility
While LD may still dominate PLC code, more controls engineers are finding reasons, such as security issues, to incorporate other languages. “In some cases, we want to use structured text, but we want to have a function block that is locked down with a password that no one can get in because the end user has intellectual property (IP) that they really don't want anyone with a thumb drive stealing,” says Thomas Kuckhoff, senior product manager at Omron, who also points to the automotive industry’s use of LD and sequential function chart (SFC) as an example of multi-language programming. “Not only is their automation getting more complex and integrated more into enterprise resource planning (ERP) systems, but also there is a huge amount of flexibility that the line is expected to do, whether it's internal combustion and plug-in hybrid or just an electric vehicle,” he adds. This means when maintenance tries to assess a machine issue, it’s complicated because it was, for example, working fine on the last shift while making a different drive train.
“That’s where we’re seeing ladder logic pop up a little bit,” Kuckhoff says. “We’re seeing these chunks of the program displayed in a much more visual format, so a maintenance person could better monitor how a machine is running through its steps, not by monitoring all the rungs of logic, but looking at it from a flow chart type of situation. That’s allowed teams to get to that root cause much more quickly.”
SFC provides a visual flow chart of machine function that can allow someone who didn’t write the code to work through the steps and figure out where the program is hung up.
Strategic language selection for diverse applications
Hoat Phung, senior application engineer at ABB, says he has machine builder customers that use three or four languages. They might use ST for a mathematics model for calculating flow, whereas that type of coding is a little more cumbersome in LD. “It’s a smoother, quicker execution using structured text, but once they get into the motor control, the structured text becomes more cumbersome,” Phung says. “A ladder diagram or a function block diagram represents the control of the system. It makes it easier.”
Sequential function charts can be used to control the sequence of the operation, and, as the name suggests, SFC is specifically designed for that Phung says. Using multiple languages can be a way to keep programming compact. “Each language has advantages, depending on what you want to use,” he adds.
Readability vs. scalability
Ladder-logic programming is often championed for its readability, but text-based languages are often more flexible and easier to scale. “The simplest answer of making it all ladder logic often results in excessively verbose programs that are just as hard to read as another language, if not harder,” says Patrick Smith, senior project engineer at DMC, a CSIA-certified system integrator. LD is inherently more cumbersome to scale. “Tools for generating ladder code are often less flexible and harder to use than text-based tools,” he adds.
One suggestion he has for multi-language programming is writing more testable code. “Then, you can write code in something like structured text, test it and use it in your program, knowing it is less likely to need to be debugged,” Smith says. This can be harder to do with typical controls programs, but tools like function blocks and analog input/output (AIO) modules can help keep code small and self-contained.
Function blocks: modular, reusable code
The function block is a core concept in the IEC 61131-3 standard and used in multiple languages, namely FBD and ST. A function block is essentially a chunk of PLC programming logic. It’s modular and reusable, and it encapsulates a specific function. Function blocks are useful for time-based or sequential operations because they remember values between the scans.
A user-defined function block (UDFB) can be constructed in the language of choice, explains Aaron Dahlen, applications engineer at DigiKey. “Then stitch them together in the top-level program using ladder logic,” he says.
Encapsulating code into function blocks enables scaling with reusable code. “Such function blocks may have an outward representation intended for FBD but contain flexible ST code inside,” says Imran Mohamed, motion control application engineer at Yaskawa America. “The use of modular function blocks can also assist with the protection of intellectual property. This is very important for OEMs and system integrators who want to safeguard their proprietary algorithms or trade secrets from scrutiny by the end users or other competitors. My approach is to use ladder diagram or sequential function chart for high-level machine control and state machines, where readability and clarity are essential. For reusable and scalable logic, I prefer using structured text or function blocks. This balanced approach has consistently worked well for me and my customers, ensuring the system remains accessible to technicians while also being robust, scalable and efficient for developers.”
Get your subscription to Control Design’s daily newsletter.
Standardization and the evolution of programming practices
Standardization is often about maintainability, and customers choose a specific programming language to maintain interoperability and ensure compliance with existing machines. “This standardization enables them to customize and reuse function blocks across different projects or machine types, continues Mohamed. “For example, some customers develop dedicated servo-axis-control function blocks that encapsulate all necessary control logic and parameter monitoring logic for the servo axis ensuring uniform look and feel that they can reuse across their entire machine lineup,” Mohamed says.
Blended approach: graphical and text-based languages
Sara McGhee, product owner of Simatic AX at Siemens, says its customers also use a mix of languages. “In the United States, you’re going to see some kind of ladder or a graphical representation of language at least somewhere in the program,” she says. “That’s really important to customers to be able to have that visibility.”
However, she is seeing more customers gravitate toward text-based languages. “What we see globally, there’s more adoption of text-based languages for PLC programming overall,” she adds.
The next generation is also leaning into more text-based languages, she says, driven by the rise of computer engineers in the market. And the advances of software programming are beginning to influence the automation space. “While text-based languages aren’t new, they’re more widely accepted in the automation space,” McGhee says.
In general, designers look toward text-based languages for programs that have more complexity. “You can get something up and running really quickly with graphical languages,” says McGhee. “But, as your systems get more complex, it may take a lot longer to figure out how to do something in a graphical language and do it in a way that makes sense.” More complex operations with data intake or manipulation are often easier with text-based languages.
Libraries and quality standards
With machine builders, Siemens has many discussions around why text-based languages might work in some situations but not others, McGhee says. “That’s why the blend is really key,” she explains. “Maybe you have a library centered around text-based language or structured text, where you’re doing those data operations. Then you’re able to pull that library in some function block into the rest of your program that is maybe more of a graphical representation. At a lower level, at certain points, it might be structured text, but from a high level, those engineers that service the machines have the ability to see what’s going on.”
Claudia Dürr, global marketing manager at Siemens, seconds this strategy at Siemens for combining programming languages. “It is common to use a mixed-language strategy: Combine ladder diagram or function block diagram for the straightforward, or frequently troubleshoot logic—interlocks, alarms, simple sequences—with structured text for complex processing, data handling or algorithms. This leverages the high readability of graphical languages where needed and the scalability/reusability advantages of ST where beneficial,” she says.
Text-based languages can provide a lot of flexibility and power, but it comes with some added responsibility, McGhee says. “Now with the adoption of more text-based languages and software principles, you see more and more people adopting some of the quality standards that they have in place, and there’s a lot of testing that goes into software development that we don’t see as much in the forefront of the automation space.”
For automation, this means adopting that test mentality, for example, in terms of library development, McGhee says. “If you’re developing that library block, ideally, you’re testing it,” she explains. “You’re checking the quality of that before ever inputting that in the program.”
If something goes wrong in the library block, then the service person would have to go into the library. “Then, they’re in the text language, and then they don’t know how to debug it because it’s not as easy to understand as a graphical language.”
