By
Jeremy Pollard, CET, ColumnistI 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 Europeansthe originators of PLCopenembrace standards, use technology for technologys 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 werent 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 doesnt 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 isnt 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 cant have compliant software unless its tested to be compliant. You say it might not be important to you, but be sure where youre 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. Theyre using IEC-based software products to replace the proprietary software we used years ago. The control software you create with Product A cant be used by Product B. It seems nothing has changed.
Consequently, you rightly ask: where are the benefits? Maybe its not in the standard at all. Modicon and Allen-Bradley users knew that each PLC had a timer and counters and math blocks, etc. Its 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 cant be upset by an untrained maintenance person. Some IDEs support dynamic linking to C++ compiled libraries. Thats very cool.
Once you use an IEC-61131 IDE, and move to another one, youll 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.
Dont 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.