Language barriers: Is ladder logic all you need?

Since there continues to be a large installed base of PLCs that have been programmed using ladder logic, this well-accepted software remains a staple in the industry. Ladder logic definitely has time on its side. But there's a feeling within the industry that limiting PLC programming software language to only ladder logic could be counterproductive in some applications. It’s useful to examine both ladder logic and the other programming languages defined by the IEC, as well as their benefits.

By Stephen L. Arnold, Schneider Electric October 17, 2007

“If it ain’t broke, don’t fix it.” That’s the opinion of many programmable logic controller (PLC) programmers in the industry who have known nothing but legacy proprietary ladder logic languages. Since there continues to be a large installed base of PLCs that have been programmed using ladder logic, this well-accepted software remains a staple in the industry. Ladder logic definitely has time on its side. There is, however, a feeling within the industry that limiting PLC programming software language to only ladder logic could be counterproductive in some applications.

The International Electrotechnical Commission (IEC) — a sister organization of the International Standardization Organization (ISO) — created the IEC 61131 standard for PLCs out of the belief that an open systems approach was needed to facilitate the design and implementation of large systems, particularly those using hardware from multiple manufacturers. Specifically, IEC 61131-3 was developed in response to what was perceived as the absence of a suitable standard to define the way PLCs could be programmed. IEC 61131-3 defines three graphical and two textual PLC programming software standards, one of which includes ladder logic.
It’s useful to examine both ladder logic and the other programming languages defined by the IEC, and their benefits.
Ladder logic shows its age
By far the most popular of many different programming languages, ladder logic, either a proprietary legacy language or the open IEC version, is most beneficial for simple, straightforward programs that aren’t heavy in math or require unique coding structures.
Ladder logic also has a number of weaknesses. For example, in legacy versions, ladder logic symbols and functions can vary among software from different suppliers. End users who stay with one hardware and software supplier won’t see this as an issue. But if they decide to use hardware and software from another supplier — or they hire people who are trained in a different language — it can become a significant training challenge.
Both the legacy and IEC versions of ladder logic also have limited functionality for reusing code. If the code structure is standardized and logically laid out, it can be reused with a simple cut-and-paste function. However, if that’s not the case — for example if some parameters are located in another section of the code — it’s possible to miss vital parts of the code structure. This can increase code debug time and possibly commissioning time as well.
Ladder logic has poor functionality for addressing and manipulating data structures, particularly in the legacy versions. Also, the complex sequences of these structures are difficult to create and debug. In addition, complex arithmetic functions are difficult to write because the programming language doesn’t easily support this functionality. Some functions were added as development progressed over the years, but the difficulties remain.
To experienced programmers, these issues may seem superficial. However, less-experienced programmers could consider some of these issues as showstoppers.
New horizon of software
The other IEC 61131-3 compliant programming languages are seen as an answer to the perceived shortcomings of ladder logic. They are well-structured with top-down and bottom-up program development. The standard also requires strong data typing so programming errors caused by a programmer erroneously attempting to write the wrong type of data to a variable are drastically reduced.
The other IEC 61131-3 programming languages support full execution control because they allow different parts of a program to be executed at different times, at different rates and in parallel. Complex sequential behavior also can easily be programmed using a concise graphical language. This allows a sequence to be described in terms of steps, their actions and the transitions between those steps. In addition, defined data structures allow associated data elements to be passed among different parts of a program as if they were a single entity. This allows the passage of complex information as a single variable, which improves program readability and ensures associated data are accessed correctly.
Other IEC 61131-3 languages defined
The remaining two graphical and two text-based languages defined by IEC 61131-3 allow for flexible language selection so program designers can choose the language that is most suitable to solve a given part of an application program.
Structured Text is a high-level text-based language that encourages structured programming. The language structure, or syntax, strongly resembles PASCAL, a popular programming language from Borland. Structured text also supports a wide range of standard functions and operators, making it an excellent solution for highly complex algorithms or math functions.
Function Block Diagram is a graphical language that clearly depicts signal and data flow through function blocks. It’s useful for expressing the interconnection of control system algorithms and logic as well as math. Function blocks are part of a control program, packaged so they can be reused in different parts of either the same program or in a different program or project. Function blocks can provide software solutions for small problems, such as creating a pulse timer, or provide the control for a major portion of a plant or machinery, such as a reactor vessel. A valuable feature of function block diagram is the ability to nest function blocks up to several levels, which allows a high-level view of a plant or process. It also allows the end user to drill down into the function block when greater detail of the process is needed for troubleshooting or other functions.
Instruction List is a low level assembler-like textual language based on similar instruction list languages found in a wide range of today’s PLCs. This language has been used in many nano and micro-level PLCs. The greatest benefit of instruction list language is that it requires less memory for a given application than solutions created in the other IEC 61131-3 languages.
Sequential Function Chart is a graphical language that’s often used to depict the sequential behavior of a control system. It easily defines time and event-driven control sequences. Sequential function chart is an effective graphical language for expressing the high-level sequential parts of a control program, as well as programming low-level sequences.
Real-world value of IEC 61131-3 languages
What is the value of these other IEC 61131-3 software programming languages for system integrators, OEMs and end users? First, while system integrators tend to focus on the same kinds of projects, each one is still different from the next. For example, a system integrator that concentrates on water/wastewater applications will have to create programming for lift stations in every project. The concept of lift stations is basically the same in every application, but the number of pumps and their associated hardware changes in each one. It’s possible to reuse the logic with a basic ladder logic PLC software program by performing cut and paste operations from one program to the next. However it’s essential that the system integrator capture all of the code. This includes code for the interlocks, alarms and other functionality that may not be located in the same area of the program. If the integrator misses any portion of the required code, it will lengthen the testing, debugging and commissioning time for the application.
Using structured text or function block diagram languages can greatly simplify the process of reusing code. For example, the system integrator could create a series of Derived Function Blocks (DFBs) that describe the various functions in a lift station, including pump and valve, alarm and sensor DFBs. These DFBs will be created and debugged once and always will be correct. Having the ability to reuse code immediately reduces the amount of time required to test, debug and commission an application.
In the previously described example, a system integrator also could create a DFB that contains one instance of the sensor DFB, one instance of the alarm DFB and four instances of the pump DFB. The result is one DFB that completely defines and controls the lift station and greatly simplifies the time required to create the control code. Reducing the amount of time spent on programming, testing, debugging and commissioning is of major value to a system integrator because it helps them be more competitive in the bidding process.
Having IEC 61131-3 compatible hardware and software also makes it easy to write or convert programming for hardware that’s from a different manufacturer.
Although OEMs don’t always build the same exact machines over and over, they too can benefit from reusing code and using a language other than ladder logic. For example, OEMs can create a library of special DFBs that are unique to their applications, thereby making the creation of even custom applications simpler and faster and saving on testing and field commissioning time.
End users also will find the other IEC 61131-3 programming languages valuable because it makes troubleshooting easier. An end user trying to troubleshoot a problem with a water/wastewater lift station can go online with the PLC, go directly to the DFB for that station in the code, open it, observe the animation and discover quickly where the problem lies. For example, the end user could see that the signal to start a pump is present, but that the pump isn’t running. If a maintenance team is dispatched, they will know what equipment to take with them and where to start. In a standard ladder logic program, this process would take significantly longer to complete because the end user would have to look for clues in several locations throughout the program instead of working in one nested function block. The other IEC compliant languages provide reduced downtime through faster, more accurate diagnostics and the ability to know what equipment is required before a repair is started. It also gives end users the ability to more easily change hardware or software suppliers since the code is portable.
System integrators, OEMs and end users looking to reuse programming code, reduce debugging and commissioning time, improve troubleshooting capabilities and have code portability may find a non-ladder logic IEC 61131-3 programming language beneficial.
Stephen L. Arnold is senior product specialist at Schneider Electric.