The White Papers.....State Language

R

Thread Starter

Ralph Kitts

The article on state languages that can be accessed in the Languages section of this website has me a little disturbed.

Forgive if I miss the point, but nowhere in the article did I find a point or issue, that state languages handle better that ladder logic. If it is simplification you are after, or better clarity, write your RLL and "encapsulate" it into subroutines....I do it all the time. This insulates those who don't care for the details, and lets them bypass them and look at the general outline.

Lets face it, the details (dirty work) hidden from the state language user has to be dealt with at some point.....state language can't bypass the setup of protocols and servo details any more than any other language. I have found plenty of functionality in RLL and do not find the dreaded function box confusing at all. And anyway, do not most people find a graphical-style language like RLL quicker to understand that a statement list? I can see in a second why a step in my process is being held up. I can program interrupts and and immediate refreshes. And RLL is the very essence of asynchronous control: its not something that had to be added later.

RLL is so flexible it can successfully mimic state-type blocks and sequence-type functions. I guess my opinion is clear, but my main point is I don't see the need to change when no obvious gains are apparent. If it is an issue of flavor of control instead of function, then OK. I do vigorously reserve the right to be wrong, and will listen to thoughtful comments and ideas on this subject.
 
M

Michael Griffin

At 16:32 01/09/00 -0400, Ralph Kitts wrote:
<clip>
>The article on state languages that can be accessed in the
>Languages section of this website has me a little disturbed.
>
>Forgive if I miss the point, but nowhere in the article did I find a
>point or issue, that state languages handle better that ladder logic.
>If it is simplification you are after, or better clarity, write your RLL
>and "encapsulate" it into subroutines....I do it all the time. This
>insulates those who don't care for the details, and lets them
>bypass them and look at the general outline.
<clip>

I can't comment on the relative merit of state languages (or rather of Quick Step in particular), as I have not used it in a real project. However I think you are perhaps confounding two issues. You are not unique in this respect, as I believe that the original white paper to which you refer does the same in a different way.

When we are dealing with programs which are larger than a few pages in size, we have to deal with two separate problems. The first is how to represent very small snippets of logic clearly. This is something which ladder logic excels at. I have yet to see a system which represents the equivalent of a single rung of ladder logic as clearly as ladder does. This is what people are referring to when they talk about how handy it is for trouble shooting.

However, when we have to assemble large numbers of "rungs" into an organised system (especially for sequential operations) and show the relationships between groups of rungs, this is where ladder runs into a problem. True ladder logic itself simply has no provision for this. This is what people are referring to when they complain how difficult ladder logic is to trouble shoot.

State logic, grafcet, "flow charts", etc. all attempt to deal with this latter problem in different ways. I won't comment on what I believe
their individual degree of success is in this matter. I will say that the problem they are attempting to solve is one that true ladder logic does not even address.

What people have done to address it is to impose various overall structures on ladder logic which are not really part of the language itself.

The first is to allow a division into functional or logical areas. This is generally performed by allowing subroutines of some sort. Subroutine parameters even allow the creation of reusable logic. There is no obvious means of deciding how many subroutines there should be, or what should be in each. However, the problems here are relatively minor compared to the next
issue.

The second problem is organising logic to create a sequential series of operations. This is the area where ladder logic does most poorly. There has never been an area of programming which has been such a fertile source of bad ideas and worse implementations as this. Everybody seems to have their own system or variation on a system, and everybody has a reason why their method is the only one which makes sense.

I will mention a few of the systems I have seen. All of them should be well known to us. If anyone has something not covered here, they are welcome to add to the list.

1) Step latches. This works tolerably well for very simple systems. It gets rather tedious though if you are trying to provide features such as single-step sequential manual control in forward and reverse. It is also very dependent upon the programmer being very neat and organised.

2) Drum (or cam) controler emulator. This also works tolerably well for very simple systems which always perform exactly the same operations in the same order and very poorly for any other situation. It is not very flexible, and simply will not work at all for many applications. It has also been the source of some of the very worst programs I have ever seen.

3) Shift register. This is really just a variation on the drum emulator and suffers many of the same problems. It is often used by people
who wanted to use a drum sequence emulator but were working with a PLC which didn't have one built in.

4) Subroutine or zone sequencing of some sort where each step of the sequence is completely contained in a different subroutine or logic zone. The method by which the transitions between steps are made can be defined in various ways. Some PLCs have special instructions to implement this method. Programs using this method use the same "output/transition" logical concepts
that grafcet (and other graphical systems) use.
The biggest problem with this method (or methods rather) is that there is no standardised way of implementing it and different versions may
have drastically different characteristics whose side effects may not be obvious to the uninitiated.

Methods 1 and 4 have definite advantages in that they provide an obvious means of grouping related logic together. Method 4 indeed normally
*requires* grouping logic together. Method 1 is typically somewhat less successful at this though.
Unless the machine is very simple indeed, methods 2 and 3 tend to result in "spagetti code" programs whose elements are scattered about in a
way totally unrelated to their sequence of operation. Reverse engineering a program using methods 2 or 3 can often require much more work than was required to originally write it.

Methods 2 and 3 also do not handle diverging and converging parallel sequences at all. Method 4 can handle this well or poorly depending upon how the transitions are controlled.

Methods 1 and 3 are often the lowest common denominator across a large range of different brands of PLCs, and so are often favoured by those who have to write programs for many different PLCs.

>I have found plenty of functionality in RLL and do
>not find the dreaded function box confusing at all.
<clip>
I agree about the function box. Questioning whether "function boxes" are actually ladder logic is a red herring. The most complex "function boxes" to be found in any ladder logic definition are timer and counter functions, and I have never seen the presence of either of these questioned. Mathematical and logical functions are simple by comparison.


>RLL is so flexible it can successfully mimic state-type blocks and
>sequence-type functions.
<clip>

I would not say it *can* mimic these features, rather I would say it *has* to mimic these features because they are not built in.


On another related note, I happen to have current need of a good written comparison of different ladder logic sequencing methods to
illustrate the advantages and disadvantages of each to several people who are not familiar with them. I am looking for something much more detailed than my brief comments above but have not found anything.
I am not looking for a manual for a specific PLC, rather I am looking for something which deals with non-trivial PLC programming on a
analytical basis. The general principles are the same regardless of the hardware. Does anyone know of any such document?


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
R

Richard A. Higginbotham, II

>The article on state languages that can be accessed in the
>Languages section of this website has me a little disturbed.

Me too, but I think for different reasons.

>Forgive if I miss the point, but nowhere in the article did I find a
>point or issue, that state languages handle better that ladder logic.
>If it is simplification you are after, or better clarity, write your RLL
>and "encapsulate" it into subroutines....I do it all the time. This
>insulates those who don't care for the details, and lets them
>bypass them and look at the general outline.

I think the "missing part" is a discussion of the different implementations of state languages and thier pros and cons and the way they can contribute to a programic solution (not just be it). I got the feeling he was talking about state languages as a programming solution in and of itself. State languages can handle complicated sequential operations in a clearer way than rll. The nitty gritty details depend on the implementation of course, but I would label them as another tool in my tool belt (valuable as they are), not the tool belt itself.


>Lets face it, the details (dirty work) hidden from the state language
>user has to be dealt with at some point.....state language can't
>bypass the setup of protocols and servo details any more than any
>other language. I have found plenty of functionality in RLL and do
>not find the dreaded function box confusing at all. And anyway, do
>not most people find a graphical-style language like RLL quicker to
>understand that a statement list? I can see in a second why a
>step in my process is being held up. I can program interrupts and
>and immediate refreshes. And RLL is the very essence of
>asynchronous control: its not something that had to be added later.

I agree that a state language is not the end all be all of control programing languages. With certain things it may allow an easilier and/or
faster implementation (namely sequential operations :), but I think you do miss one point. Its not that RLL isn't the easiest to understand for a small solution. Its all about time. C/C++, etc. allows programers no more
instructions over machine code. So why not program in machine code? Can't skip those details? Of course not, you don't program in machine code because its a PITA and considerably more time consuming. You'd probably scoff if someone asked you to do it. I do the same when asked to program RLL :). If you can do the same project in a higher level language in less
than half the time and you're not loosing some "critical piece" then thats the way it should be done. Unfortunately, we're lagging well being PC
languages in this respect but at least we are taking some steps foward.

>RLL is so flexible it can successfully mimic state-type blocks and
>sequence-type functions. I guess my opinion is clear, but my main
>point is I don't see the need to change when no obvious gains are
>apparent. If it is an issue of flavor of control instead of function,
>then OK. I do vigorously reserve the right to be wrong, and will
>listen to thoughtful comments and ideas on this subject.

Again, I think its an issue of development time. A higher level language(s) may significantly decress the development and debug time (and theoretically, program maitence time). I imagine much the same was said about programming in assembly years ago ("what could possibly be the benefit, assembly is just as good and faster"), in fact if you look hard enough some people are still saying it. If you truely don't see a gain using a higher level language then either your using the wrong language (or combination thereof) or you're using it improperly. No offense intended, of course, I base that upon my personal experience and time comparisons done by my company. I don't think many of the languages currently offered make the case any easier, most of the ones I've seen are poorly implemented when it comes to saving time and increasing productivity.

Personally, I found the authors examples of state language very poor. I think state languages excel when your "looking at the big picture" as it
were. A top down view of the necessary sequences, not a collection of "goto" statements and lower level code (as was presented). Having been spoiled on APTs SFCs, I can understand your distrust of any benefits of state language, given the example.

SFCs (properly implemented) are the missing link between the automation world and a automation solution using another higher level languages such as C. To the best of my knowledge, nothing like them exists on the PC (not including automation languages of course :). They can be a very powerful tool. The best implementation I have seen so far is with APT. Still, I wouldn't even consider using them as the only weapon in my arsenal (I have seen people try it, It was bad, VERY bad). A wise man once told me that software languages were like "tools on a tool belt [you'd never guess right], you dont use a screw driver to drive a nail, you use a hammer". I know this is a somewhat superficial treatment of the subject of programming languages (like the authors, in my opinion) but I'd be happy to elaborate on any points I've raised.

Hope everyone has a nice Holiday,

Richard Higginbotham
Controls Programmer
ISD
 
V

Vladimir E. Zyubin

Hello Michael,

Tuesday, September 05, 2000, 12:28:11 AM, you wrote:

<clip>
MG> On another related note, I happen to have current need of a good
MG> written comparison of different ladder logic sequencing methods to
MG> illustrate the advantages and disadvantages of each to several people who
MG> are not familiar with them. I am looking for something much more detailed
MG> than my brief comments above but have not found anything.
MG> I am not looking for a manual for a specific PLC, rather I am
MG> looking for something which deals with non-trivial PLC programming on a
MG> analytical basis. The general principles are the same regardless of the
MG> hardware. Does anyone know of any such document?


A good enough article can be found at Int. Journal of "Computer Integrated Manufacturing" Vol 11 #2, march-april 1998 ISSN 0951-192X. Article of Sengoda G. Shanmugham and Chell A Roberts "Application of graphical specification methodologies to manufacturing control logic development: a classification and comparison".
the article is about graphical languages... but interesting enough. FB, SFC, LD, graphical clones of the state languages are there. Well readable. The other source for your aim could be
"Review Guidelines on Software Languages for Use in Nuclear Power Plant Safety Systems" ( http://www.nrc.gov/NRC/NUREGS/CR6463/index.htm )
the main advatage of that work is concentration on imperfections of languages used for control (Ada, C/C++, Pascal, LD, FB, SFC, etc.) there is no comparison between the languages in the book, but it can be easily made. Well structurized. Readable.

If you find other interesting sources, please make me aware.

--
Best regards,
Vladimir mailto:[email protected]
 
M

Michael Griffin

>A good enough article can be found at Int. Journal of "Computer Integrated
>Manufacturing" Vol 11 #2, march-april 1998 ISSN 0951-192X. Article
>of Sengoda G. Shanmugham and Chell A Roberts "Application of graphical
>specification methodologies to manufacturing control logic development:
>a classification and comparison".
<clip>
I am not familiar with this publication. Who publishes it?

>The other source for your aim could be
>"Review Guidelines on Software Languages for Use in Nuclear Power
>Plant Safety Systems" ( http://www.nrc.gov/NRC/NUREGS/CR6463/index.htm )
<clip>
I've heard of this before, but I never thought to look at it. It isn't what I want, but it is worth reading anyway. It will take a bit of
time to digest this.

>If you find other interesting sources, please make me aware.
<clip>
I'm still looking. I've considered writing something, but I don't want to if someone has already done this (and quite possibly done a much better job of it than I could).
If anyone else has any other suggestions, I and several other people would be very interested.


**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
R
I appreciate the thoughtful replys to my initial message. I do appreciate the points raised, esp. the analogy of higher level languages versus assembly. My PC projects are done in C/C++ and VB and I would not consider using assembly language to write the bulk of the code, although I have used and am glad of the ability of C to allow me access to assembly inside inside C's environment.

I find that I apparantly don't know enough about State languages and need to get more familiar with them before I attempt any intelligent replys/discussions. I am especially curious about how state languages deal with the many varieties of IO hardware and how much lower-level control I might have, should I need it.

I will read all further comments and will be boning up on state.

Thanks,

Ralph Kitts
 
V

Vladimir E. Zyubin

Hello Michael,

Thursday, September 07, 2000, 10:11:51 AM, you wrote:

MG> At 19:47 06/09/00 +0600, Vladimir E. Zyubin wrote:
MG> <clip>
>>A good enough article can be found at Int. Journal of "Computer Integrated
>>Manufacturing" Vol 11 #2, march-april 1998 ISSN 0951-192X. Article
>>of Sengoda G. Shanmugham and Chell A Roberts "Application of graphical
>>specification methodologies to manufacturing control logic development:
>>a classification and comparison".
MG> <clip>
MG> I am not familiar with this publication. Who publishes it?

Taylor&Francis Ltd, One GunpowderSquare, London publishes that journal. "The journal publishes reffered papers relating to Comp. Int.
Manufacturing in a wide variety of manufacturing environments..." etc.
http://www.tandf.co.uk/journals/tf/0951192X.html
There is an ability to order the article from the site... Hm. A bit expensive from my point of view... :) But the lack of ads pressing is guaranted. ;-)

>>The other source for your aim could be
>>"Review Guidelines on Software Languages for Use in Nuclear Power
>>Plant Safety Systems" ( http://www.nrc.gov/NRC/NUREGS/CR6463/index.htm )
MG> <clip>
MG> I've heard of this before, but I never thought to look at it. It
MG> isn't what I want, but it is worth reading anyway. It will take a bit of
MG> time to digest this.

The research of various languages was made from safety viewpoint. But such things as reliability, maintainability, etc. are very important and affect on effectivity of program creation. Obviously.

>>If you find other interesting sources, please make me aware.
MG> <clip>
MG> I'm still looking. I've considered writing something, but I don't
MG> want to if someone has already done this (and quite possibly done a much
MG> better job of it than I could).

Inspite of actuality that kind of material is hard to find. ;-) Who will sponsor the research? ;-))) Maybe OpenPLC? He-he-heh...
But only a novice that doesn't know the real situation may have such illusions. ;-))
So, if not you then who? :)

--
Best regards,
Vladimir mailto:[email protected]
 
J

Johan Bengtsson P&L Automatik AB

Ok, I know I have said this before, but anyway:

SFC and ladder are solving two different needs, it solves different problems.

Sure enough SFC can be implemented using ladder and therefore everything you can do in SFC can be done in ladder.

For a problem where SFC is better than pure ladder it is easier to use that - cutting developement time, but for a problem where SFC isn't easier it adds to development time
instead. (This statement of does course not count the fact that the one implementing might be more used to one of these).

If SFC is used, don't even look at the ladder program (if it is converted to that and implemented using ladder), it is as looking at the machine code when the program is written in C
- debugging using the C source code is easier than debugging using the machine code.


/Johan Bengtsson

----------------------------------------
P&L, the Academy of Automation
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
Top