Iec 1131

JesperMP

Lifetime Supporting Member + Moderator
Join Date
Feb 2003
Location
ᚴᚬᛒᛅᚾᚼᚬᚠᚾ
Posts
16,223
Some questions to those using IEC 1131 for programming:

1. Have anyone tried to use an external IEC 1131 software for programming Siemens S7 ? If so, can the code be exported/imported between the IEC 1131 software and STEP7 ?

2. Have anyone tried to use an external IEC 1131 software for programming AB ControlLogix ? If so, can the code be exported/imported between the IEC 1131 software and RSLogix ?

3. Have anyone tried to use an IEC 1131 programming package for crossplatform development ? If so, any good or bad things that have come up in that context ?
 
Jesper,

as far as I know IEC-1131 (or EN-61131) is a way of programming, not a programming package.

This is a standard which only describes which languages have to be present in a programming package, which are optional, how timers and counters have to be programmed, the formats of variables and so on.

If anybody could correct me in this I too would be very interested since I'm teaching people about no less than 7 different PLC's, sometimes even all at the same time:
  1. Simatic S5-100U and 115U
  2. Simatic S5-135U
  3. Simatic S7-200
  4. Simatic S7-300
  5. Omron CQM1
  6. Allen-Bradley SLC5/03
  7. Allen-Bradley CompactLogix
    [/list=1]
    No need to say that this kind of software would make life a lot easier for me :p .

    Kind regards,
 
Jean Pierre,

I know that it is not a programming package in it self.
But there are several programming environments that follow IEC 1131.
I have trial versions of Beckhoffs TWINCAT and Grp. Schneiders CONCEPT and will try to find out how useful they are for crossplatform development.

Both S7 and ControlLogix claim they conform to IEC 1131. But for STEP7 there is zero help in how to use this claimed feature.
 
You are correct of course that IEC1131 is NOT an programming package,

The Standard IEC 1131 is the standard to which programmable Logic Controllers should behave. They are a standard for the "functions" of the PLC, not interchangable.

For example the IEC standard includes the Signal processing function, The operating system, Types of IO signals, Characteristics of communications functions, debug/monitoring archiving etc,status indication etcetcetc.

THese are all characteristics that all plc's should adapt, AB/Siemens Mitsubishi etc. THe software aspect of IEC1131 refers to the handling and functionality of all software features such as Timers / Warm restarts. It defines these features but by no way does it make them interchangable. You will not be able to program an Mitsubishi IEC program on a Siemens Step 7 software. But it does and should mean that if you have 2 x sets of programs one written in Siemens the other in Mitsubishi that side by side if written utilising IEC timers and functions the 2 x programs should behave in the same manner. Thats the idea anyway is that IEC1131 Defines all the aspects of Programmable Logic Controllers and MMI's etc (Should be HMI's nowadays but I think it was released prior to 1992) so excuse us ladies,,

Either way it reads Like a Siemens Manual, wonder did they have any interest in developing... I imagine maybe a while down the line the softwares will be completely interchangable , but as far as I know they're a while from that,, just think then Siemens will have to release their MPI protocol !!!!!!!!!


Cheers, hope someone can correct me on this !!
 
There is no cross-platform programming software.

And I don't think that there will ever be, even though this is the dream of all those who tout IEC-61131-3.

Even IF any two PLCs shared a common language/instruction set (and that is a pretty big IF), then this mythical third-party programmer would have to know the details of the firmware to actually be able to convert the high-level languages into the machine code that the PLC can acutally understand.

The manufacturer's don't share those secrets, and so you have to reverse engineer the firmware (and each new firmware version that comes out - a potential problem with ControlLogix)

And they'd have to have such a good interface that they'd be able to compete with the existing programs that are already out on the market that are made by the manufacturer.

Once upon a time, it might have been possible. There were 3rd-party program suppliers. You could program an Allen Bradley PLC-5 using either AB's 6200 or Icom's AI. A Modicon 984 could be programmed with Modsoft, Taylor, UpDoc, and a few others. I can't think of an existing 3rd party programming package now. Concept, even though it's IEC-61131, only programs Modicom Quantum and Premium PLCs.


Going back to that big IF. Quiz (for anyone who knows):

Which is the "correct" method to do a 61131 timer:


+---- TON --+
------|EN | Loss of Enable = Reset
| 1 SEC |
+-----------+

OR
+---- TMR --+
------|EN | Seperate Enable and Reset
| 1 SEC | ("Retentive" or "Accumulating" timer)
------|RST |
+-----------+


Or are both acceptable?
Does every brand of PLC (firmware) support both? I know that AB does (although they break out the RES function from the RTO block in the way they display the code. Does this make it "61131-3 complient?" or not?)
 
The "common feaures" aspect of IEC1131 is grossly oversold. We have programmed identical machines in "IEC1131 compliant" programming packages from different vendors. If you put the printouts of the two programs next to each other the differences are very significant. For the forseeable future you should resign yourself to redoing the program every time you change platforms.
 
Allen,

I've never actually read the 61131-3 spec for ladder logic functions, so I can't verify if this is accurate or not.

When Horner Electric first rolled out their combined PLC/HMI product (the one Ron Doran is working with), I attended one of their demos. The guy doing the presentation claimed that their ladder was 61131-3 compliant. They did not have a retentive timer instruction in their function set. He said that for the initial release, they had chosen to implement only those functions that were called for in the 61131-3 spec, and that the retentive timer instruction was allowed, but not mandated.

Maybe one of the regulars here has access to the spec (Peter, would that be you?) and can confirm or debunk this.

I notice that Horner has added a retentive timer in a subsequent release.
 
Is it really possible to port IEC 61131-3 software from one vendor's PLC to another?
No it is not possible simply to take an application that runs on one type of PLC and copy it over to another type. There are several problems preventing the direct porting of IEC 61131-3 software.
1. The PLC I/O systems use different addressing schemes.
2. The task scan rates supported on different PLCs vary.
3. Each PLC vendor may have implemented a different sub-set of IEC 61131-3 features.
4. Similarly each vendor may have different values for implementation specific parameters such as maximum array sizes, string lengths etc.
5. Finally there is not a standard file format in which to store and port IEC 61131-3 applications.
Notwithstanding these constraints, at the function and function block level, it may be possible to re-implement identical POUs on different vendors PLCs. Textual source code for POUs developed in ST or IL can be ported between different types of PLCs.

Is it possible to automatically convert between IEC 61131-3 languages, for example, can a POU written using LD be viewed and edited in ST or FBD?
This is a favourite IEC 61131-3 myth. There has never been any intention that it should be possible to convert any language into any other language. If a restricted sub-set of each language is used some limited portability may be possible but there are some significant problems. For example, there is no way to represent expressions involving array variables in the FBD language.

More can be seen at: http://www.holobloc.com/stds/iec/sc65bwg7tf3/html/faq.htm
 
Moeller PS3

Hi, i've got a Moeller PS3 and i think it is IEC 1131 compliant, but i don't know anything about this languaje... can anybody tell me where can i found info about IEC 1131?

Thanx!

PS: this is my first post :D
 
Thanks to all that have responded so far.
It is certainly enlightening to learn your experiences, but also disappointing as it seems that the vote is allmost unanimously against that code can be ported between IEC 1131 platforms.

But I wont give it up yet.
Even if it is not possible to automatically convert 100%, isnt it possible to export and import something . At least to get a good starting point.
How about export and import of IL ? If this is standardized, and is basically just ASCII text, then it should be possible to export and import a good part of it.

I would like to elaborate on why I have started on this "quest". A couple of years back I read an article about a large danish company that have put all its automation out to subcontractors. The subcontractors were only required to fulfill the requirements for the equipments functionality. They were free to choose how they would achieve the functionality - including which PLC to use. Here is the important point: The subcontactors had to use IEC 1131 compatible PLCs so that the code was reusable across all the various platforms. The company stated substantial savings because of this subcontracting sceme.
I am going to track that article down !
 
Steve Bailey said:
They did not have a retentive timer instruction in their function set. He said that for the initial release, they had chosen to implement only those functions that were called for in the 61131-3 spec, and that the retentive timer instruction was allowed, but not mandated.

Maybe one of the regulars here has access to the spec (Peter, would that be you?) and can confirm or debunk this.

I notice that Horner has added a retentive timer in a subsequent release.

I just looked at the specifications. I could not see where retentive memory is mandated. I would have to agree with the Horner guy ( a first ). There is a specification on how retentive memory is to be declared if it is avaiable.
 
JesperMP
IT WILL NOT HAPPEN!!!!!

IEC 1131 has 5 sections to it. It covers hardware, software and lots of things. I would suggest you obtain a copy and have a good read. IEC 1131.3 is the section on software.

There are several languages and types of programming defined, ladder, STL (structured text), IL (mnemonic), FBC (function block), SFC (sequential flow chart). A piece of programme that is written if STL (Pasal like) is unlikely to be able to be converted to ladder etc. Scetions of the same programme may be written in ladder, FBC. STL etc as each language has it's strengths and weaknesses.

IEC 1131 does NOT and never did define that code would be portable from brand to brand, that is only an ideal. Each manufacturer has their own way of implementing these languages. Also, function lists will vary greatly from brand to brand. An example, and there are many more from brand to brand, is Omron's APR (arithmetic process) function. I have never seen it in another brand of PLC. Basically, you put together a table and then use APR to linearise the output. Very usefull for tanks that are circular with rounded ends that are mounted on their sides. Compile a table of litres=4-20 ma input (converted to values) and then linearise the output. As I stated there are many more from PLC to PLC.

The basis of IEC 1131 is "look and feel". Many basic functions will behave and be programmed the same way but will probably never be portable from brand to brand, or even between different PLC's of the same make, due to capabilities of the PLC and processor.
Brand "X" "cheapy" has 40 functions and 128 timers. The same brand top of the line has 400 functions and 4028 timers. Obviously a programme from the top of the line to the cheapy cannot be portable as the function list, timer numbers are not the same.

If you only used the functions and timers in the top of the line PLC that were available in the cheapy of brand "X", you would be able to port the programme, but then you would not use the top of the line PLC, would you?

beerchug
 
rsdoran,

I have taken a look at that link. The most interesting FAC for me was this one:
Is it really possible to port IEC 61131-3 software from one vendor's PLC to another?
No it is not possible simply to take an application that runs on one type of PLC and copy it over to another type. There are several problems preventing the direct porting of IEC 61131-3 software.
The PLC I/O systems use different addressing schemes.
The task scan rates supported on different PLCs vary.
Each PLC vendor may have implemented a different sub-set of IEC 61131-3 features.
Similarly each vendor may have different values for implementation specific parameters such as maximum array sizes, string lengths etc.
Finally there is not a standard file format in which to store and port IEC 61131-3 applications.
The above seems to say that generally you can NOT port code between vendors.

but the very last two sentences opens the door for a little light to slip thru:
Notwithstanding these constraints, at the function and function block level, it may be possible to re-implement identical POUs on different vendors PLCs. Textual source code for POUs developed in ST or IL can be ported between different types of PLCs.
So I am still hoping that parts of the programs CAN be ported, with a bit of manual labor.

edit:
The next thing that I will try, is to make some IL code in STEP7, TWINCAT and CONCEPT, and then by simple cut-and-paste between the programs see how it goes.
 
Last edited:
rsdoran,

I have studied the Siemens statement about IEC1131, and it seems that Siemens claims conformity to all IEC languages. But upon closer inspection, it seems that it is only the overall functionality that conforms, it is not an exact instruction for instruction match.
The statement is strangely wague about what the differences really are.

It says for example that for STL (IEC IL):
"STL in STEP7 differs essentially from the standard regarding the command syntax [..] Different syntax, same functionality [..] This difference is necessarry to meet the requirements concerning compatibility with STL in STEP5.
In addition STL in both STEP5 and STEP7 include far more commands than defined in the basic command set of the standard."

Ahem.. it is a lot b******t !
To me, it looks like STEP7 STL is completely different from IEC1131 IL. Siemens claim of IEC1131 IL conformity for STL is paperthin.

By the way, I have now tried to cut-and-paste IL and ST code between TWINCAT and CONCEPT, and it works. For ST code there are a number of smaller formatting errors, but these can be taken care of with a little post-porting touching up.
LD code cannot be pasted, but that was to be expected.
 
Last edited:

Similar Topics

Hello, I have a small programming task that I need help solving. I have to: * Create an analog input (4-20v)and a digital output * The analog...
Replies
45
Views
24,937
I was poking through the Stackoverflow PLC Tag when I saw this answer to a question about converting a Real to a DWord and back again. What...
Replies
8
Views
2,856
I am looking for some expert advice. I have always made function blocks both with inputs and outputs and without inputs or outputs. I make the...
Replies
21
Views
6,592
Hello and happy new year! I would like to further understand who needs to design by this standard and is it a requirement for everyone or only...
Replies
3
Views
1,745
So Ladder is easy to read graphically, most everything can be coded in ladder, and it represents wiring diagrams the closest. SCL and ST are good...
Replies
5
Views
1,655
Back
Top Bottom