Well, maybe not Python, but how do you define a higher-level language? Is it based on how much the programmer is isolated from the actual code? Is it about a more-powerful control capability? There's little consensus on what a higher-level language is for more complex applications for discrete/machine control. Is it C#, C++ and scripting? Are there others in serious play? What can they do that 61131 languages, for example, can't? Does most automation supplier programming software use higher-level languages for some purposes?

Data acquisition can serve many purposes. From machine diagnostics to exporting to an ERP system, the use of data is varied. What are your customers using it for?

Read our story Machine Data Acquisition Capabilities Grow.

I have written about IEC for 4 issues. I would like to share a thread from the Automation Control List as an exclamation point to my columns!!

The user is programming in Step 7 (Siemens) . The names have been removed. Be sure to read the very last line. I have always said that IEC 61131 is a great concept, but I don't try to sell it as a silver bullet for automation programming.

I am trying to export a POU but Export function is grayed out. I have tried to right-click on my MAIN (%OB1) block and select Export, but it is grayed out and I cannot figure out what i am doing wrong. I am trying to do this in IEC-1131 mode. Thanks!
Reply to this post...

--------------------------------------------------------------------------------

IMPORT and EXPORT only work in SIMATIC Mode, Why do you want to use it?

--------------------------------------------------------------------------------

I was hoping to port the logic over to another IEC program editor and reuse the code. It would be a lot easier than retyping the code from scratch.
--------------------------------------------------------------------------------

You can export the logic over as a text file in stl code and then maybe you can import that into your other application.
--------------------------------------------------------------------------------

IEC is a standard, but it's not that standard. :(
The export only exports in a proprietary format anyway.

We recently posted a case history written by Paolo Catterina of EUROelectronics (Die Is Cast for FPGA Control), an Italian company that delved into using FPGA-based controller technology to handle a particularly demanding control app for position and speed of an hydraulic cylinder on a diecasting machine.

I liked this article because it's an example of a company that realized its tried-and-true, and overall quite satisfactory, PLC control scheme just couldn't cut it for the speed and precision they needed, so it had to think very differently.

I won't regurgitate the whole story line, but the decision to use FPGA technology revolved largely on the relationship they'd established over the years with National Instruments in Italy.

That's all well and good when you indeed have a good relationship with a vendor and can genuinely explore whether that vendor's flagship product really is right for you.

I wondered out loud if that's the only way to get a group of basically conservative machine control professionals to put on pioneer hats and charge out ahead on their own.

Recall that a favorite machine builder definition of "pioneer" is "those guys out there on the prairie, lying face up with arrows in their chests."

So, lacking that tight relationship that EUROelectronics has, what would it take for you to head out in the unknown to try a new technology that you think might give you a competitive advantage?

Read our April 2008 articles, "Die Is Cast for FPGA Control" by Paolo Caterina and "FPGA Can Speed Development."
Do you use FPGA-based controllers? Take our Web poll.

Well, another successful event - good job guys. Man, the lunch line moves fast, eh!!

In a nutshell, my impressions were positive as a user. As always, the booths were well manned, questions answered, and a there was a good collection of third-party people from whom you could find out about stuff that Rockwell doesn't do - like load cell interfacing and the like.

Not to bore you with details, it is obvious that the Logix platform is their focus - in hardware AND software. Be sure to get your migration path in order.

Their service of migrating other vendors users (Modicon, Siemens, etc) to the Logix platform is very cool. I ran into old friend Joe Vidmar (not that you're old, Joe:)) who explained the service to me. Users might like it - vendors wont!!

Factory Talk--and this is my own observation--is the enterprise platform for RA. ALL software components will conform to FT. ALL users conform as well.

RSLogix 7.3 is the last Everlock run-time-protected version (diskette stuff) - version 8.0 will use FT activation, which uses the web. You MUST have a certain level of FT installed as well..

What this does for the complete software suite is to 'Microsoft' it. Many customer dollars will be spent on licensing and getting current - because you will have to.

Better talk to your guys about this - the budget surprise could be huge!!

I talked to an industrial electrician friend of mine who was there for the first time, and he was intimidated by the newest technology. One has to wonder why. I consider him to be one of the brightest light bulbs on the ceiling.

Once FT becomes entrenched, it may look very different that what it is right now.. but I suspect not. RA changed the support structure a few years back, and now will go after the FT upgrade path.

Again only my observations. What were your thoughts on the fair? Any tech sesions that were good? And make no mistake - we will pay the money to stay with Rockwell. In many eyes, it is the best solution out there. There were almost as many registred attendees to the AF than there was at the ISA show in Houston. wow eh!!

On October 2nd at 2PM at ISA Expo, Jeremy Pollard, columnist for Control Design, and system integrator will be chairing a panel discussion on IEC-61131. Joining him will be:

Dick Morley - Modicon founder, and consummate pontificator
Bill Lydon - Managing Director of PLCopen
Julien Chouinard - Managing Director, ICSTriplex IsaGraf

The topic will be dynamic - IEC-61131 is a non-standard ..
Morley thinks standards are an 'embargo on innovation'
PLCopen supports the standard and the community
Chouinard's company, recently bought by Rockwell and a developer of IEC-61131 products

Being IEC-61131 compliant doesnt bring anything to the table for the user. Its just another programming environment to him. There will be lots to talk about. Come and join the discussion. Come and join the fun.

If this is a subject you're interested in but can't attend, post a comment here and tell us what you think of the standard, and what you'd like to know more about it. Jeremy will include it in the session and report back.

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.