IEC 61131 PROGRAMMING 1

[QUIPPDUDE]

I have programmed many models of PLC and am reviewing the pros and cons of the IEC 61131 programming method vs. more conventional standard Ladder logic.

At first glance I do not find this method of programming to be particularly intuitive and the need to repeat variable declarations for each function block would seem redundant. In addition on-line monitoring/debugging seems tedious and awkward when the program is written in one of the textual languages [Instruction List or Structured Text].

However this is a NEW LANGUAGE for me so maybe I will begin to master it in time. I am currently using the Moeller Sucosoft 5.0 software with the PS4-200 series PLC.

I would be grateful to hear opinions from programmers who have used both types of programming language.

1.Are there any recommendations or resources that this forum's readers can suggest to get me up to speed faster with this programming language?

2.Other than the claim that this programming language is capable seamless cross-platform migration what are the true advantages/disadvantage of this system?

3.It would seem that there is a definite reluctance in the N.American market to adopt this programming system. Why?

 

[skills]

I don't look at the question in quite the same way. Ladder logic is great when it's an efficient medium for solutions. IEC systems are a development that purports to provide a 'suite' of 6 lanquages that are syntactically standard irrespect of specific implementation. It's the PLC world's version of ANSI C where if you want to be ANSI compliant, your compiler must take a source file and process it to native code to provide the EXACT same result. The benefit is, if realized, that a person can learn these six lanquages and write control code that always works!!! If, of course, it was written in the correct fashion for the application. I think it is a concept that is about 15 years overdue because I see so many people relearning different plc systems all because the systems have a different editing suite or lack some instruction or simply MODIFY a timer or counter in some way. I hate throwing money away and relearning all the time to do the same OLD thing sure looks like a waste to me!! In the pc world a C programmer writes a ANSI C programmer and it works regardless of whether he's ever seen a GIMIX or HELIX or SPARC computer and he simply doesn't need to know. There is a limit, of course, as to how far we can take this because some systems have module that may benefit from a MACRO-instruction. Great, IEC 1193-3 or the goal is to allow this; but, GUARANTEE someone like myself that I can write for it using the Standard set. In short, it is intended to be a time saver and break the hold some of these SORRY companies have on development systems. I know some good PLCs that I won't use because I think their development software sucks! I anxiously await the opportunity to use their hardware without screwing around with their pc software.

So, in short, don't look at it as an alternative to RLL. It isn't, it comprehends that and is much much more. You are free to comfine yourself to RLL within this context, it simply doesn't BOX you into it. And let's be honest here, RLL doesn't address some automation needs very effectively unless you're using langauge extensions anyway. We have just all agreed to EXPAND our view of the language set to occommodate its omissions, RIGHT?

 

[skills]

I forgot to add the link

http://www.plcopen.org/

that describes PLCopen as a goal and why both sides should benefit from it's advancement. BTW, you are free to submit suggestions for inclusion into the stardard to increase it's robustness if you have some!

 

[QUIPPDUDE]

Hey Skills,
thanks for your detailed and convincing argument toward adopting IEC 61131 programming. While I realize the primary goals are to "standardize" the programming language and provide cross-platform software migration I still remain unconvinced.
In the short time I have been using and learning the Moeller software it is apparent that each vendor includes a library of standardized IEC compliant instructions/functions and file tools. However they are free to provide platform/software specific libraries and tools.
This would seem to defeat the whole purpose of standardization and result in similar issues that currently exist between conventional Ladder Logix programs which you so eloquently discussed.

Any comments? By the way thanks for the link.

 

[skills]

I see your point and would ask "do you programm in C or C++? I ask this because a similar situation exists here as well as it does in any -- standard 'plus' environment where a product provides the STANDARD *plus* their optimized solutions. In your situation you could use the highly efficient instructions Moeller may have developed or use the standard. The difference is simply the degree you desire the result to be immediately readable and maintainable by a passer by or some backup personnel. Every standard of earth at the present is less efficient than some implementation that exists. This consortium readily admits that this is the case here. Some plcs use very efficient processors with unique instruction sets that excel like no other in some area. The standard basically 'detunes' this optimization nessesscarily to provide a common approach to all systems.

I agree with your observations about certain inefficienties with this standard, which by the way covers much much more than languages provided for in standard -3. The intended outline covers the mechanisms for I/O rack configuration where you learn one time to configure any rack in the world. I don't know that it will all be helpful and what we will end up with is companies providing the standard generators with their 'native' development systems.

I do a good bit of DCS and database work so the overdefining and structuring that may 'irk' you somewhat is just "par for the course" as regards my existing habits.

I explain what EVERYTHING is and where it's at before I even know exactly how to accomplish the task.

I would say this regarding the langauge set.

Is it perfect? Of course not!!

Is it comprehensive? Certainly not, I use 17 languages and some of my favorites aren't even included!!!

Is it more time effective?? This depends really on the scope and breath of the job or system and the specific inclusion of parallel tasks such as data logging, coordinated motion, analysis, supervisory layers and what have you.

Is is always a benefit??? No, indeed sometimes on a small, 'sub 8k', ladder logic natured job it's a pain in the but; but, someday.... someday??

 

[skills]

I'm sorry that I keep harping in on this but I keep revisiting my younger years when this all started back in 1985 and it was all the rave. As a 21 year old it promised that I could one day buy a plc with the 'quarantee' of specific functionality. If you buy a "certified" system it has be tested and deemed to pass the 7 segments of certification process. This means that I know where everything is at in memory, 'specified in standard', the structure of data sets, and the "specified" data type MUST be present, usable, and sized like the standard. You and I should love this because we can gain more free time to develop applications such as the pc programmers enjoy!!

I loved the idea that I no longer have to care how
Square D, Modicon, Seimans, TI, Reliance, AB, ABB, Telemechanique, or anyone else does stuff. I just use the standard and their stuff works. Most of the questions and threads here, as you may imagine, would go away. You and I wouldn't ask "Can you do run-time edits on a 984 or 777?", we would just know that if it was "certified" it did and we would know how!!!

The down side as I have come to discover is that it essentially has the effect or potential depending on it's acceptance of making those who primarily program plcs a commodity. No longer would some company need to run a ad for a Seimans S7 programmer, they could hire someone who is a programmer of the standard. I beleive that at the bottom some have intended to use this to drive down wages on plc engineers and technicians. Now, That's bad for me!!!

I'm for it in many ways and again it in others; but, I have no doubt that it will prevail in it's acceptance because any company that fails to provide the standard will someday be frozen out by the negative connotation of being a holdout.

 

[QUIPPDUDE]

Hey skills,
you sure have been busy responding very to my qusetion in much depth, looks like this is as hot an issue for you as it is for me. Yes we used to program in C and C++ back in the good ole microprocessor days. Our push towards PLC's was two-fold, it simplifies the I/O interfacing and dare I say it lowered the cost of necessary programming skills. This meant that a wider audience [from programmer to end-user maintenance folks] were able to work with the control devices. On-site changes, program downloads, on-line debugging etc. etc. all became a less painful and simpler process.
In programming using IEC 61131 standards one is able to mix programming methods [Structured Text, Ladder Diagram, Function Block Diagram and Instruction List] for each program function block. In some cases these may even be mixed within the same function block.
There is no doubt that some instructions [for example array handling, complex calculations] are not efficiently handled with conventional ladder instructions, they are better handled using one of the alternate programming tools. This is a definite advantage. However it would seem that this begins to migrate away from a the very advantages that conventional ladder programming offered - namely a language/method that is readily understood and accepted by all parties involved in it implementation and use.

Needless to say this seems to be the ultimate goal of the IEC 61131 standard. I rememember back in the late 70's trying being laughed at when trying to convince the diehard NEMA standards electrical engineers to implement some DIN/IEC standard components.

Yes the standard is well accepted and being used in Europe. Why the reluctance os US domestic suppliers to adopt the same approach? Pride? NIH [Not Invented Here] Syndrome? Re-Training Costs? Available programmers?

I have yet to see ONE U.S. job description that even mentions the 61131 standard as a requirement!

Oh what to to, which way to turn. I wish I had that crystal ball!

Thanks again for your responses.
Anyone else other than skills have input?