STL x Ladder

J

Thread Starter

Juan de Arajo

Is there any advantage to program with STL instead of Ladder to Siemens PLC with the objective of save memory ?

Juan
 
M

Michael Griffin

No. Statement list and ladder are simply different visual representations of the same instruction codes.

A ladder program will always translate into statement list, but the reverse is not always true because of limitations of the patterns the programming software will recognise. Also, with some families of Siemens PLCs
using some programming software, there are some instructions (not commonly used) which are not available in ladder mode.

However, how compact your program is depends more upon how well written it is (although smaller is not necessarily better). A program which is easy to read and understand is more likely to function correctly with less wasted code. Ladder is normally easier to read than statement list.
For example, I had to add some new features to a small machine a few years ago. The original program was a statement list monstrosity which I gave up trying to reverse engineer. I wrote a whole new program in ladder. The new
(ladder) program, with the new features was one eighth (1/8th) the size of the original (statement list only) version.

**********************
Michael Griffin
London, Ont. Canada
**********************
 
G

Gilles Allard

>Juan de Arajo wrote:
><clip>
>>Is there any advantage to program with STL instead of Ladder to
>>Siemens PLC with the objective of save memory ?
><clip>

> No. Statement list and ladder are simply different visual
> representations of the same instruction codes.

While the statement is true for boolean logic (contacts), I found that STL is a lot more efficient than ladder logic when you need math instructions (boxes) or other non-boolean instructions. My experience with S7 shows you can save 50% of memory (and processing time) when you use STL. I agree that ladder may be more
readable but the best compromise is to mix both languages. With STEP7 you can easily hide complex logic in a STL FC while leaving I/Os and boolean logic in ladder.

> For example, I had to add some new features to a small machine a few > years ago. The original program was a statement list monstrosity which
> I gave up trying to reverse engineer. I wrote a whole new program in
> ladder. The new (ladder) program, with the new features was one eighth
> (1/8th) the size of the original (statement list only) version.

There is a trend among machine manufacturers to develop generic programs where all options and features are handled by the same program. This may ease manufacturer support (only one program to
maintain) but it may be a nightmare for the end-user; how do you understand the usefulness of a block of code if you do not even know that the optional feature exist? From the end-user side, maintenance is easier with a simpler program.
It's the opposite for the manufacturer.

Gilles
 
M

Michael Griffin

At 11:11 19/11/01 -0500, Gilles Allard wrote:
>---------- Forwarded message ----------
>Juan de Arajo wrote:
><clip>
>>Is there any advantage to program with STL instead of Ladder to
>>Siemens PLC with the objective of save memory ?
><clip>

<clip>
>> No. Statement list and ladder are simply different visual
>> representations of the same instruction codes.
>
>While the statement is true for boolean logic (contacts), I found that
>STL is a lot more efficient than ladder logic when you need math
>instructions (boxes) or other non-boolean instructions. My experience
>with S7 shows you can save 50% of memory (and processing time) when you
>use STL. I agree that ladder may be more readable but the best
>compromise is to mix both languages. With STEP7 you can easily hide
>complex logic in a STL FC while leaving I/Os and boolean logic in
>ladder.

I agree with you, but with the following clarifications. Boolean logic is generally the bulk of a typical program. The math and other special instructions are typically only a small percentage. The sort of saving you are referring to would not apply over the whole of a typical program, but rather only over a very small part of it.
The sort of logic which is best done as a STL FC is usually things like calculations, conversions, and other similar internal logic or algorithms. The FC should generally receive its data through parameters, and it should perform a single, well defined function. Experience and good judgement can tell you how much and how far to bend this rule in practice.
These sorts of applications of STL in FCs (or FB if you are using an
S5) don't typically cause problems. Where questions such as the one which originated this discussion often arise is when someone is considering writing the entire program in STL and nothing at all in ladder under the mistaken belief that because the ladder is easier to understand, it cannot be as efficient as the STL. This often results in programs which no-one but the original author can read without great difficulty.


>There is a trend among machine manufacturers to develop generic
>programs where all options and features are handled by the same
>program. This may ease manufacturer support (only one program to
>maintain) but it may be a nightmare for the end-user; how do you
>understand the usefulness of a block of code if you do not even know
>that the optional feature exist? From the end-user side, maintenance is
>easier with a simpler program. It's the opposite for the manufacturer.
<clip>
I have seen this problem at its most extreme not with a standard OEM programs with options, but where someone was attempting to adapt a standard "boilerplate" program to fit all custom applications. The example I cited was one such program. This approach is typically only successful when applied to a range of otherwise similar machines. The enormous size of the original program was largely due to the amount of code necessary to force this "boilerplate" into the particular application. Code re-use is supposed to fulfill a purpose. It shouldn't be a goal which is pursued for its own sake.

**********************
Michael Griffin
London, Ont. Canada
**********************

 
V

Vladimir E. Zyubin

Hello Michael,<br>
<br>
<p>
MG> "Vladimir E. Zyubin" wrote:<br>
>>Also... There is the mistaken belief that the ladder is easier to understand...</p>
<p>
MG> A typical rung of ladder is easier for someone who isn't a full time<br>
MG> programmer to understand than STL is. I base this on what the electricians<br>
MG> and others whom I work with have told me. I have heard this from Germans,<br>
MG> Poles, Italians, Russians, Romanians, Chinese, and others as well as<br>
MG> Canadians so I don't think this is an opinion which is peculiar to people<br>
MG> who learned their trade around here. I expect that most people on this list<br>
MG> would have the same opinion.</p>
<p>
IMO. the right form of the statment(the form anybody ought to agree with) could be: the ladder is easier to understand by electricians, when the ladder describes both simple("without memory", "small sized") and "bit handling" algoritms...</p>
<p>
Recently there were the discussion about implementation the "SFC-style" of the programming in the LD... I think we all remember it... Does sombody think some electricians could easy understand this kind of algorithms? - Never. Total headache... that leads to insanity! ( IMO )</p>
<p>
>>I am sorry, but your connotative statement is far away from an obvious one...<br>
>>OK. STL has no "bit handling operations"... the ladder has no "word handling<br>
>>operations". Just two invalid languages...</p>
<p>
MG> STL "has no bit handling operations"? What about A, AN, O, ON, S, R,<br>
MG> =, etc.? Virtually every ladder I can recall seeing (even back to the PLC/2)<br>
MG> has plenty of word handling instructions as well.</p>
<p>
according to the IEC(6)1131-3 there were no the bit handling operations in ST... in the 1998 at least... (and it was the only argument for the IL existance... from technical point of view).</p>
<p>
Well... I admit that there was the Great Revolution in the standard... and the operations were inserted in the syntax.... but I am not sure... because of the notation for the "operations" (A, AN, O.. etc.) I suppose it is a set of functions introduced by a vendor who has enough brain to enhance the standard(the ST) with this obviouse means ... (BTW, those of functions are available in any language... a lot of years ago I personaly wrote those functions in Fortran... via operators: divide, multiply, etc... My reminiscence: It was a big headache and big problems with the executive efficacy)</p>
<p>
And again: According to my fillings the IEC(6)1131-3 community believes that for the "bit handling operations" the programmers should use the IL... ;-)</p>
<p>
So, it is a set of _functions_, not of _operations_. Alas.</p>
<p>
Please have a look at the table:
<pre>
==================
TABLE 55 - Operators of the ST language
No. Operation Symbol Precedence
1 Parenthesization (expression) HIGHEST
2 Function evaluation identifier(argument list)
Examples: LN(A), MAX(X,Y), etc.
3 Exponentiation (Note 2) **
4 Negation -
5 Complement NOT
6 Multiply *
7 Divide /
8 Modulo MOD
9 Add +
10 Subtract -
11 Comparison < , > , <= , >=
12 Equality =
13 Inequality <>
14 Boolean AND &
15 Boolean AND AND
16 Boolean Exclusive OR XOR
17 Boolean OR OR
LOWEST
</pre>
<p>
NOTES<br>
1. The same restrictions apply to the operands of these operators as to the inputs of the corresponding functions defined in 2.5.1.5.<br>
2.The result of evaluating the expression A**B shall be the same as the result of evaluating EXPT(A,B) as defined in table 24.</p>
================================<br>
<br>
<p>
MG> Both STL and ladder have lots of instructions for twiddling bits and<br>
MG> bytes. This isn't their failing. Where they lack is in ways of seeing the<br>
MG> bits and bytes in a larger context. The objective after all isn't to just<br>
MG> manipulate bits, it is to solve an overall problem - to make the machine do<br>
MG> something useful. This 'something useful' requires logic which spans many<br>
MG> rungs of logic, whether ladder or STL. Neither method is of any help in<br>
MG> providing a broader view of what is being attempted.</p>
<p>
I think you aware of my opinion about the standard... Just to remind:</p>
<p>
In the hands of PLCopen, the standard calls up thoughts of the tower of Babel.</p>
<p>
--<br>
Best regards,<br>
Vladimir<br> mailto:[email protected]</p>
 
F

Friedrich Haase

Moin Mr. Zyubin,
moin Mr. Griffin,
moin all,

just a minor correction. Handling boolean operands IS contained in IEC 61131-3, since ever (>1988 or so). See "Table 55 - Operators of the ST
language" of IEC.

In IL you use AND, ANDN, OR, ORN, XOR etc. Some vendors use other mnemos (see below.)

In ST you use the operators AND, OR, XOR, NOT with boolean operands. Pretty much the same as in Pascal or C (with different mnemos.)

Here a sample of a function block which toggles a BOOL output at every rsing edge of a BOOL input.

(* ST version *)
FUNCTION_BLOCK ToggleOnEdge
(* toggle BOOL output with each input rising edge *)
VAR_INPUT
IN : BOOL R_EDGE;
END_VAR
VAR_OUTPUT
Q : BOOL;
END_VAR
Q := Q xor IN;
END_FUNCTION_BLOCK

(* IL version *)
FUNCTION_BLOCK ToggleOnEdge
(* toggle BOOL output with each input rising edge *)
VAR_INPUT
IN : BOOL R_EDGE;
END_VAR
VAR_OUTPUT
Q : BOOL;
END_VAR
LD Q
XOR IN
ST Q
END_FUNCTION_BLOCK

(* ladder diagram version *)
FUNCTION_BLOCK ToggleOnEdge
(* toggle BOOL output with each input rising edge *)
VAR_INPUT
IN : BOOL R_EDGE;
END_VAR
VAR_OUTPUT
Q : BOOL;
END_VAR
|
| Q IN Q
+---] [---+---]/[---+---( )---|
| |
| Q IN |
+---]/[---+---] [---+
|
END_FUNCTION_BLOCK

regards
Friedrich Haase
 
J

Johan Bengtsson

If my memory doesn't serve me too badly bit handling operators is all there is. That means: if you use AND OR and so on you get bit handling instructions. At least it is so for the other languages and I really think it is like that for ST too. Right now I don't have access to my copy
of the standard so I can't verify it, unfortunately...


/Johan Bengtsson

Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
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/
----------------------------------------
 
R
Some very interesting comments here. I think to go back to the original question. STL is more efficient due to the fact that STL is the closest
language to the machine code, thus less overhead. Every other programming language whether LAD,FBD,SCL,CFC or Graph all create more 'overhead' thus not as efficient. STL is of course the more difficult language to troubleshoot, but the benefits are fairly clear. STL takes full advantage of how the S7 PLC
actually operates for example being able to directly access Address Registers and Accumulators. If we were to only consider 'overhead' below is a list in order of 'overhead' (least to greatest)

STL
LAD
FBD
SCL
CFC
S7 Graph
S7 Charts

In my experience these languages all offer certain benefits. Generally speaking every project that I have done I will use a collection of different languages for the different blocks to take full advantage of what ever type of
function that I may be writing. To me this is the benefit. Just some personal thoughts, I am sure there are many different viewpoints out there.

Roger Hill
Software Geek
 
Top