IEC 61131 Standardizes PLC Programming

According to PLCopen, its XML interchange standard provides an open, non-proprietary, software interface for the interchange of industrial and process control programs between controls, product life cycle management (PLM), machine and process simulation, CAD, documentation software, and other systems. Find out more, including documentation and schemas at www.control-xml.com

The group is also working on OPC UA, a standard designed to simplify the interface between controllers, control software, and business enterprise systems - sort of shop-floor to top-floor on steroids.

—K.L.

Based on a modular architecture compatible with any of five languages, the standard offers flexibility, reusability, and ease of use.

At the heart of every machine lies the controller. Whether the mechanism consists of one axis or 100, it requires a processor, memory, and instructions to be useful. Programming the control system consumes more non-recurring engineering hours almost any other task in machine building. In the early 90s, the International Electrotechnical Commission (IEC) began developing IEC 61131, a standard for programmable logic controllers that today consists of eight parts encompassing everything from hardware and test protocol to communications. In particular, IEC 61131-3 defines a modular PLC programming environment that promises flexibility, reusability, and vender-to-vendor interoperability. Let's take a closer look.

Not to be confused with fieldbus protocols like SERCOS, CANopen, or any of the many flavors of Ethernet, IEC 61131-3 is a programming standard. It begins at the system level and becomes steadily more granular, progressing to specific tasks and function blocks of code. At the start of a project, the programmer establishes a top-level configuration that specifies hardware components, characteristics, and capabilities. Each configuration encompasses a set of resources—so-called processing facilities - that can execute programs. Each resource encompasses a set of tasks that in turn include programs and/or function blocks. The task level controls program execution and supports triggers and scheduling.

The program level is where the action is. 61131-3 breaks programs into program organizational units (POUs) consisting of functions and function blocks that themselves comprise code in any of five supported languages: function block, instruction list, ladder logic, sequential flowchart, and structured text.

In addition to architecture, the standard defines key parameters of data types, and lets users define their own data types. Variables are classed as local to the POU unless they are explicitly defined as global.

As far as Bill Lydon, Director at PLCopen North America, is concerned, the switch to IEC 61131 is about more than language, it's about a fundamental design philosophy that is enabled by the standard. “There's a whole modular design methodology in the computer industry that has to do with how you break a problem into modular components,” he says. “You have to think about structure rather than just writing a program for your PLC to do something. That's one of the things I think we have to train people on.”

One Language Doesn't Fit All
Among the most important benefits of the standard is its flexibility. For a number of years, the most common language used in programming PLCs varied geographically, with ladder logic being most popular in the United States, for example, while function block found heavy use in Europe. This trend overlooked a key characteristic of programming languages, however - each has strong points and weak points. Structured text might be good for performing complex computational tasks, while ladder logic is ideal for basic machine operations. Using a single language to perform every action is inefficient, at best, and ineffective, at worst.

One of the big advantages of the IEC 61131-3 standard is that it not only supports five languages, but any or all of those five languages can be used interchangeably in a single program. “It allows the best of five different worlds as a way of attacking the problem," says Dan Throne, sales and marketing manager for the electric drives and controls division at Bosch Rexroth Corp. (Hoffman Estates, Illinois). "If you're doing a high-level computation where you’re calculating a cam profile or dynamic inertial compensation, it’s really nice to use structured text for the math, which looks a lot like Pascal. If you’re just trying to get an overall sequence of operation for the machine to work and you want to visualize that very easily, it’s easier if you can use a sequential function chart because the whole chart fits on one screen. You can do standard tasks like power on, power off in ladder logic, and then you can do all of your motion in function blocks." 

The IEC 61131 standard does not restrict converting from one language to another. It is important to note that implementations by particular vendors may not provide the ability to convert between languages, or may not convert bi-directionally. In other words, depending on the particular vendor implementation or third-party logic engine you’re using, you may be able to convert from ladder logic to structured text, but cannot back compile structured text to ladder logic.

Block Party
Function blocks constitute another huge advantage to of the standard. IEC 61131-3 includes a set of standard mathematical functions like SQRT, ABS, and COS. More important, it allows programmers to establish a library of common functions. Once a function block has been written, it can be used again and again, both in the same program and for different projects. As an added resource, users can turn to PLCopen.

An international consortium, PLCopen was formed, in part, to generate a library of basic, open-source, 61131-3-compatible function blocks. Member companies contribute input to help develop code to perform common tasks like wind/unwind operations, for example. If a manufacturer is working on kinematics for a 300-part-per-minute packaging machine, PLCopen may not be their best source, but it’s a way to save time they’d otherwise spend reinventing the wheel.

Don't Miss These Industry-Leading Events!

January 20-22, 2025
Orlando, FL

May 12-15, 2025
Detroit, MI

November 3-5, 2025
Houston, TX

Although the standard is built on a philosophy of interoperability, the function blocks lend themselves to product differentiation. Vendors and machine builders can write code and embed it in password-protected function blocks “If there’s a certain aspect of their machine they’ve patented or that they’ve developed for a specific customer who paid for a good part of it, then it makes a lot of sense to lock that function block to protect any intellectual property," says Throne.

Machine builders need a better way of managing controller programs. “By leveraging 61131-3, a library of function blocks can be created for commonly used functions and reused throughout various programs,” says Sloan Zupan, Controller & HMI Product Marketing Manager at Mitsubishi Electric Automation Inc. (Vernon Hills, Illinois). Structured text, as an example, is an excellent method of performing math functions. The structured text function can be stored in a block and used within a ladder program or in another function block. “There's a great deal of flexibility and programming efficiency that can be realized. The more program code can be reused the more profitable a machine builder can become.”

With proprietary code, changing PLC suppliers means writing new control software. For system integrators and OEMs, that can become a serious burden. IEC 61131 helps them speed development time and cut cost. “The reason IEC 61131 exists is portability,” says John Rinaldi, CEO of device manufacturer Real Time Automation Inc (RTA). “System integrators got tired of rewriting and testing their control logic every time they sold a machine because this guy wanted PLC A and the next guy wanted PLC B and the third guy wanted something else. The software was hard to reuse. They had to maintain all those different environments.”

Instead of putting in the nonrecurring engineering hours to develop an entirely new set of code, integrators working with 61131-3-compliant products can, in theory, transfer over large segments of the code they've already written. Reusable function blocks can be developed to perform tasks such as hardware configuration and tuning, automatic setup, adjusting cams on the fly, predictive maintenance and more. In this environment, the job of programming becomes largely simplified by drag-and-drop selection of function blocks, guided by software wizards that set datatypes, structures and attributes.

The standard provides big benefits even when implemented in stealth mode, says RTA Marketing Director Drew Baryenbruch. “Even though many of our customers don't know it's there, it’s a big timesaver for us to be able to quickly add a few function blocks to make a custom product without hard coding.”

So just how portable is the standard? "I get asked this question all the time," says Throne. He cites the recent example of converting the control software for a 4-axis gantry robot which used a IEC controller from another company. "I double-clicked on the original executable program, my software opened it up and there it was,” he says. At that point, much of the conversion was performed automatically. “The ladder logic came across perfectly. At the bottom were 13 faults and those were the 13 proprietary function blocks that the other supplier used to accomplish the application. Some of them were really simple functions like a timer or an counter function, so wasn't a big deal. All I had to do was a find and replace in each of those 13 instances with the appropriate function block either from PLCopen or something we've created. I would estimate that about 80% of the program came over instantly.”

That wasn't all, of course. He still had to convert I/O configuration and the tags that allow the PLC program to interface with the HMI, but it was still a fairly straightforward process.

Barriers To Acceptance
Despite the broad availability of 61131-3-compliant components, the standard has yet to achieve the kind of widespread uptake necessary for it to achieve its promise. One of the current barriers to broader adoption is the perception that customers will require extensive instruction to use 61131-compliant devices. Rinaldi describes a Minneapolis-based customer who considered, and ultimately elected not to go with, 61131. “They were afraid of the cost of training their customers on how to write control programs using this tool. One of the reasons that you go with 61131, though, is because it's an open standard - there's literature, there's documentation, there's training available.”

Once the standard is widely adopted, 61131-trained engineers will be the rule, not the exception. The problem is reaching that point. Companies already running systems with proprietary control logic from one vendor are reluctant to burden their engineers and technicians with learning and supporting multiple kinds of control programming on different platforms. “We thought when we started the product line that there would be a lot of people who would want to do their own programming," Rinaldi says. "What we found over the last two years is that they really would like to avoid it.”

For IEC 61131 to really take hold, the community of machine builders needs to try the process. Right now, the consensus seems to be that has not yet happened. "There’s great benefit to an end-user but the end-users aren't asking for it, so there’s very little incentive for a machine builder to invest the time and energy to rewrite their programs in an IEC format," says Zupan. “There’s such a large investment already in standard ladder programs that until machine builders are being pushed regularly by the end user community, we’re never going to see a transition to a more interoperable environment.”

As far as Throne is concerned, OEMs who don’t see the benefit of making the switch are doing themselves a disservice. “You're stunting your innovation. You won’t be able to move on to the next plateau, because in the software realm it's going much more toward PC-based and open architecture than it's ever going to be going backward toward proprietary environments.”