Iec 1131

[rsdoran]

I get confused alot so I read everything I can find. This pdf file pertaining to S7 and IEC 61131-3 may be of interest:
http://www4.ad.siemens.de/dnl/zE3NDcxAAAA_8790932/norm_tbl.pdf

I think S7 Pro is the only version that gives any information on this stuff but I may be wrong.

I knew that S7-SCL and S7-Graph certifies to IEC 61131-3 and PLCopen base level but thought the others just covered enough to be in compliance but not certified, seems that pdf says different.

 

[JesperMP]

It looks to me that STEP7 STL covers a sub-set of of the commands in IEC1131 IL.
At the same time STEP7 STL have additional commands that IEC1131 doesnt have.

How Siemens can conclude from that, that STEP7 STL conforms to IEC1131 is a mystery to me. Their argument seems to be that you can achieve the same thing in STEP7 STL as you can in IEC1131 IL ("Different syntax, same functionality").

 

[JesperMP]

I post this just to let people know my personal conclusion:

It is not possible to use one or several IEC 1131-3 compliant programming softwares in order to write PLC code that can be used on several PLC platforms.

But that was what people was saying anyhow, only now I too will testify to this notion.

I come to this conclusion because of the following:
Only IL and ST code can be ported by means of simple cut-and-paste. This is very cumbersome, and does not achieve a 100 % rate of succes. Some code from one software will not pass the verifier in another software.
LD and FB are not possible to port by cut-and-paste. I think they are in the "must have" category, as they are very popular for writing code.

My final comment is a rant about why the socalled PLCopen society has gone through all this effort, only to come up with a specification for how a PLC should work. I see no particular achievement in this.
Why havent they defined a way to save the code in a common format ? Its like going 99% of the way, but just not getting to the final destination.
I think that all that has come from this, is that the requirement for IEC 1131-3 conformity is starting to pop up in contracts (for no other reason than that people like to specify stuff). And thats the real reason why all the major PLC manufacturers are stating IEC 1131-3 conformity (whether they do conform or not).

Bah ! Humbug !!

 

[rdrast]

Before you get all mad at 1131, think about what it DOES do.

It at least formalizes things that you should be knowledgable about, and a method of interacting with PLC systems that while not identical over all platforms, is at least similar.

It defines how several standard functions SHOULD behave when used. The represention of a particular timer may be different across platforms, but the functionality of the timer will be consistant.

It would be silly to actually mandate that all must be 100% in conformance with this specification, as then all PLC's would be identical, and manufacturers would start shutting their doors. Personally, I rather enjoy the automatic-casting between datatypes that Rockwell allows, even though it's not in strict compliance. I also hate the fact that with Step 7, not only is there no automatic casting, but in ladder, there is NO casting at all between datatypes at all.

Look on IEC 1131 as you might on RS-232. It is a guideline. It does lead to a lot of standardization, but leaves tremendous room for flexability too.

 

[JesperMP]

Look to the PC world where "C" and "C++" are standardized so that code can be ported between various sofware vendors platforms, and in some cases even hardware platforms.
This is a huge advantage, you have to admit that.

If it was possible to port code freely beteen PLC platforms then maybe the margin for profit would be smaller. But on the other hand maybe the market itself would be bigger.

The free development of software and hardware that does NOT comply to any standard also has its advantages.

IEC 1131-3 sit itself between two chairs.
It is only sort-of-a-standard.
Because: It is OK to implement only a sub-set. And it seems to OK to also have extra non-IEC instructions ("super-set" ?).

Mad ? Nooo !
Like we say around here "Son, I am not mad at you, only disappointed".

 

[rdrast]

Well, yes, C and C++, are very portable. That is, until you call a single function on the underlying platform.

You cannot port Windows code to a DOS platform. And for the most part, you can't port DOS code to a Windows platform, if it touches any hardware.

Forget about porting from Windows to Mac to Unix. For that matter, most program's nowadays in C++ use almost no pure C++ code. They are collections of calls to other functions that someone else has defined. People publish API libraries. For everything. A web search will probably come up with at least 50 API libraries to handle simple serial communications out a Window's PC's serial port. Are they compatable? no. Do they each have virtues and drawbacks? yes. Are some more suitable to a task than others? yes. If you have an UNDERSTANDING of the conventions of C++ (or VB, or C#, or Pascal, or whatever) can you successfully use any of those libraries in a program? yep.

 

[Jim Dungar]

There is some portability between Certified IEC61131-3 programming packages when the logic uses only the basic commands (i.e. the timer example).

The problem with IEC61131-3 is the vast number of software packages that are only Compliant rather than certified. Compliancy is a marketing tool, cetrification is a commitment to the standard.

One main advantage of using/specifing IEC certified packages is the minimal learning curve required to move from one manufacturer to another. No longer do you need to remember, or figure out, the differences between how Rockwell, Siemens, and Modicon does a "one-shot" coil.

 

[JesperMP]

rdrast,
I have a feeling that I have stepped on someones toe here. Let me apologize, because the fault is all mine. I assumed something in the beginning that just isnt possible.
But to take your analogy of MAC DOS WINDOWS UNIX etc. that would correspond to the different PLC hardware configurations. The basic datahandling routines should port between platforms. But adjustment to the underlying platform for i/o will allways be required (whether PC or PLC).

Jim,
are TWINCAT and CONCEPT amongst the certified programming packages ?

thanx

 

[rdrast]

No toes stepped on

But as Jim just said above, the actual functionality that is 100% cross platform is not all that extensive. And unfortunately, restricting yourself to that level of actual certifiable compliance would be like restricting yourself to only using a 4 function calculator with no memory to do trig. Yes, it's possible, but not an ideal solution.

The other problem is that many PLC's DO have hardware dependencies, that restrict how they can be programmed. The most common hardware dependency here might be the fact that some PLC's have hard-coded allocations for timers and counters. You may only get 32 timers, and 32 counters in Brand X, whereas Brand Y uses a total software timer implementation, and lets you have as many as available memory allows.


But even if something did come out that was 100% platform independent at a source code level, you can bet that the very next week, a new platform architecture would come out and break it .

 

[rsdoran]

ALL of this conversation is about 1131-3, there are more parts to it. Actually I think the software was just a part because they wanted a certain familiarity created when programming, not that it would actually be exact from brand to brand.

I think hardware and some other issues were, like the concept of having original program file to be able to view or access the plc.

Basically I think it was more of a "protection" scheme for manuafacturers and OEM's ...ie slightly easier to use because the software will have similar functions and ALOT easier to protect the software or programming when desired.

Standards are not always created to make it easier, sometimes they are developed to "line pockets".

I too thought that IEC 61131-3 was going to mean that software would be the "exact same" regardless of vendor but studied it and even got involved in that waste of time project with Linux. For someone like me if all the software had all the same functions etc then, maybe then, I could learn this stuff. I have to deal with so many brands its like a jungle.

We live and learn.

 

[Tom Jenkins]

"Dream a little dream for me" - Mamma Cass

I am quite sure that IEC prgramming standards were only intended to create cross platform consistency in "look and feel" for common program instructions, and it failed to a large extent in this. It was also intended to standardize the various prgramming languages (ladder, sequential function chart, etc.) that COULD be available. Cross platform transportability is, alas, going to be an impossible dream. Most manufacturers can't even get cross platform compatibility for different models within their own product line.

As far as companies specifying IEC compatibilty because they think it will save money through transportable code, it doesn't prove a thing. Some of these same guys specifiy industrial ethernet for data communications because they think that means that any PLC with an ethernet port can tie into the network - WRONG!

 

[Peter Nachtwey]

What kind of specification doesn't support XOR?

I was looking at Theo's problem and looked at my 61131-3 specification and found that 61131-3 does not support a byte, word or dword exclusive or. Just logical exclusive or. What kind of specification is that? I hope I will be forgiven when I don't follow the specification and add these instructions. Most microcontrollers, and all that I have seen, support a byte exclusive or. My DSP supports the dword exclusive or as it doesn't support bytes.