Hello everyone,
I have been in the PLC / automation industry for quite a few years now and have been exposed to many different PLCs and their programming environments. Sometimes as a result of this I have been required to use the IEC 61131 programming standard depending on the controller selected. I understand the utopian belief behind it that all anyone ever has to do is learn one programming software package and then be able to automate all different types of PLCs.

This standard, which I think is flawed, at times I don't think ever has or ever will achieve the original intent as all that it did was create 3rd party software vendors to create the programming software (without knowing or caring which PLC it is for) and that virtually every type of PLC I come into has its own IEC environment that is not cross compatible to the other so you never could write one program for multiple PLC hardware setups. All of the environments have similar standard functions but then each PLC vendor has its own custom functions.

To me the IEC 61131 standards has failed. I have programmed Allen-Bradley, Bristol Babcock, Siemens, and ISaGRAF based controllers all IEC compliant but each environment is unique and the only one that acutally feels like it wasn't thrown together over a weekend is Allen-Bradley's and maybe Siemens environment.

Am I expecting too much? What do you think?

 

We've all shared your experience.

1131 hasn't really changed anything as far as I can tell. Each programming environment is unique and requires more knowledge of arcane vendor-specific trivia than technical brilliance.

We all spend more time sweating firmware versions, drivers and service packs than concentrating on the real task at hand.

This has become as true for hard PLCs as it always has been for PCs.

Most of us work in Windows now & it changes every couple of years. Believe it or not, most people actually WANT it to! I've got 4 OSs on my laptop and here comes Vista.

Yet we have to support hardware that can a does last decades.

As much as I'd like to see a standard that addresses the real problems, I don't expect to live to see it.

My $0.02

Michal Casterline
Frakes Engineering

 

The IEC61131-3 is really more about the 'common elements' - things like strong data typing, POU definition, variable definition. There is only one library of elements (basic function blocks like counters and timers) defined by the standard.

It was never the intent to have cross-portability.

The interface (the editor) is only a small part of a control system, the real thing that drives a control system, especially motion, is how that engine works underneath. That will always depend on the manufacturer. Suffice it to say that some work better than others.

Organizations like plcopen.org and omac.org have accomplished much toward other libraries of elements by the way. I recommend getting involved and seeing first hand how much work is expended by many well meaning people, with out thinking about market share.

The fact that something like IEC61131-3 exists is a testament to what is right in our world.

If an implementation is poor, do not blame the standard. There are many very capable packages out there. You have to be willing to step out of the box however. Take a chance with a smaller more nimble vendor that truly lives openness.

Robert B. Trask, PE
San Diego, CA USA

 

I agree, and the same goes for Foundation Fieldbus based systems like DeltaV, they interpret the "standard" their own way.

As with your 2 examples, the top players are the most robust and look like there was some time, money and research spent on them.

That part speaks for itself in volume and size of company.

There will never be standards when money and type "A" personalities are involved. We all think we have a better way.

Within my own company we developed standards which every time we turn around are violated or "we will just make an exception this one time" and this one time and on and on...

I prefer to call them all guidelines now.

Dave

 

I have worked with several 61131-3 systems. AB (LOOSE implementation) Siemens (loose as well).
Those are the "big dogs", I guess you could call them. If you read the standards, Modicon's Concept and Unity seem to come the closest to adherence to the standard. Indramat's implementation is also very close. The advantage with Indramat's is that you can view all of the code in either ST, Ladder, or Function blocks. I have been programming PLCs since the mid to late 1980's. Used just about every kind of PLC out there, and for me, I prefer the way that Schneider has built the Unity platform. Its ability to create advanced Objects is going to revolutionize the way we program and re-use objects. Troubleshooting is also much easier than in Ladder. If AB catches up, I may change my mind.

Nik

 

Hello all,

I think that the implementation of IEC 61131-3 has been a good thing. If you look at the languages, there is a basic form for allowing easy programming from one manufacturer to another. If you require you integrator to only use the common functions and FBs, you should be able to write the a new program in Bristol, Inc. from A-B in a shorter time. Each of the manufacturers have there own special FBs and that is ok. We try to stay away from these in the basic program so that we can move to another manufacturer without to many problems. If the code is good in one manufacturer, why rewrite it? In Water and Wastewater we pretty much do the same process year after year. If we have to switch to a different product line, we can do it a lot easier if we have a standard to reference. It causes a little of frustration for the integrators sometime, but that is what they are getting paid to do for you.

If we have special functions that are easily done by a suppliers FBs, then I have them written in a different POU and documented to let future programmers know what is going on. I think if you follow some basic policies in your programming, you can make it easier to transition from one manufacturer to another.

It would be nice to be able to port the program from one manufacturer to another, but something is better than nothing. There are some good books that provide a basis to allow easy transition from one manufacturer to another.

Anyway, my $0.02.

Bob

Robert J. Dusza, Jr.
Project & Technical Support Manager
(V) 1-860-647-3219
(F) 1-860-647-3150
E-mail - [email protected]
Manchester Water & Sewer Dept.
125 Spring St. P.O. Box 191
Manchester, CT 06045-0191

 

In my personal opinion the implementation of IEC 61131-3 (the programming language) is consistent among the different systems and software that I have seen. A coil or a normally-open contact look the same in all the applications I can recall so I think that IEC 61131-3 has been a success. I believe an engineer can jump from one 1131-3 system to the other and much of his programming skill is still valid. In my view this is a great success.

"Slcster" wrote the original intent was for "3rd party software vendors to create the programming software (without knowing or caring which PLC it is for" - was the original intent really to allow third party programming tools or was the intent portability of skills? If so, a big piece is missing, and that would be the protocol for the software to download the programming elements into the PLC - I have not seen that being defined yet.

Jonas

 

Hi, I agree, I use this language everyday, its strong typing has greatly simplified LADDER and FBD programming. I regularly swap routines between AB and Siemens, with a little tweaking. I believe that it will continue to erode the 'we only know brand X PLC' mentality, and force manufacturers to compete on price and quality.

Marc Sinclair

 

In my opinion, the IEC 61131-3 standard is an example of misuse of standard idea. The main feature that lead me to this thoughts, is the joining of 5 languages in one document. It is a bit conspirology suspicion, but I think the big guys just tried to protect their investments (most probably, from OOP).

The languages are very poor from technical point of view, so, the algorithms they allow to create are very simple, so, the standard has very small value, if any.

Best regards
Vladimir

 

In reply to Jonas Berge: I think the original intention of the IEC 61131-3 standard was to standardise ladder logic and other automation languages in a manner similar to how 'C' and many other computer programming languages have been standardised. If this was the intention, then IEC 61131-3 has not been successful.

The differences between different IEC 61131-3 compliant ladder implementations are at least as great as the differences between compliant and non-compliant language dialects, so it is difficult to see what the standard has accomplished. At least one of the major PLC vendors has two current "IEC 61131-3 compliant" product lines whose ladder and IL have little or nothing in common with each other.

What a genuine standard would do is to allow you to easily move an existing PLC program to a different model or brand of PLC. It would also make practical the creation of standardised third party libraries for controlling or interfacing with OEM hardware (e.g. a bowl feeder vendor could provide a library to control the feeder and have this library work with any model of PLC).

As it is, the automation industry seems to be stuck in the computing equivalent of the 1960s, where every computer was programmed in its own proprietary language and porting a program to a different computer meant completely re-writing it. The smaller automation vendors seem to make a more genuine effort than the larger ones to have a real standard. This is probably because they are less concerned with locking in their existing customers and more concerned with getting new ones.

 

How is it that these languages are poor? In my opinion the IEC 61131-3 languages are excellent but are not a replacement for C/C++/C# type of high variability languages.

I believe the IEC 61131-3 languages were chosen due to their suitability for building control strategies for automation. They are pre-packed with pre-tested functions/modules for the features often used in automation projects and the graphical languages (ladder diagram and function block diagram) even look like the documentation they are based on; often we say we are "configuring" application programs rather than "programming".

The highly structured ("inflexible") nature of these languages ensure a simple way of preventing complex problems like memory conflicts, type mismatch, infinite loops, and memory leaks. Safety standards (IEC 61508-3) favor these types of "limited variability languages" because it makes testing/verification/validation/analysis of "code" easier. Additionally, these are typically also strongly typed, not using any global variables to make it even more robust, and no "jumps".

IEC 61131-3 falls under parent standard IEC 61499 and has a sister standard IEC 61804 which is for function blocks more suited for process control than factory automation.

Jonas

 

Maybe it is time to evaluate these standards by the end users. I beleive the standard is a good idea to define data format and define a set of standard instructions. The problem I think makers of this standard left too many little things a litle bit open to the PLC manufacturers. Everyone complies with the standard in his own way.

Anyway i think it is time to extend this standard, there is a lack of instructions and function blocks in this standard, and I think it is time concentrate on standarisation of programming structures.

How many programs these days that are supposed to comply with IEC1131, but the programmers have used non-IEC1131 programming instructions in the PLCs or even worse they think the program is compliant.

I agree that the standard has failed to acheive its goal, but still it is something we have. Do not throw it away but try to make it better.

Sabri

 

As the former Managing Director of PLCopen for North America, I share your
pain. The IEC standard as a standard is somewhat worthless due to the
limits it provides vendors. To be compliant only to the standard will not
allow anyone to do what they need to do.

Having said that, I invite you to read my column on my thoughts here:

http://www.controldesign.com/articles/2006/119.html

and yes I think that there are hidden agendas everywhere..

Cheers from: Jeremy Pollard, CET The Caring Canuckian!
www[.]tsuonline.com

Control Design www[.]controldesignmag.com
Manufacturing Automation www[.]automationmag.com

3 Red Pine Court, RR# 2 Shanty Bay, Ontario L0L 2L0
705.739.7155 Cell # 705.725.3579

 

I have a tendency to agree that the initiative may not be living up to the aspirations of its authors. The byproducts, however, that it has introduced are, in my humble opinion, nothing less than great. I live in North America and the favored plc by most customers has traditionally been an Allen Bradley. Previously we only had ladder by which to program. Now that AB has adopted various (if not all) languages of the 1131-3 standard in its CLX platform, it has extended the capabilities of that plc immeasurably. Admittedly AB doesn’t strictly adhere to the standard, but the benefits are a giant leap ahead of where we were 10 years ago (though probably not as far as we could be).

 

Hello Jonas,

> How is it that these languages are poor? In my opinion the IEC 61131-3
> languages are excellent but are not a replacement for C/C++/C# type of high
> variability languages. <

I say "poor" because there are certain criteria of "poorness" - criteria that are issued from the control algorithm specific features.

> I believe the IEC 61131-3 languages were chosen due to their suitability for
> building control strategies for automation. They are pre-packed with
> pre-tested functions/modules for the features often used in automation
> projects and the graphical languages (ladder diagram and function block
> diagram) even look like the documentation they are based on; often we say we
> are "configuring" application programs rather than "programming". <

LD and FBD are rather methaphoric languages than graphic ones. It is the key feature. Very easy to study, very hard to use in complex projects.

> The highly structured ("inflexible") nature of these languages ensure a
> simple way of preventing complex problems like memory conflicts, type
> mismatch, infinite loops, and memory leaks. Safety standards (IEC 61508-3)
> favor these types of "limited variability languages" because it makes
> testing/verification/validation/analysis of "code" easier. Additionally,
> these are typically also strongly typed, not using any global variables to
> make it even more robust, and no "jumps". <

It is another level of the language problem. We may disscuss those aspects if you wish, but we need be more accurate... and tell the difference
between "limited variability" and "limited ability" at least ;-) Everybody can google "esoteris languages" and think a little about those of extremely simple languages.

> IEC 61131-3 falls under parent standard IEC 61499 and has a sister standard
> IEC 61804 which is for function blocks more suited for process control than
> factory automation. <

Yes, IEC 61499 is an attempt to enhance the 61131-3 standard to acheive satisfactory level of structurisation, -- the feature that is absent in the 61131-3 languages.

Best regards,
Vladimir

 

Hello again everyone,

The response to this post has been great. I think that there has been some constructive critiques of the standards with people posting on both sides of the fence. It is nice to know that I am not the only one who has been let down by the standards. I do see a great advantage to standardization, but I feel that the standard is too loose as you cannot easily take a program from one environment to the other without literally recreating it. Then if you use custom blocks as developed by the manufacturer those custom blocks might not be available in the other. As a programmer it has not simplified my life. One post mentioned that maybe it was time for the end user to take this to the next level. I am not even sure how we could go about this but it certainly is a nice idea. Ultimately though how could the big players in the automation industry every agree on "losing control" of their development environment....

Keep the posts coming. I thank everyone for responding!

 

Here, as in so many other things, money is the root of all evil. As long as competitors rather than users call the shots, we will never see strong or effective standards. And if we did, they would immediately set about embracing, extending, and destroying them. If users were to set the standards, and actually make them a contract requirement, this mess would be cleared up inside a year. As long as people buy broken standards, they will stay broken.

Regards

cww

 

Hello,

While I mostly agree with you Curt, I think there is more to it.

I've looked at PLCs that tried to meet the standard using their existing product by making software/compiler changes, and when you meet all of the IEC requirements (especially when you talk about SFC) the application code gets so bloated that scan times that normally take microseconds bloat up to tens of milliseconds for a very small process. So why would a company want to change their hardware and software to implement some standard exactly at the price of frustrating their customer when it does not work optimally?

I do believe that the controls world could use a paradigm shift, but I don't believe IEC 61131 is it. I see two major problems in controls:

- Lack of a sequential programming language like a subset of C/C++/C# implemented inside a RTOS structure. - Integrated Servo and stepper motion instructions/functions and hardware tightly coupled to memory. - Integrated HMI interfacing (i.e. all data gets stored with the PLC project, no additional projecs or tag database exports needed). If you want to export the tags and use a remote HMI, that is fine as an option.

I'm not holding my breath, because I don't think people are quite ready to program their PLCs in a C like language with an RTOS underneath, but I have hope because the robot Industry has adopted it in some applications, such as Epson RC+ language which has a simplified RTOS with a C/VB6 mixture of language. I've used this to develop entire machines (not just robot control) and it has proved to be very fast and robust. I'd like to see something like that, but on PLC hardware.

~Ken

 

I looked at the standard again after many years and I could not find any statement about portability of the code.

To port a program file from one system to another the file format would also have to be the same. Such a format has not been defined.

I personally believe the intent of the standard is to be able to apply what you learnt once on many different systems.

Jonas

 

In reply to Jonas Berge: I didn't actually say portability was the explicit intention of the IEC-61131-3 standard, I said portability would have been the practical result of real standard. The real test of how well a language standard works is to try to port "compliant" programs between compilers or interpreters.

I don't think I am alone in this view either. I don't have a copy of the IEC standard, but I will note that the canonical book on the subject is "Programming Industrial Control Systems Using IEC 1131-3" by R.W. Lewis, and published by the IEE. In chapter 1 section 1.8 the author states "IEC 1131-3 provides standardised languages and methods of program execution so that a wide range of technological problems can be programmed as vendor-independent software elements. In other words, a large proportion of software written for IEC 1131-3 compliant PLCs, should be portable and will run on PLCs from different vendors." The phrase "vendor-independent software" was printed in bold in the book.

I will also point out that file formats are a very different subject from language standards. A compatible language doesn't imply a compatible file format or visa versa. Both are useful, but they are really different things. I could send you a document written in English in ISO/IEC 26300 standard file format, but if you use a word processor that doesn't support standard formats (like Microsoft Word), then you won't be able to open it.