Which has more portion in your S7 program?

LAD or STL?

or some masters use pure STL?

Definately, I can use LAD only in S7, I tried, and found that's the stupid way.

What do you mean more portion??? What takes up more memory???

Dave

I mean in a program, totally how much percentage is LAD and how much percentage is STL.

At least when it's downloaded into PLC, when it's been executing, it doesn't matter what kind of program source it is, it's machine code I think.

So, if that's true, it means STL has far more efficiency than LAD, like C vs Basic, because it's closer to machine code, and from LAD you'll have some standard code compiled which is no use for program.

And, STL program should always smaller than LAD. The same thing happened in PC program. You can see the size difference - if it's a C/C++ program written, it's small.

I Agree. STL is more powerful LAD and is alot more efficient. PLus it reduces you FC's and your FB's sizes incredibly. They say alot of the overhead in LAD programing in S7 is due to the graphics.

Dave

OK, I try to keep my logics in LAD.
The simplest math and move instructions I also keep in LAD.
If it gets a bit complicated i use STL for math and memory functions.
All in all I have roughly speaking 75% LAD and 25% STL.

I dont find LAD stupid at all.
The penalty on execution time and memory usage is insignificant. What you get is the advantage to interpret and understand a LAD network in a glimpse (instantly). This is invaluable when debugging online. If there are many branches in a logical network then with STL it will take at least some time to read + understand it.

Sorry, what I mean stupid is for some complex mathmatics it will be 3-4 times longer and hard to understand in LAD. Anyway, I'm a LAD guy with AB experience so I just wandering how much STL a S7 guy will use.

Thanks.

I don't use ladder. I only use STL and FBD.
FBD for simple motor control and functionality.

STL I use for calculation and data functionality (DB arrays, pointers etc).

It depends on the type of application on how the percentage are divided.

Oh do I agree. I am doing a program in S7 as we speak and really hate the fact that Siemens does not have a compute/math block like AB has. You don't know how many times I swear about this daily.

Dave

Who are they?

dmark88 said:

IThey say alot of the overhead in LAD programing in S7 is due to the graphics.

Dave

Click to expand...

Who are they? Graphics have nothing to do with the size of the code. There is no graphics in a .awl file. It isn't the graphics that cause LAD to be inefficient. It is the enable and ENO that does. STL and SCL doesn't have blocks that need to be enabled.

I think(know) the Siemens implementation of LAD is crippled. There is no indirect addressing in LAD without a LOT of pain. There is an example in the Berger books.

Does FBD programming allow indirect addressing? If so, how?
Is FBD efficient or does it have the same problems as LAD does with keeping track on the enable inputs and outputs.

STL is the most efficient way to program an S7 IF you only consider execution speed. The JL instruction makes executing state machines very efficient. The FCs and FBs make organizing code for big projects easy. However, STL is not for the average maintenance guy. STL is good for the code architects and power users. STL is like assembly language on a micro controller but it has a very irregular instruction set. The STL compiler itself has a flaw the bothers the me allot. I can't use symbollic hames everywhere like I can in assembly language. This flaw requires that one uses hard code constants way too often which is not good.

Compute blocks are not necessary if you feel comfortable using STL. Functions that get used many times in a program can alway be put in a FC or FB.

I recently got a copy of SCL. I think that is a good compromise between efficiency and ease of writing code. I haven't had time to play with it yet.

For our own product, we started with motion blocks and compute blocks. Once you have compute blocks you really don't need anything else. We call compute blocks expression blocks because they may not do any computing at all. One could just write
A := B to move a variable from B to A. Who need move blocks when you have expression blocks?

Peter Nachtwey said:

Who are they? Graphics have nothing to do with the size of the code. There is no graphics in a .awl file. It isn't the graphics that cause LAD to be inefficient.

Click to expand...

Actually, if you look at the code which S7 translate automatically from LAD (which you saved in .awl file), it's different from what you write in STL.

I think that's what Dmark means "Graphics". To form a standard LAD "graphic", it need some extra code and spend lots of time just doing all those extra L (load) and T (tansfer) to forming LAD. You can consider each LAD instruction is like a small block unit which has input and output, for general use, it has to have lots of extra code. That's the reason LAD consumes lots of processing time and memories.

- That based on S7 machine code is very similar to STL. Anyway, S7 use STL interpret everything, include LAD, include FBD.

Another thing is, for some application like processing or stream line or sequence, does S7 have some language tool to do that like AB SFC(sequential function chart) or STL only ?

Does FBD programming allow indirect addressing? If so, how?
Is FBD efficient or does it have the same problems as LAD does with keeping track on the enable inputs and outputs.

Click to expand...

Given that LAD and FBD are virtually 100% interchangeable (there are a few exceptions but I can't remember them off-hand) and that FBD has the same EN/ENO logic that LAD has, I wuld guess that as far as code efficiency is concerned, they're probably pretty much identical.

Another thing is, for some application like processing or stream line or sequence, does S7 have some language tool to do that like AB SFC(sequential function chart) or STL only ?

Click to expand...

S7 has two S/W packages for this, S7GRAPH for SFCs and Hi-GRAPH for State Machine logic.

I am with Jesper on this one...

I will do as much as I can in LAD, then only dip into STL if I need to.

That's the way I always work and will continue to do so.

Paul

Would anyone like to give up this forum with all its wonderful images, colours, drawings, embedded files etc and go back to a black and white text-only display of a single message at a time?

Who remembers EDLIN, that marvellous text editor?
Sure it was small, and the whole operating system fitted on a single 360K floppy or whatever, and everybody used ASCII characters to try to make pretend graphics, and ...

For me, I place readability and comprehension at the top of my list for controller languages. And especially comprehension by the guy who's going to have to look at my code after I've gone. I want lots of images, pictures, graphics, visual things, and PLCs are getting there. If you told someone 20 years ago that a PLC would have 20MB memory, and the programming software would take 1GB on a hard disk (sorry, would that have been a Winchester?) they would have laughed at you.

If you can do the same task clearly and explictly in a 'visual' language (FBD or LAD) why would you want to do it in a short, terse, complex language like STL. Note I said 'If'. I accept that many manufacturers' LAD or FBD do leave out some instructions that I agree are fundamental. But we have to look at the history of computing and programming. The trend has always been for larger applications to pull through the development of faster and more capable CPUs or microprocessors. And text gives way to graphics on all sides. And the human interface becomes the dominant design feature rather than the code beneath. PLCs and industrial control systems generally operate on much longer generations than PCs but we're going that way eventually.

Ken

The LAD is not a real graphic programming environment, it only shows logic clearer than text.

Let's look at PC programming, after 20 years, the most important change is the interface, is not programming language. Programmer still using text editor - except LabVIEW (it's said is for scientists and engineers).

We have more powerful hardware, processor, memories,... but after all, we need program laguage - still based on text edit. Because there is no better way to do that.

Another reason I ask this question is that I found it's very inconvenience in LAD editing for S7, it's not like AB. I can tell AB is living on ladder logic, and Siemens is living on STL.

There's lots of room for Siemens to improve its LAD, but once it become a pure LAD (like AB does), it will disappear from this world.

Some guys like ladder logic, some guys like statement structure text, you cannot say which one has more advantage or which one is better, they have different usage.

I know that from very begining, everytime when I check Siemens samples, it use STL, on top of that, it cannot show in LAD "graphic", that's why I was thinking if there is someone using 100% STL in program.

- AB's sample also based on text, but it equals ladder "graphic".

I do believe it's no use to talk about which on is better or what the trend is. I just want to know, based on engineering experience, how you S7 guys write a normal S7 program.

Still, there is nobody answer my question: Does S7 have any programming tool like AB SFC?

Thanks everyone.

Take a look back at post #11.

Keith