Ladder vs STL

[Peter Nachtwey]

Siemen's LD implementation is crippled.

It isn't fair to say that Siemen's version of LD respresent all implementation of LD. The Siemens LD implentation is a kludge that must have been added for the North American market.
It is obvious that the S7 is designed to run STL and anything else is just an after thought. Just compare the STL generated from LD with the text required to enter a Rockwell rung. When entering ladder using text on a Rockwell rung there is no need to keep track of a BR register.

Its a shame that unknowledgible endineers sometimes enforce rules where STL is not allowed at all, I can understand having the basic code in ladder but sub-routine functions are far better in STL.

This is shear stupidity. Ask the engineer to do indirect addressing in LD.

The brackets are a common feature of many languages like basic, C, fortran etc. The ( cause the current value to be pushed on a stack. This is very similar to the Automation Directs PUSH instruction. The ) cause the value on the stack to be popped off the stack and used as an operand.

Note the AB NXB instruction also pushes the current state on the stack. The BND instruction causes the save results to be popped off the stack and 'OR'ed together.

STL is more efficient than ladder because the intermediate results don't need to be stored and reloaded between rungs. However, I wonder if Rockwell's ladder code is so optimized that it would minimize reloading parameters that have already been loaded in that rung. I know that is the way I would do it.

 

[S7Guy]

For the example shown, the BR bit is always forced on so the blocks in the ladder will always execute. When performing other arithmetic, *D for example, the ladder version will generate code to check for overflow and if an overflow occurs, it will not execute blocks further along the same rung. If you perform the arithmetic using STL, it is up to you to decide what to do in the event of an overflow.

Yes, but I hold my code to a higher standard than "it doesn't blow up". Anyone should clamp and condition variables first before math is performed anyway, so an overflow condition would never occur. To rely on a BR bit seems kind of scary, especially since you'd have to write code to handle the condition anyway.

In the real world, I actually would have done something like this:

L PIW760
T #tA

L #tA
L #Minimum
>=I
JC max
T #tA
SET
= #MinLimitWarning
max: L #tA
L #Maximum
<=I
JC ok
T #tA
SET
= #MaxLimitWarning
ok: NOP 0

Proceed with math here....

It is obvious that the S7 is designed to run STL and anything else is just an after thought.

Yes, no doubt. But, I have to say their FBD representation isn't too bad. I like it for complex boolean logic, and it supports more instructions (i.e. X).

 

[L D[AR2P#0.0]]

For those of you using ladder for maths, here is a simple example that shows the difference between ladder and STL. For the ladder version, the double integer multiply results in an overflow and the DI_R instruction is not executed and rTemp1 is left at it's previous value. For the STL version, the DTR is executed resulting in a large number in rTemp2.

 

[Sergei Troizky]

The discussion subject “Ladder vs STL” is incorrect by definition.
Ladder is not a programming language but only a method of visualization.
The programming language being visualized by classic ladder is called IL (instruction list).
Hence, the discussion subject should be either “STL vs IL” or “Graphical Interface vs Text”.
Let us consider both.

STL vs IL.
These are different level languages and should not be compared at all.
IL is something of the Assembly language level, while STL should be classified as a programming language of high-level corresponding to at least Pascal.
Of course, programs in high-level languages are more compact thanks to preprogrammed advanced instructions.
The final code, though, will never be as compact as it potentially can be in the Assembly.
By the way, the latter is the concept of the RISC processors.

Graphical Interface vs Text
I’ve never known anybody preferring IL to Ladder view on computer screen.
For me, it would be like listening to a picture verbal description instead of seeing it.
Or tell me, how many of you do use a navigator in his car in text mode instead of map view?



Below are some statements from this thread with my comments.

PeterW:
“STL can be daunting when you first see it, but once it clicks in your mind you will love it.”
Being a long time ladder user, I made more than one attempt to discover STL advantages.
Nobody ever could answer this simple question.
There are usually only two arguments:
- It is more common in Europe.
This is neither advantage nor disadvantage for me.
- It decreases programming time.
Even if so (which is questionable for small projects), it will increase the online debugging time.

PeterW:
“A good way to learn the basics is to write code in ladder, then switch it to STL and see what comes up.”
This is actually decompiling from low-level into high-level language and cannot be used for judgement about the quality of the code.

S7Guy:
“But the point is that for math (and other non-bit functions) STL is more efficient and quicker to write.”
Quicker to write- probably, if the fragment is large enough.
More efficient- no. Compilation from higher-level language cannot be more efficient then a good text in low-level language.

S7Guy:
“Try the same thing in ladder. Not only will you need about ten times as many instructions, it will take longer, and it will be no easier to understand.”
As I said above, programs in high-level languages are more compact thanks to preprogrammed advanced instructions.
However, I doubt that STL visualizes complex branched logical conditions better than ladder.

LadderLogic:
“I guess the example above just shows the inefficiency of Siemens ladder implementation and not necessarily the advantage of STL.”
Fully agree.
And this answers LD[AR2,P#0.0]'s argument in his example.

Peter Nachtwey:
“Ask the engineer to do indirect addressing in LD.”
I do this many times every day. What’s wrong with it?


My opinion is: if the STL software package features a ladder view option with proper bi-directional conversion (compiler/decompiler), nothing could be better. But is there one?
Otherwise I remain a ladder user because of the following:
- There is no better visualization of complex branched logical conditions.
It is good for offline programming or understanding and becomes priceless during monitoring.
- Much less limitations for online editing.
- No (or much less) bothering with data types.
If I use a symbol for a contact or coil it is obviously boolean. Why bother declaring this?

P.S. All the above is only IMO.

 

[LadderLogic]

- There is no better visualization of complex branched logical conditions.
It is good for offline programming or understanding and becomes priceless during monitoring.
- Much less limitations for online editing.
- No (or much less) bothering with data types.
If I use a symbol for a contact or coil it is obviously boolean. Why bother declaring this?

I tend to agree with Sergey's assesment (few things set me off more than Siemens' idea of a one-shot as a function block - which, unfortunately, made it into IEC standard!). However, I love or would love to be able to include block of STL-type code into my ladder programs: with text representations of If..Then..Else logic, For...Next loops, math functions, string hadling and things like that.

Everything is good where it is good. Nothing is good for everything.

 

[Peter Nachtwey]

Who's STL?

The discussion subject “Ladder vs STL” is incorrect by definition.
Ladder is not a programming language but only a method of visualization.

So you are saying the original Modicon and AB only visualized solutions?
Give us a break.

The programming language being visualized by classic ladder is called IL (instruction list).

What language did ladder visualize before IL was invented? Inquiring minds want to know.

Hence, the discussion subject should be either “STL vs IL” or “Graphical Interface vs Text”.
Let us consider both.

You must be confusing Siemen's STL with Mitsubishi's STL. Siemen's STL is definitely text.

STL vs IL.
These are different level languages and should not be compared at all.
IL is something of the Assembly language level, while STL should be classified as a programming language of high-level corresponding to at least Pascal.

I did a search. You are a Mitsubishi programmer. STL is Mitsubishi is a graphical language but not Siemens STL. The context of this thread has been Siemens based so the STL that everyone is talking about is similar to IL.

I’ve never known anybody preferring IL to Ladder view on computer screen.
For me, it would be like listening to a picture verbal description instead of seeing it.

This is slightly OT but haven't you ever viewed Mitsubishi ladder in text format? I did it all the time because I can type much faster than I can move a mouse, hit a key, move the mouse and hit another key.
The Mitsubishi actually does a better job than the S7 at switch between LD and IL.

Below are some statements from this thread with my comments.

PeterW is a S7 programmer so he isn't talking about Mitsubishi STL, he is talking about Siemens STL. Here is a test, is S7Guy talking about Mitsubishi or S7 programming?

Peter Nachtwey:
“Ask the engineer to do indirect addressing in LD.”
I do this many times every day. What’s wrong with it?

Not on a S7 you don't. Mitsubishi indirect programming is rather easy and very effective.

LadderLogic, F_TRIG and R_TRIG are FBs because they must remember state. Rockwell's OSR on ONS must remember state to. So does Siemens FPs. I don't understand the complaint. They all must do the same thing. I do agree it is a little heavy handed to make one declare a one shot BUT before one shots we implement one shots and latches in ladder using normal coils. You don't need to use R_TRIG and F_TRIG or any of the one shot blocks. When I do ladder programming I know I often just do it the way I learned back in the 70's when it was really relay logic.

 

[LadderLogic]

LadderLogic, F_TRIG and R_TRIG are FBs because they must remember state. Rockwell's OSR on ONS must remember state to. So does Siemens FPs. I don't understand the complaint. They all must do the same thing. I do agree it is a little heavy handed to make one declare a one shot BUT before one shots we implement one shots and latches in ladder using normal coils. You don't need to use R_TRIG and F_TRIG or any of the one shot blocks. When I do ladder programming I know I often just do it the way I learned back in the 70's when it was really relay logic.

I know, Peter. My complaint is about the IEC standard that dictates representing them as bulky rectangles rather than small and easy to read arrows. For better or for worse, a one-shot is such a frequent and an indispensible feature of any ladder code that an exception could have been and should have been made. Even if they are, in essence, function blocks with internal state.

What has become a standard was, unfortunately, derived from not the best version of LD, namely, Siemens'.

 

[Sergei Troizky]

Peter,
I am not familiar with Siemens and Modicon, but I repeat and insist that in Mitsubishi and AB ladder and IL are synonymous representations of each other.
And I doubt they were invented separately.
I remember handheld programming consoles with IL display while the paper documentation used to be in ladder.

All your other arguments simply state that Siemens is distinct and not that great.
I know this and never use it (thanks God, I am able to choose brands for most of our company projects).

And yes, I always prefer ladder view in Mitsubishi, as well as in any other brand I use..

By the way, STL in Mitsubishi may mean State Lock used in SFC programming technique. This is not a Structured Text Language and has nothing with the subject.

 

[PeterW]

All your other arguments simply state that Siemens is distinct and not that great.
I know this and never use it (thanks God, I am able to choose brands for most of our company projects).

This is what I mean't about unknowlegdible engineers, I don't know much about Mitsibushi PLC programming so I make no comment on it.

For the past year, since I swapped Europe for North America I have exclusively used AB Control Logix and most every day I swear to myself and wish I was using Siemens.

Its not that AB is no good, quite the opposite, its just I am used to using Siemens and prefer it.

Siemens is distinct and it is really great to program, quite opposite to your conclusion (where from you had that I do not know).

Maintenance engineers are used to looking at electrical diagrams though and through that they understand (mostly) ladder logic. Because of that I agree that the main control part should be ladder if its designed with local maintenance in mind, BUT STL has to be allowed.

 

[Peter Nachtwey]

PeterW, I think Sergei was confused. He is a Mitsubishi programmer. Mitsubishi STL is similar to SFC. That explains Sergei's comments. It should have been obvious that Sergei's comments were not about Siemens STL.

 

[ivo.maenen]

I have always used S5 and S7. Since last year september I'm also using Mitsubishi GX-IEC-Develloper.

I have always heared comments that Siemens has difficult and way-over-the-top software but after a half year I think for my tast the GX-IEC-develloper is not as good and not as easy to use as STEP7. But that's my opinion.

By the way, talking about mitsubishi; maybe somebody can tell me if it is possible (and how) to switch between absolute and symbolic adresses (global vars) in GX-develloper (6.10) and how to switch between ladder and STL.

 

[Sergei Troizky]

PeterW, I think Sergei was confused. He is a Mitsubishi programmer. Mitsubishi STL is similar to SFC. That explains Sergei's comments. It should have been obvious that Sergei's comments were not about Siemens STL.

No. Peter, I was not confused.
I meant exactly Structured Text Language in my posts.
All my arguments, however, were brand-independent., something like Ideal STL vs Ideal Ladder.
I never tried to judge Siemens STL vs Siemens Ladder simply because I am not a Siemens user.

 

[Peter Nachtwey]

No. Peter, I was not confused.

In the Siemens word STL is statement list not structure text language.
Joltron, PeterW and S7Guy were using Siemens terminology. The Siemens version of structured text (ST in IEC) is SCL.

You are confused. I know all these details because I have programmed AB, Siemens, Omron, Reliance, Mitsubishi, AD and Modicon PLCs. I have an electronic zoo at Delta. Since we want our products to get a good grade at 'playing well with others' we have had to buy all these PLCs for product testing. I have two different models of Mitsubishi PLC, a FX2N and a Q series, and 2 or 3 different versions of S7. I have paid a lot for this knowledge.

 

[Sergei Troizky]

Hmm,
If STL is not Structured Text in Siemens then everything I wrote here is offtopic (still fully in power though).
I cannot delete it anymore- disregard it.

P.S. By the way, what is electronic zoo at Delta?

 

[Peter Nachtwey]

P.S. By the way, what is electronic zoo at Delta?

It us our collection of PLC and HMIs that make sure our product plays well with others.