Slow going for IEC-61131

I BELIEVE in PLCopen and in its IEC-61131 language base. I think you should too, but only after you get to know it well. Things sometimes are not as they appear.

Some of you might know that I recently resigned as North American managing director for PLCopen. I held the post for six years, but it was time to pass the baton to another seasoned controls veteran so I could continue with my own initiatives.

I believe in PLCopen and its IEC-61131 language base. I think you should too, but only after you get to know it well. Things sometimes are not as they appear.

The Europeans—the originators of PLCopen—embrace standards, use technology for technology’s sake, and are relatively quick to adopt. It seems, to me anyway, that North Americans do not. I think this is the main reason that the IEC-61131 standard has been so long in gaining traction in North America.

Misunderstandings about the standard used to drive me crazy. In 1993, I ran a panel discussion on alternate programming environments and IEC-61131. The audience thought I had three heads.

Things have improved, but as recently as October, 2005, about 60% of the audience at a presentation I made on IEC-61131 weren’t very familiar with the notion of a universal programming language.

IEC-61131 was created by people and companies with expertise in different areas. Ladder Logic was required by the North American representatives, while Instruction List was required by the German representatives. The standard applies to instruction sets, program organizational units, data types, and the software model.

It doesn’t apply to execution, display presentation, and “how-to” methods. In fact, IEC-61131 allows extensions to the standard, which creates incompatibilities between vendor offerings.

The big promise of IEC-61131 was the ability to have software written so that when you changed the hardware, you could use the same software. This promise isn’t met by the standard, although PLCopen is working towards a portability level of compliance, which will address certain areas of the software.

As PLCopen states, you can’t have compliant software unless it’s tested to be compliant. You say it might not be important to you, but be sure where you’re going before accepting untested software.

IEC-61131 consists of five different languages and graphical representations. A good programmer can create control strategies in different languages that provide good control. However, the majority of people I know using IEC-based products, are doing Ladder Logic. They’re using IEC-based software products to replace the proprietary software we used years ago. The control software you create with Product A can’t be used by Product B. It seems nothing has changed.

Consequently, you rightly ask: where are the benefits? Maybe it’s not in the standard at all. Modicon and Allen-Bradley users knew that each PLC had a timer and counters and math blocks, etc. It’s no different with IEC products.

The most intrinsic value is the presentation environment. Most integrated development environments (IDEs) look and feel much the same. Tag-based allocation to hardware and variables are common to all programming functions. The tedium of past I/O addressing schemes is gone.

The ability to password protect allows developers to lock certain routines away, so the apple cart can’t be upset by an untrained maintenance person. Some IDEs support dynamic linking to C++ compiled libraries. That’s very cool.

Once you use an IEC-61131 IDE, and move to another one, you’ll find the transition pretty painless. The troubles are in the extensions that vendors put in the IDEs and the basic functionality of the software to support their hardware. These potential roadblocks can be a source of frustration to newcomers.

Don’t expect the experience to be like, for example, RSLogix, which is a mature product that uses its own rules. IEC-based IDEs must adhere to some semblance of order for their own good.