IEC 61131 Creates Common Programming, but Not a Common Development Environment

April 6, 2009
A while back, Jeremy Pollard wrote a series of columns on IEC 61131. He’s maintained all along that IEC 61131 isn’t a standard as much as a guideline for vendor product development. It’s 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.

A while back, Jeremy Pollard wrote a series of columns on IEC 61131. He’s maintained all along that IEC 61131 isn’t a standard as much as a guideline for vendor product development. It’s 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.

Recently, his columns sparked comments from Corey McAtee, product manager at Beckhoff Automation. You can read Jeremy’s latest column about his conversation with Corey here, but here’s a taste.

Corey says IEC 61131 is a programming standard, not an integrated development environment standard. 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 Jeremy 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, explains Jeremy.

While Corey acknowledged that each vendor defines its own version of IEC, Beckhoff Automation 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 explains. Beckhoff Automation’s TwinCat product can reduce development time, says Corey, by using more-efficient mouse actions and functions. These are not IEC functions, but they’re needed for the hardware. “The promise of IEC should be promoted through the languages,” says Corey. And Jeremy agrees. The five languages 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.

Joe Ottenhof, Beckhoff’s Canadian regional manager, later joined the conversation and cited one of Hans Beckhoff’s guiding principles: Never do anything in hardware that you can do in software. “That single guiding principle says more about Beckhoff and how we approach the development of automation ‘products’  than anything else,” says Joe. “And it encompasses why we are committed to IEC 61131-3 and even more so now with IEC 61499. There is a revolution coming to the automation world, and it’s not going to involve more hardware from 1980s companies intent on lining their pockets with annual maintenance fees, fear tactics and yesterday’s answers for tomorrow’s problems.”

About the Author

Mike Bacidore | Editor in Chief

Mike Bacidore is chief editor of Control Design and has been an integral part of the Endeavor Business Media editorial team since 2007. Previously, he was editorial director at Hughes Communications and a portfolio manager of the human resources and labor law areas at Wolters Kluwer. Bacidore holds a BA from the University of Illinois and an MBA from Lake Forest Graduate School of Management. He is an award-winning columnist, earning multiple regional and national awards from the American Society of Business Publication Editors. He may be reached at [email protected]