By Jeremy Pollard, CET
In December, I got wound up about misleading things some automation suppliers promote about IEC 61131 portability, as seen in answers to a recent reader question. You can catch up with my comments at www.ControlDesign.com/rage1.
Now I want to react to some of those answers given in Control Design's October Real Answers (www.ControlDesign.com/portability).
Some say portability is there, but they don't add that it's only viable with structured text. PLCopen defined an XML interface to permit the ability to transfer code from various languages. And not everyone uses the same syntax and format.
Another writes that his company's software can open a competitor's code and import. It's made to sound very easy, but there are a lot of qualifiers associated with this. I'll bet he can't do it with an RSLogix5000 data file, or even a KW software file. He uses the word "transportability."
Many talk about PLCopen motion function blocks, saying if you use them then all is good. But the portability issue remains. Semantics aside, the blocks are developed for each vendor. You cannot take a Beckhoff program and use it with B&R Automation hardware directly.
Even Ken Ryan, who teaches this stuff at the Alexandria Technical & Community College in Minnesota, and has the respect of most people in this business, talks about reusable code in a September/October 2010 Intech article, "Why Can't My Software Behave Like My Hardware?" He states that the resulting code would be transportable, but it is not reusable in the true sense.
Julien Chouinard from IsaGraf made me smile. His premise is, "Who cares if it's portable?" He's realistic and did not defend portability. You have to wonder if, in fact, he actually is on target. If you use a vendor's hardware platform, use its software. If you change platforms, then use the new vendor's software.
This is really where the portability issue comes into play. It is not about code; it's about resources. Modicon and Allen-Bradley in the old days used very different programming methods. Each had a captive audience. Although IEC 61131 levels the playing field a bit, it is only the portability of methods that allows users to be more comfortable with potential hardware horse changing.
Maybe we shouldn't care, as Chouinard suggests. We are in the same spot we were in 10 years ago. Buy hardware and buy that vendor's software. End of story.
And why are customers asking for IEC 61131 compliancy? I believe simply because it is a standard, and they think there are default benefits in a standard. They would be right. But I fear that the reasons that the general automation public have been given won't be challenged because most won't go find out what the standard really says.
One of the key platforms of the standard is the ability of any vendor to extend the standard in any way it wants, as long as it tells the user it has extended the standard and notifies PLCopen for certification purposes.
So, if Beckhoff adds functions that it needs for its servo systems, then it is an extension. That block cannot be used anywhere else because it is tied to the hardware.
The PLCopen motion control function blocks also are tied to the hardware. However, if you use those blocks and only those blocks, then you can recreate the motion control program and profile in another vendor's software. This is good because the control algorithms have been tested, and the end result should be the same regardless of the hardware.
Realize that once a vendor changes or adds stuff, it is no longer a standard—it is proprietary.
Tag-based addressing and the ability to program in five different languages (with basic instruction sets for each) in a common environment are very compelling.
The standard tries to address the "common look and feel" of any IEC 61131-compliant development environment, but in practice it is less than precise because you don't have to have a certain presentation to be compliant.
Jeremy Pollard has been writing about technology and software issues for many years. Publisher of The Software User Online, he has been involved in control system programming and training for more than 25 years.