To read Jeremy Pollard's multiple-part saga on IEC 61131 and other related articles, visit our IEC 61131 resource page |
To be sure I wasnt being overly biased, I enlisted colleagues on the Automation List at
Control.com. The conformance criteria are so general, it is virtually meaningless, says Michael Griffin, an independent consultant, about compliancy.
A published PLCopen document reads: The overall requirements of IEC 61131-3 are not easy to fulfill. For that reason, the standard allows partial implementations in various aspects. This covers the number of supported languages, functions and function blocks. This leaves freedom at the supplier side, but a user should be well aware of it during his selection process. This doesnt help us much.
The original intent of the specification or standard was to create a common platform for control software development. When the industry emerged in the 70s, all software was written using dedicated hardware and firmware. With the advent of the personal computer, vendors developed their own development environments. It is no different today. The software programs that have been developed support only the vendors hardware. There is no common platform here. We are no further along than we were 20 years ago
Using RSLogix 5000 and Schneiders Unity is no different than when we used fixed programming terminals. You cant share programs, although PLCopen is trying to develop an XML transfer specification.
I anticipate that vendors will have import routines, but few, if any, will have export routines.
The spec does not cover off-the-scan issues and program-execution methods. Process behavior most likely will change on different hardware platforms since the software environment is different.
Some of the visualizations of the code are supposed to be close. If you look at ControlLogix5000, which Rockwell states is IEC 61131-compliant, and compare the visualization with that of KW Software, for instance, there wont be much similarity.
Tag-based programming is a plus, but even in the 1980s many products had the ability to use symbols. With IEC 61131, you have to use symbols, but the length of the tag names is variable. You cant use a 40-character symbol with a product that supports only 20.
To me, IEC 61131 is similar to SQL, UNIX or C. Theyre standard products to some degree, but theyre not called standards. The varying flavors dont interoperate, as some compilers, before the world went Microsoft, had very different syntax and ways to do things.
One Automation List contributor who wanted to remain anonymous says, Siemens currently sells two different PLC product lines, the S7-300/400 and the S7-200. Both supposedly support IEC 61131-3, but let's compare them to two non-1131 PLCs: Siemens S5 and Koyo DL series. The S7-300/400 and the S7-200 both use I,Q, and M as part of their memory addressing. However, if you compare overall features, you find that the S7-300/400 resembles the S5 more closely than it does the S7-200. The S7-200 resembles the Koyo DL series more closely than it does the S7-300/400. So why do two IEC 61131-3-compliant PLCs from the same manufacturer each more closely resemble two different non-1131 PLCs than they do each other? Given the above, what does being IEC 61131-3-compliant offer me?
And Julien Chouinard, managing director of ICS TriplexISaGRAF, calls IEC 61131 a compromise.
IEC 61131 has fallen short of expectations, but that doesnt mean there are no benefits to the specification. My final installment of this report will examine actual potential benefits.