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.
advanced solutions manager,
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
ARRAY_OUTPUTS[I] := FALSE;
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.
control & software product marketing,
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.