By Jeremy Pollard, CET
As I wrap up my dissection of IEC 61131, you may want to catch up on the plot thus far by reading the previous columns that led us here. The saga is available online at ControlDesign.com/iec61131.
Now, make no mistake about 61131. We still are in the same environment we were in before its creation. Rockwell, Schneider, Siemens, GE and Wago all have their own programming environments. The business of automation wont allow for real interoperability of these competing products.
The main difference from 20 years ago is that there is some form of commonality. There are some good reasons to use an IEC 61131-based product.
Tag names permit abstraction of the hardware I/O, so databases from product to product could be maintained externally. All will use tag names based variable allocation and typically the common elements, such as Boolean, will behave the same. That doesnt mean, however, that all vendors support all the common elements.
Most products will have all five languages. A large benefit of an IEC 61131 integrated-development environment (IDE) is access to the function block part of the software. The power in function block programming is tremendous. This is the type of programming the older DCS products had 20 years ago. You can program a very complex part of the application and have it hidden behind a block. Some argue that this improves troubleshooting capabilities.
In return, it requires a better programming skill, as well as a good handle on the project scope and project management. This is foreign territory to many ladder programmers.
A selling feature of the standard is the ability to develop control strategies in the right language. While I agree with this, the plant floor maintenance staff usually doesnt include a structured text guru. This is scary for the controls engineer who develops the application, so oftentimes hell just use ladder logic. One of the major benefits is left untapped as a result.
Proponents of IEC 61131 swear by its training and investment benefits. If you use Company As IEC 61131, and later you have to use Company Bs IEC 61131, you already know how to program the hardware. This is not necessarily so, but there is some truth to it.
Many companies use a development package from 3S. Some use a product from Softing, and others create their own. If an OEM used IEC software from four different hardware vendors and they all licensed their software from one company, the OEM stands a better chance of being able to migrate the learning curve to the new hardware and of being able to reuse the software.
Will the training cycle be shorter? Probably. But from vendor to vendor, there is some level of commonality that can be borrowed, but the impact may be limited.
Will IEC 61131 help the maintenance person trying to solve a problem at 3:00 A.M.? For most user companies that standardize on a single hardware platform, the answer is no. Theyll get used to whatever the software tool is. IEC 61131 isnt important.
It might be important to you if you leave your company and have IEC 61131 on your resume. It surely cant hurt.
If you are a machine builder or a manufacturer with multiple vendors that all use IEC 61131, maybe it helps. There are some inherent similarities that could help getting re-familiarized with a hardware platform or a software troubleshooting tool, but I think this is a personal function rather than a software tool function.
No doubt IEC 61131 is here to stay. Early misunderstandings of the benefits and the resulting misconceptions of what an IEC 61131-based product actually was turned off a lot of potential users.
Open is as open does. IEC 61131 is the same. It is simply a platform for a software product design tool for hardware. It provides some benefits for the OEM and the user, but mainly the vendors benefit, in my perception.
It is no panacea. It can help in our quest for a better automation platform, but we will leave that for IEC 61499, a true standard. As long as we dont screw it up.
