Learning IEC 61131-3 Programming Languages

A system integrator asks our readers about receiving education on object-based programming.

By Control Design Staff

1 of 4 < 1 | 2 | 3 | 4 View on one page

As a long-time integrator, I've become a reliable source of help for most PLC-based ladder logic systems. But it's clear that I need to supplement this with object-based programming skills around the IEC 61131-3 standard languages. Is function block reusability, which is supposed to make my life easier, its biggest benefit? What's the learning curve like to become good at it?

— From November '12 Control Design


Worth the Effort
Function block reusability based on the use of IEC 61131 is a significant advantage. It allows you to easily encapsulate work from one project and use it in future projects, providing significant time savings.

Another advantage of IEC 61131 is the support of multiple programming languages, including ladder logic, structured text and sequential function charts. Each language has its strengths, and we find that "power programmers" will often mix languages used within an application. Function blocks provide a powerful way to integrate these languages; for example, a communications function block can be developed in structured text, and then easily reused within a ladder logic program.

If you have already mastered ladder logic programming, adding function block development to your skill set will not take long. Probably the most important aspect of successful function block reuse is ensuring that proper documentation is in place. Adding new programming languages to your skill set will take longer, but can be well worth the effort in future programming efficiency.

Rich Harwell,
advanced solutions manager,

Multiple Benefits
IEC 61131 has many, many benefits. Code reusability is certainly one benefit, but not the only one. Portability between manufacturers is much easier, since all manufacturers use the same standard set of function blocks and code construction methods. In fact, you can now directly port code between many manufacturers.

The ability to use the right language for the right job is another benefit. For example, if I wanted to turn off 16 digital outputs all at once, this is rather repetitive in ladder logic because I would need to create each coil separately, attaching them on one side to the logic and on the other to the power rail. In structured text, we pull each output into a user-defined datatype called an "array," and now it's merely three lines of code to turn off these inputs:

FOR I:=1 TO 16 BY 1 DO

However, many who can write structured text are hesitant to do so because they are worried how their field technicians will handle the code. With IEC 61131, we can take this code and encase it into a function block that we write ourselves, and insert it into the ladder logic. And then we can lock the function block to prevent field technicians from modifying something we're not entirely certain they have the skills to work with.

Learning curves are always an issue. The good news is that since IEC 61131 is widely used by many manufacturers, training is portable across each manufacturer. Since the standard was developed by engineers, everything is relatively intuitive. The serious power and development tools provided by the standard more than make up for the curve involved.

Dan Fenton,
control & software product marketing,
Phoenix Contact

Change Your Thinking
The IEC 61131-3 standard strongly encouraged function block reuse from the beginning when it was first ratified in 1993. The upcoming third edition of IEC 61131-3 takes the reuse of code to the next level with object-oriented extensions.

In addition to function block reusability, it is also important to consider maintainability and robustness of the software. Can we make changes to working control systems without negatively affecting the overall system behavior? As an answer to this, object-oriented programming (OOP) has proven to be an incredible force in reuse and robustness over the past 20 years.

Take your smartphone, for example. Everything on your phone — every program, every application — is object-based. Smartphone users download and install applications without worrying about any negative side effects to how they make phone calls. The object-oriented nature of the interface protects the user from adversely affecting other functions. This is the essence of what we are working to implement in the control systems of today and the future.

As far as a learning curve, OOP is not difficult for most controls programmers; in fact, the "rules" are few and quite easy to learn. But applying OOP in an effective way is another story. For example, you can learn the rules of chess within minutes — and then spend a lifetime mastering the nuances of those rules and strategies to best succeed with them. To really harness the potential of OOP, we must change the way we think about programming. As automation professionals, we are used to thinking in a procedural way: Start at the top, go to the bottom, start over. With OOP, we start thinking about objects and how they interact with each other rather than thinking in terms of a procedure. We as engineers have trained ourselves to think procedurally and in a linear fashion; to remain competitive, this thinking must be changed to think of function blocks of isolated objects that interact with other objects. This interaction, the "interface" in IEC 61131-3 parlance, is key to successfully leveraging OOP.

1 of 4 < 1 | 2 | 3 | 4 View on one page
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.


  • <p>The "programming" language that you use should be determined by the nature of the process. The IEC 61131-3 standard contains 4 programming methods, and one system design method. The 4 methods of programming are: IL - instruction list, very much like assembly language, one instruction at a time; ST- structured text, a high-level language, a form of PASCAL much more forgiving than C++; LD- ladder diagrams; a formalization of relay ladder logic FBD - function block diagrams, compatible with the graphical configured block structure diagramming used in process control; </p> <p>and SFC - sequential function charts, a formalization of Petrinets, a method that is highly useful in the definition of sequences that contain both series and parallel elements. It was intended, as in Grafcet, that the full logical sequences and parallel elements be defined at a very high level BEFORE you start programming. Each block of SFC describes an operation with a criterion for completion. When each block is totally defined in SFC, then you program it in one of the other languages suitable for that operation; if the operation contains logical interlocks, then LD or ST are a good choice; if the operation contains computational elements, the FBD or maybe ST are a better choice. </p> <p>The writers of IEC 61131-3 were strongly influenced by the languages prevalent in the different countries represented by the members of the standards committee, but truly each language has its application niche. I want to point out that there is only one fully defined high level programming language in this standard - ST. As an old FORTRAN programmer myself, I would find the use of ST to be highly useful in practically all automation programming, but only after I had fully defined all of the interlocking, serial, and parallel sequences first in a SFC. </p> <p>In my course on the ISA Certified Automation Professional exam, I teach my students the importance of diagramming the states of a process before you start programming. I did this for FORTRAN programs and I cannot stress it more for ALL automation programs.</p> <p>A lot has been said about the reuse of Function Blocks (which are objects). If you use only one brand of DCS or PLC, then you can certainly reuse function blocks. Also, if your DCS/PLC supports Foundation Fieldbus, the function blocks defined by that standard can be reused. But if you are looking for reuse of function blocks across different PLCs, I think you are out of luck UNLESS those function blocks were written in the only fully defined programming language in IEC 61131-3 Structured Text.</p>


RSS feed for comments on this page | RSS feed for all comments