Speaking in Tongues: Understanding the IEC 61131-3 Programming Languages
Long dismissed as just a European phenomenon, the IEC 61131-3 programmable-controller-language standard is gaining traction in the United States. Many controls engineers are familiar with one or a few of these languages, but not all. That makes it difficult for them to make the best choice for a given application based on programming-language characteristics. See diagrams.
Ted Thayer, Bosch Rexroth Electric Drives and Controls
Long dismissed as just a European phenomenon, the IEC61131-3 programmable-controller-language standard is gaining traction in the United States. Many controls engineers are familiar with one or a few of these languages, but not all. That makes it difficult for them to make the best choice for a given application based on programming-language characteristics.
Thanks to the International Electrotechnical Commission (IEC), five standard languages have emerged for programming both process and discrete controllers:
Ladder Diagram (LD)
Function Block Diagram (FBD)
Sequential Function Chart (SFC)
Instruction List (IL)
Structured Text (ST)
When should one be used over another? What are the benefits and disadvantages of each? For an in-depth look at each programming language with code examples, see the online version of this article on the Control Engineering Website at www.controleng.com via the January 2009 archive.
Choosing an Appropriate Language
With the different programming languages available, it’s important to consider a few factors before deciding which to use for your application. Of course, if you’re already familiar with a certain language, then the tendency may be to stick with what you know. However, consider the high-level benefits of each language, as detailed below, before making a decision:
Ease of maintenance by the final user: SFC;
Universal acceptance of language: LD;
Acceptance in Europe: IL or ST;
Speed of execution by the PLC: IL or ST;
Applications mainly using digital I/O and basic processing: LD or FBD;
Ease of changing code later: LD;
Ease of use by newer engineers: ST;
Ease of implementing complex mathematical operations: ST; and
Applications with repeating processes or processes requiring interlocks and concurrent operations: SFC.
Your PLC or PAC platform may also affect the choice of programming languages, as not all automation vendors provide programming software that is fully IEC61131-3 compatible. In fact, most of the non-European vendors do not offer this functionality, or only have a very limited spectrum of options, such as Ladder and SFC.
Another consideration is that not all PLCs are capable of running the various IEC languages due to lack of memory or processor speed. This tends to be the case with many micro PLCs.
While many programmers are locked into a customer specification, if they have the freedom to choose a hardware platform, they should decide which language or languages will work best for the application, then select the hardware and software that support it.
Ladder Diagram (LD or simply Ladder) is probably the most widely used controller programming language. Invented to replace hardwired relay-based control systems, Ladder programming is used in probably 95% of all applications. Visually, this language resembles a series of control circuits, with a series of inputs needing to be “made” or “true” in order to activate one or more outputs.
Ladder has experienced such widespread adoption that almost every programmer in any country or industry can read and write this language. Because it resembles the familiar electric circuit format, even a non-programmer with an electrical background can follow the program for purposes of troubleshooting a problem.
It’s also easy to start writing a program in Ladder. With just a basic outline of input and output signals, one can start churning out code. Most other IEC languages require more preparation, such as flowcharting of all potential process flows. Finally, most Ladder implementations allow a program to be organized into folders or subprograms that can be downloaded to the PLC, allowing easy program segmentation.
Ladder programming is ideal for simple material handling applications, for example, where a sensor detects the presence of a box, other sensors check for obstructions, and then an output fires an actuator to push the box to another conveyor. Digital inputs check for various conditions, and the program analyzes the inputs and fires digital outputs in response. There may be timers in the program, or some basic comparisons, or math, but there are no complex functions involved.
As the complexity of PLC functionality has grown, however, Ladder has been challenged to meet these advances and still maintain the paradigm of easy visualization and understanding. Functions, such as PID loops, trigonometry, and data analysis, now required in many control applications can be difficult to implement. Another challenge is that as program size grows, the ladder can become very difficult to read and interpret unless it’s extensively documented. Finally, implementing full processes in Ladder can be daunting– picture a ladder rung with an output used in several phases of a process with many input conditions attempting to control exactly when that output needs to turn on.
Function Block Diagram
Although Ladder may be the most widespread language, a survey conducted by Control Engineering magazine several months ago highlighted growth in the use of programming languages other than Ladder. Function Block Diagram (FBD) programming is an example. Even though the adoption rate for this language has recently slowed relative to other languages such as Structured Text, FBD is probably the second most widely used language.
In many ways, this graphical language resembles a wiring diagram even more so than Ladder code. With FBD, the blocks are “wired” together into a sequence that’s easy to follow. It uses the same instructions as Ladder, but visually is more understandable to a viewer who is not versed in relay logic. The major advantage is that programs written in FBD tend to be easy to follow– just follow the path!
FBD is ideal for simpler programs consisting of digital inputs, such as photoelectric sensors, and outputs such as valve manifolds, and could be used in any application where Ladder works well.
However, FBD is not ideal for large programs using special I/O and functions. The large amount of screen space required can quickly make a program unwieldy if it reaches any substantial size. Also, writing a program in FBD requires more upfront preparation to understand the program and how it will flow before any code is written, since it can be difficult to make corrections later.
Sequential Function Chart
Sequential Function Chart (SFC) programming resembles the computer flowcharts that many engineers remember drawing up in their college days. An initial step “action box” (the starting point of a flowchart) is followed by a series of transitions and additional action steps. The SFC concept is simple: an action box, with code inside written in any language of the programmer’s choice, is active until the transition step below it activates. The current action box is turned off, and the next one in the sequence is active. The transition step also has code to check that the necessary conditions are met to allow the program to advance to the next step. The language is very friendly to maintenance engineers because its visual nature and natural code segmentation makes it easy to troubleshoot.
On the downside, this style of programming is not suitable for every application, as the structure it forces on a program could add unneeded complexity. A large amount of time must be spent up front preparing and planning before any programming is attempted, or the charts can become unwieldy and difficult to follow. The overhead required for this type of program causes it to execute slower than the other languages.
A final consideration is the inability to convert to other languages. IL, FBD, ST and Ladder programs can easily be interconverted, allowing a piece of code to be displayed in the way most comfortable to the user. SFC, however, cannot be converted.
Instruction List programming (IL) consists of many lines of code, with each line representing exactly one operation. Thus, it is very step-by-step in layout and format, which makes the entry of a series of simple mathematical functions easy.
IL is a low-level language and, as such, will execute much faster than a graphical language, such as Ladder. IL is also much more compact and will consume less space in PLC memory. The simple one-line text entry method supported by this language also allows for very fast program entry– no mouse required, no tabs to click! In legacy systems, programs written in IL are easier to display and edit on a handheld programming unit, with no software or laptop required.
Despite IL’s advantages, it seems that maintenance and service engineers do not prefer it. This may be because it is less visual than Ladder, which may make it more difficult to interpret what the program is doing and what errors it is experiencing.
IL can make entering complex functions, such as PID loops and complex mathematical computations, a struggle. IL does not lend itself well to any form of structured programming, such as state programming or step ladder, further limiting its usefulness for implementing large programs. It is also arguable that the advantages of speed and compactness are less relevant, given the processing speeds of modern PLCs and the large amounts of memory available.
With its IF…THEN loops, CASE selectors, and lines ending in semicolons, Structured Text (ST) closely resembles a high-level computer programming language such as Pascal and C. The aforementioned Control Engineering survey indicated that of all the IEC61131-defined programming languages, ST has seen the greatest increase in adoption.
Among IEC languages, ST perhaps best embraces the growing complexity of PLC programming, such as the process control functions involved in plastics or chemical manufacturing. Trigonometry, calculus, and data analysis can be implemented far more easily than in Ladder or IL. Decision loops and pointers (variables used to do indirect addressing) allow for a more compact program implementation than can be achieved in Ladder. The flexible ST editor that is common in most programming packages makes it easy to insert comments throughout a program, and to use indents and line spacing to emphasize related sections of code. This makes the task of structuring a complex program easier.
ST text-based, non-graphical nature, which is similar to IL, also runs much faster than Ladder. An additional ST benefit is that it comes closer than most of the other languages in achieving the transferability goals of the IEC61131 standard, emancipating a programmer from the hardware platform.
A final benefit is that many students currently graduating from engineering studies have a better background in computer languages than in the basics of electrical wiring, and therefore can more easily become proficient in ST than Ladder programming.
A disadvantage is that, for many previously experienced programmers or maintenance and service personnel, the ST environment is unfamiliar. Writing the code and structure to make it maintenance-friendly can reduce some of its compactness advantages.
As a result, control engineers tend to use ST “behind the scenes.” For example, IEC 61131 allows a programmer to build his or her own functions in one language, then insert them as sub-programs in another language. With this option, programmers often encapsulate an ST program inside an instruction, which is then embedded in a Ladder program.
Why Use Software Verification?
As control-system application programs become ever more complex, maintaining software quality during initial development and subsequent maintenance becomes more difficult. In a white paper available for download from Control Engineering ’s online Resource Center, Paul Humphreys, a software engineer with LDRA Ltd. makes the case for extensive testing of control software, and explains the procedures world-class embedded control software developers use to ensure error free applications. Download the white paper.
For more information:
Ted Thayer is automation systems product manager at Bosch Rexroth Electric Drives and Controls. Contact him at firstname.lastname@example.org .
|Search the online Automation Integrator Guide|
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.