IEC-61131 is a ‘NON-Standard’

True, it is a 'standard', but for whom? Users?? I think not. While it allows for vendors to write 'compliant' products, who says they ARE compliant? No one. PLCopen (for which I was the managing director for 7 years) has tried to develop testing for compliance but who really cares? Compliancy is ONLY good for and needed by a community that requires portability between code. If not then its no different than the good ol' days of Modicon vs Allen-Bradley. Regardless of the benefits (if any for the user base), being IEC-compliant doesnt mean a damn thing. The PLC programming environment you use is there because of the hardware you use. Do you CARE that it IEC-61131 compliant? Would you switch hardware vendors to get IEC-61131 compliant software? Rant over :) Flak jacket on - ready for input.
Show Comments
Hide Comments

Join the discussion

We welcome your thoughtful comments.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

  • <p>The benefit for the user base is reduced cost of training and maintenance. When you're trying to get 100,000 widgets per shift out the back door, a maintenance technician who can troubleshoot vendor "A"'s code and then go and work on vendor "B"'s code is a significant financial advantage.</p>

    Reply

  • <p>Marc - while I agree that there are some benefits, the imlementations of the standard from Vendor A to Vendor B will be different enuff to allow the technician to be a 'deer in the headlights' based on the notion that they would not be using the software on a daily basis.</p> <p>I would also submit that the products that are out there typically do not come with the right tools to allow for effecient troubleshooting of the control code.</p>

    Reply

  • <p>I wholeheartedly agree that the end user (me) doesn't benefit or appreciate most of the benefits gained from IEC-61131 software. Most of the time it just doesn't help and many times it seems to get in the way. Give me a well coordinated environment like RSLogix for end user trouble-shooting.</p>

    Reply

  • <p>Hey Rod - I'hear' ya.. I think that most if not all environments focus on development and the troubleshooting is left behind. and the IDE's arent that great either. COmfort - give me comfort!!</p>

    Reply

  • <p>Jeremy,</p> <p>You know IEC us about the look-and-feel, so focussed to training, engineering, and operation and installation. Also, via the function block concepts it is focussed on reusability of code, especially in different projects. It gives you (especially if combined with SFC) a very structured approach to your software development process. Perhaps the issue in the US is more - is there a consistent software development philosophy within industrial automation. Perhaps IEC is not perfect - but show me something better - and if you mention ladder, you'd better recheck the functionality and requirements of modern software development processes.</p>

    Reply

  • <p>Eelco - and to all that are unfamiliar with Eelco, he is the managing director of PLCopen - the look and feel between the new version of Codesys is nothing like Unity, and RSLogix, and ... although the nomenclature maybe similar (such as data types, POU's, etc) The IEC platform is less diverse perhaps as a Modicon vs Allen Bradley arguement of years past, but at the same time not close enuff to be said to be similar. I will be writing a 3 part series on IEC. and I will present the reasons why I think that IEC is good, what its not, and why you should take it with a grain of salt. You and I have had many conversations about this Eelco. This is a PLCopen opportnuity - the standard is holding everyone back! Thanks for feedback my friend. There will be more I'm sure:)</p>

    Reply

  • <p>I remember when this thing was first promised. We were told that there would be "automation code foundries" where you would purchase standard code widgets and they could be used by any IEC 61131.3 PLC.</p> <p>The emperor has no clothes with IEC 61131.3. The vendor voting bloc at the IEC hijacked the whole process just like they did with the eight-headed hydra for the field bus.</p> <p>No way on earth a Siemens S7 expert can intuitively switch to ControlLogix and be ready to go. We've all programmed lots of different PLCs, but to be a master of Siemens and Rockwell Automation (POUs in RSLogix?), to name just two, isn't getting any easier every year (just carrying around all the right cables and having the right Vmware session on hand is hard enough).</p> <p>That's not to say the "standard" is totally flawed, there are good things in at least the attempt to group languages.</p> <p>RJ</p>

    Reply

  • <p>Ranjan - I couldnt agree more. While I was the Managing Director of PLCopen, I tried to take the focus away from the IEC spec, and got my hand slapped as such. Its all about the standard, thus the 'its not a stnadard' rant since you CANT do the things that a standard should allow you to do ..</p> <p>the good things are good things. The not-so-good things get in the way. Even the motion blocks are unique for each vendor because of the editor fileformats, and hardware (of course). But having the blocks is better than not having them?????</p> <p>The vendors STILL want your undivided attention.</p> <p>I was at Rockwells Automation Fair, ad Contrologix was front and center. the 'IEC--61131' moniker was not.</p> <p>Things that make you go 'ummmmmmmmmmm'</p>

    Reply

RSS feed for comments on this page | RSS feed for all comments