By
Jeremy Pollard, CET, Columnist
A while back, I wrote a series for this column on IEC 61131—what it is, what it isn’t and what the inherent and valuable benefits are that the programming “standard” can bring to an organization.
I’ve maintained all along that I don’t believe it is a standard as much as a guideline for vendor product development. It is a container for up to five programming languages that can be used in any application, providing the vendor supports them, and providing, of course, the target hardware also supports the resulting code.
I recently had a spirited phone conversation with Corey McAtee, product manager at Beckhoff Automation. “Jeremy, we agree with what you’ve said—no fundamental differences,” is how we started. And then came the dreaded “but.”
“But we would like to try to clarify a few things.”
I have been on a soapbox about how vendors in general talk about their software being complaint with the standard as a marketing gimmick. Corey previously had asked me, “How does writing code relate to being compliant?” That’s what supporting a standard in programming is or should be all about, according to many vendors.
Corey said IEC 61131 is a programming standard, not an integrated development environment standard. I found it interesting that a vendor mentioned that. Part of the reason for developing IEC 61131 was to present a standard visual component—a common look and feel. Rockwell Automation and Beckhoff look nothing alike—finally someone from the vendor community is talking my language.
We talked about how IEC really only defines resources and tasks from an under-the-hood point of view. The efforts of the XML export specification from PLCopen, the association that supports the IEC 61131 spec and for which I was managing director in North America, were commendable. If the resources and task parameters can be exported, then time might be saved for the customer when he changes platforms and doesn’t have to reinvent.
We agreed that the potential of five languages is a real positive, regardless of whether it was a standard. While structured text presently is the only real portable language, not everyone has the same format. As Corey said, “Each vendor defines its own version of IEC.”
Beckhoff has prided itself in extending the standard, allowable per the IEC document, to give the user a better experience for its hardware products. “We can even open competitive code in our editor,” he explained. Beckhoff’s TwinCat product can reduce development time, Corey said, by using more-efficient mouse actions and functions. These are not IEC functions, but they’re needed for the hardware.
But Corey pounded the table about the languages. “The promise of IEC should be promoted through the languages,” he said. I couldn’t agree more. That there are five different languages is a good thing, but they don’t have to be the same from everyone. A function block is a function block, for sure. But the implementation of that block and the execution of the block is purely at the whim of the vendor and the system designer.
“IEC 61131 is an engineering tool, not a marketing tool,” he argued. “It’s a software design education issue. A user should not be concerned with what’s inside anyway.”
This, I thought, is a company that gets it. “We provide the five IEC-defined languages” would be a good marketing slogan, instead of touting IEC compliance.
“Our added functionality and reusability of code within the Beckhoff environment is time-saving,” he claimed. I haven’t played with TwinCat, but the telling part of this statement is “within the Beckhoff environment.” The PLCopen website had a statement in its text stating, “High level of reusability reduces costs and increases confidence in planning.” In that statement, a “within a single environment” qualifier would mean the world to the reader.
I was pleased with the dialogue Corey and I had. He wasn’t trying to pin me to the wall and, in fact, agreed with a lot of what I had said. He just wanted to clarify some of the nuances—in the comments I had made—from Beckhoff’s viewpoint.
The words describing a function or a method are as important as the method or function itself.
