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

Answers

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,
Eaton

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
ARRAY_OUTPUTS[I] := FALSE;
END_FOR;

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.

Bob Trask,
PE, TwinCAT 3 product specialist,
Beckhoff Automation

Control Complexity
This is a great question, and one that many people have today. The IEC 61131-3 standard for programming languages was created to address the rising cost and complexity of PLC and PAC systems. Over the years, technology has enabled more data processing at the PAC level. Sometimes, this additional workload can increase system complexity.

One of the biggest benefits of the standard is being able to leverage multiple programming languages to address this complexity. Ladder code is a language that many people in the industry are familiar with today. Boolean logic is still addressed best using the ladder logic programming language. It is often the language that many maintenance personnel know the best.

The function block language is, in fact, reusable pieces of code, but it offers another major advantage — the ability to trace through the flow of math for a particular piece of code. Complex code can be difficult to follow and troubleshoot. Placing that code into function blocks can help address this by simplifying how this code is presented to those charged with designing and maintaining a system.

There are options today in many software applications to create a reusable piece of code called an add-on instruction (AOI). These instructions help a designer create modular code, available for reuse throughout the system, saving precious time and money in the design phase. For maintenance personnel, AOIs help decrease system complexity by allowing them to quickly locate relevant code for troubleshooting, rather than scrolling through rungs and rungs of ladder logic. For the most part, AOIs can be created in whatever language the designer prefers. AOIs can help standardize an OEM's machine or end user's system and make them more scalable.

To become competent in other programming languages, a good first step would be to explore how to solve a problem in the new language. For instance, if you have existing code for a tension regulator currently programmed in ladder logic, try to convert that into a function block diagram. Follow this up with testing the code in each language, comparing compactness, scan time and readability. This can provide a good understanding of the unique strengths and limitations of each language.

Another helpful tool can be the programming reference manual. Some software packages integrate a reference manual into the programming environment with a simple click of the F1 key, which can help you find how the instruction is best used in each programming language.

Introducing a new language is not always easy and often requires tailoring to the end user's needs. However, when the benefits of programming in a particular language are clearly explained, that language is more freely accepted. A demonstration of how the new language helps ease maintenance and improve uptime or productivity is the best route to gain acceptance.

Christopher Como,
product manager,
Rockwell Automation

Easier Transfers
Getting to know the IEC 61131-3 standard languages enables system integrators to select the optimum controls supplier, from both a technical and commercial standpoint, for a given application without having to go through the programming and commissioning learning curve that often occurs with a new supplier.

Because many PLC and motion suppliers support one or more IEC 61131-3 standard languages, system integrators who get to know these standards will have less of a learning curve when going to the next project with a different controls supplier.

Although the code itself cannot typically be transferred between different programming environments, if the supplier for a given application is changing the IEC 61131-3 functions — including timers, counters, conditional statements, motion control function blocks, etc. — used in the first supplier's control product, it will program the same way or very close to the same way in the replacement product, resulting in much quicker code writing.

Carroll Wontrop,
senior system engineer,
Kollmorgen

Not a Steep Curve
There are several ways that IEC 61131-3 languages can simplify your job. Each of the five main languages has distinct application-specific benefits. However, they can interface to support complex applications. For example, ladder diagram is ideal for discrete controllers. Structured text, which is very similar to C programming, is well-suited to algorithms based on complex calculations. However, the two can interface to share data. For example, if you write an algorithm in structured text, you can then get those results in ladder text for your discrete controller.

Automation tech suppliers have been at work, further expanding IEC language usability. For example, you can write an algorithm in structured text and put it into function block format. Of course, reusability is a huge benefit to integrators. Function blocks make it possible to create libraries of commonly used items for a line, or lines, of related machinery.

Having a basic set of blocks can also significantly reduce engineering and commissioning times. In addition to reusability, you get the means to protect intellectual property — users will see only what you want them to see.

The IEC learning curve isn't very steep, either, especially for the benefits you can get from it. If you already program PLCs, you've basically got it — it's merely the syntax of programming code.

Charlie Norz,
product manager — Wago-I/O-system
Wago

Function Block Benefits
According to many customers, being able to choose the best language to accomplish a particular task is the main reason people choose to use IEC 61131-3. As an example, many people find it much easier to use the structured text language to perform mathematical expressions or instruction list for direct device register access; and ladder diagram is of course the most commonly used and perceived to be the easiest to troubleshoot.

Of all the programming languages, function blocks probably provide programmers the most value. Whether you are an OEM, system integrator or end user, function block programming has allowed people to more easily reuse program content. Function blocks can contain other programming languages in the block. When there are several engineers working on a project, it's important that functions are implemented consistently. This speeds machine debugging time and simplifies troubleshooting. Our customers are agreeing with our recommendation to convert their programs to follow the IEC 61131-3 standards. They find the small learning curve is justified by improved time to market.

Another factor that is a growing concern of programmers is protecting intellectual property. Over the past decade, as manufacturing operations have become more global, customers have been looking for ways to protect the programs that give them a competitive advantage from unauthorized duplication. By using function blocks, companies can lock code contained in the block to protect their intellectual property.

Today's programming software and the controllers that run these sophisticated programs can go as far as keying the program to a particular controller for maximum protection against piracy. This allows U.S.-based companies that ship machines outside of the country to do so with confidence that the machines and source code will not be duplicated.

In summary, function blocks enable programmers to implement source code consistently. By reusing predefined function blocks, machines can be brought to market faster. Another benefit of a function block is its ability lock the code so it maintains a company's intellectual property.

Christopher McPhee,
senior project manager,
and Sloan Zupan,
senior product manager,
Mitsubishi Electric Automation

ALSO READ:  Use PLC programming, not custom code

Your Bottom Line
Your time is valuable, and being able to complete programming jobs faster can directly impact your bottom line. You are also most likely facing the need to provide the same or similar solutions repeatedly at different jobs. Therefore, being able to reuse previously developed code for new applications can lead to significant time savings and improved quality of code.

An object-based approach to programming using a "divide and conquer" approach looks at any application not as a single object, but rather as individual modules with clearly defined interfaces. It's just like putting together an object from individual pieces of Lego blocks — it looks like one piece once put together, but can be broken up and reassembled in many different ways.

Modular software works in the same way. Once individual objects have been identified, the implementation can be made as an individual program, or preferably a separate function block. Function blocks have the advantage of clear and clean encapsulation of their inner workings from all other function blocks and programs because only their interfaces are visible, while the internal code can easily be hidden from view, thus creating a "black box." This method can be very useful to also protect intellectual property when handing over applications because other users will not get nor need the source code of the function blocks.

Fixing bugs or adding features is also much easier with a modular approach using function blocks. The modification needs to be done only in a single place and will automatically be replicated to all instances of the function blocks used in the application program during the next download. Controlling different versions of function blocks can also be easily achieved by tying the programming tool into version control systems.

In addition, using the different languages of the IEC 61131-3 provides greater flexibility; for example, a complex control algorithm can be implemented in structured text as a function block, while the function block itself is still being used in ladder for easier troubleshooting of input and output signals. Lastly, individual function blocks or a library collection of them can be easily exported from one development project into another.

Another emerging trend in automation is to offer truly object-oriented programming in addition to object-based programming. Object orientation requires programming languages like C++ that can implement additional functionality like encapsulation, inheritance and polymorphism. Although those languages and principles have been common in PC software development for decades, their added complexity and required design and programming knowledge still limits their implementation in automation outside of application frameworks used by large machine builders.

Objects can be more than function blocks, though. An application module, for example, is an aggregation of function blocks and programs calling them and the necessary "glue code." This can be seen as the next step of modular software development. While a function block can contain the code for one specific function used on one or many parts of a machine, an application module now contains the code for an individual part of the machine.

Taking the time initially to think about a modular software architecture and using either an object-based or an object-oriented programming method to implement and maintain it will pay off quickly.

Robert Muehlfellner,
director of automation,
B&R Industrial Automation

OOP Ease
The main object-oriented programming (OOP) concepts include encapsulation, inheritance and polymorphism. IEC 61131-3 standards and tools encourage good software practices similar to that of OOP. However, the specifics of the OO mechanism are muted. The function block programming of the PLC uses the concept of encapsulation or information hiding (i.e., the idea that the specific data and operation of an independent operational unit is hidden from the caller). The idea of classes (containers specifying the attributes, operations and objects/instances of a class) are present in function block programming without the complexity of specifying the class structure.

One of the broad OOP goals is to develop reusable, maintainable code. Function block programming encourages this goal. The concepts of component-based software engineering (i.e., to build larger, reusable code modules from smaller objects) are also used in function block programming. In this regard, learning function block programming is very beneficial. Users have reusable blocks or "classes" that can be specified by dragging a block onto the pallet that will be instantiated at run time. Simple blocks can be created from structured text or ladder diagrams to encapsulate data and operation, and then be reused. Finally, the blocks can be aggregated into larger modules that perform sophisticated operations that can be validated and reused as part of a library.

The key concepts of inheritance and polymorphism are not present in the IEC 61131-3 specification. Inheritance allows child classes to reuse the code in the parent while adding new operations and attributes. Polymorphism permits a member (or operation) to operate differently depending on the context or the specialization of the child class. The lack of these OOP concepts negates much of the power of the OOP paradigm, but does keep the IEC 61131-3 language easy to use for those not familiar with OOP. If these concepts are desired or needed, some products permit C# (a fully object-oriented language) to be combined with function block programming so that the full power of OOP can be used.

If you are already familiar with ladder diagram programming and the operating system structure of a PLC, function block programming should have a very short learning curve. The use of encapsulation and instantiation is usually handled by the development environment and, without having to learn about inheritance or polymorphism, using function blocks to program should feel routine in a matter of days.

Joseph Profeta,
director product management,
Control System Group,
Aerotech