I am fairly new to Siemens S7 programming so forgive me if I'm being fairly inept here.

I have an application where I have an FC with a UDT as in input parameter. When I call the FC I cannot seem correctly pass the structure to the FC. A section of a DB has been structured to the UDT and it is this area I wish to pass to the FC as an input parameter.

Can anyone out there point me in the right direction?

Thanks

 

We should consider a simple example:

You have "UDT 10" defined.
This "UDT 10" is an input for "FC 11".
"FC 11" is called from "FB 12".
On the other hand you have "DB 13" that has somewhere in the declaration a complex variable named "MyUDT" of type "UDT 10".

Considering the above, in FB12 you should have "DB 13.MyUDT" as input for FC11.
If this is what you have, "MyUDT" will be transferred inside "FC 11" (transparent for you). If "DB 13" is an INSTANCE for "FB 12" it is not necessary to put "DB 13" in front of "MyUDT" as input to "FC 11".

This was a technical explanation. Since you are new to Siemens I think you have some problems with "correctly" monitoring the variables! The code is probably OK.

Use the following procedure to monitor your code:
- Open your subroutine. Click "Debug/Operation" and hit OK (strange step since there is no other option!)
- Click "Debug/Environment" check mark instance DB (left side, about 1/3 from the bottom - sorry I am not online so I can not give you the exact name for this box) and in the lower-right corner enter the DB number where your subroutine is called.
- Now, go online and monitor your subroutine. You will see what is happening in your sbr in the DB you specified. This procedure is very helpful when the sbr is called in multiple DBs!

If you still have problems email me at [email protected]

ValRo

 

This is where I stop buying that PLCs are better because they are understandable by anyone. The S7 system is pretty versatile and can do just about anything you could want, but the programming to do it can be far more complex than most high level languages like C. STL in particular, resembles assembler more than anything else. And the programmer is responsible for all the details, even more so than with a GP programming language. In explaining things to most people, their eyes glaze over about at the concept of instance data blocks. And it seems many (most?) S7 programs are a mix of at least STL and Ladder. Yet they seem to escape the criticism any other suggestion of
non-ladder programming receives. I'm curious why this is? I started to wonder about this as I figured out a couple dozen STL blocks in the middle of a sea of Ladder. It's fairly serious programming.

Regards

cww

 

Hello Curt,

>In explaining things to most people,
>their eyes glaze over about at the concept of instance data blocks. <

Most "people" or most "programmers"? As far as I know, multi-instanced FBs is another point that most "people"
are afraid of (oh, add the use of S7 compiler too). I bet many "people" just run the programming package without reading the manuals or without attending a proper programming course. I bet also many "people" still think
PLC programming means "easy programming" or "amateur programming".

> And it seems many (most?) S7 programs are a mix of at least STL and
>Ladder. Yet they seem to escape the criticism any other suggestion of
>non-ladder programming receives. I'm curious why this is? I started
>to wonder about this as I figured out a couple dozen STL blocks in
>the middle of a sea of Ladder. It's fairly serious programming. <

The "many (most?)" number of STL+LAD hybrid programs depends on "people", not on the PLC itself. Siemens PLC systems are based on STL (or assembler, as you may like to call it), graphic representations like ladder and others are just a shell around STL; this is the way Simatic systems work. If ladder as native language is preferred, integrators can buy controllers other than Siemens (and stop complaining).

best regards
Luca Gallina

 

Hi tecnog

> On August 10, 2004, Curt Wuollet wrote:
>>In explaining things to most people,
>>their eyes glaze over about at the concept of instance data blocks. <
>
> Most "people" or most "programmers"?
> As far as I know, multi-instanced FBs is another point that most "people"
> are afraid of (oh, add the use of S7 compiler too). I bet many "people"
> just run the programming package without reading the manuals or without
> attending a proper programming course. I bet also many "people" still think
> PLC programming means "easy programming" or "amateur programming". <

The argument I keep hearing is that the electrician who has to fix the thing in the middle of the night has a good chance with ladder logic.

Actually, I suspect many would have a better chance with well written Pascal, for example, than with STL. But any mention of high level languages for PLCs or control in general, is shouted down summarily. I'm curious why STL, more difficult in my mind, doesn't raise howls of protest. Nor do Siemens' Object Orientation features. STL as an
Intermediate Language for compilation doesn't surprise me at all. That they expose it to users and have "networks" not representable in LAD or FB chips away at the electrician argument. I _have_ modest programming abilities and it's pretty tedious to slog through. It
certainly wouldn't be my first choice for a large project. I can see it used like inline assembler, to do things the other languages can't or for efficiency's sake. Do schemes other than ladder actually have a chance in the market?

> The ";many (most?)" number of STL+LAD hybrid programs depends on "people",
> not on the PLC itself.
> Siemens PLC systems are based on STL (or assembler, as you may like to call
> it), graphic representations like ladder and others are just a shell around
> STL; this is the way Simatic systems work. If ladder as native language is
> preferred, integrators can buy controllers other than Siemens (and stop
> complaining). <

This might well explain AB's popularity here. Is the mix of automation folks different overseas? More CS oreinted? Or do poeple just use what is provided? It's the contradictions in automation that intrigue me.

Regards

cww

 

<clip>
> The argument I keep hearing is that the electrician who has to fix the
> thing in the middle of the night has a good chance with ladder logic.
<clip>

If you write a program in a mixture of STL and ladder, the electrician isn't typically going to have a problem if the parts he is interested in are all in ladder. Typically, the electrician is interested in the parts which interact
directly with the hardware. The stuff you have to do in STL is generally data or memory manipulation operations which can be encapsulated in FBs (S5) or FCs (S7) with data passed as parameters. You generally don't have to go into these types of blocks for troubleshooting purposes (unless they have bugs).

The reasons why you see see so many S5 programs which are written almost entirely in STL is because of problems with the Siemens Step-5 program editor. It is so cumbersome to use that some people prefer to write a few long convoluted STL segments rather than a larger number of simpler ladder
rungs. This is particularly true of people who are contracted to write a program and then never have to look at it again later. This is also true of people who think that if the logic is hard to understand, they must be smart if they wrote it.

> Actually, I suspect many would have a better chance with well written
> Pascal, for example <

The IEC61131-3 Structured Text language is similar to Pascal.

> than with STL. But any mention of high level
> languages for PLCs or control in general, is shouted down summarily.
> I'm curious why STL, more difficult in my mind, doesn't raise howls of
> protest.
<clip>

What STL offers over Pascal is a format which has one simple instruction per line of code. This allows the programming software to display the current RLO (the accumulated result of boolean operations) on a per instruction basis, which lets you see where the STL logic train breaks (provided the logic does not have too many parallel flow paths for you to decipher). I don't know of a way you could do that readily with Pascal (or Structured Text). Program debuggers which are used with Pascal rely on single stepping and halting on break points. This doesn't fit well with on-line monitoring of cyclically
scanned PLC programs.

STL was also easy to represent on a small screen on a hand held programmer. Not so long ago, portable computers for industrial programming were rare and expensive, and PLC programs were small and simple. Hand helds were cheaper to
buy and adequate for the small programs common in those days.

> STL as an Intermediate Language for compilation doesn't surprise me at all.
> I can see it used like inline assembler, to do things the other languages
> can't or for efficiency's sake. <

STL still exists for historical reasons, not because of any inherent design requirement. The S7-300/400 was designed as the successor to the S5 and uses many of the same concepts, with a number of improvements and changes. There are still STL instructions which have no ladder representation.

Also, as the direct successor to the S5, the S7-300/400 was intended to make it easy for their existing customer base to switch to the new product line. Older customers who want to see STL can still see STL. There are people who haven't progressed from STL to ladder, let alone from ladder to anything more modern.

The S7-200 is a completely different design, and every STL instruction has a ladder equivalent. You can access every feature of the S7-200 in ladder, and the S7-200 has a very complete feature set. Given this, "things other languages can't" is more a matter of the programmer's personal preferences rather than the actual capability of the software and firmware. If you think about what you want the machine to do, rather than how to make your S7-200
program look like an S5 program, you will find there is nothing you can't do just as readily in ladder as you could in STL.

As for "efficiency", STL is no more "efficient" in code execution than is ladder. The PLC executes the same code and STL or ladder are just representations on your computer screen. The only way you could create significantly more efficient code in one format versus the other is if you manage to do the same task with less code. Since boolean operations execute very fast, any significant changes would have to involve using fewer timers or counters or math operations. It is difficult to think of any logic where STL versus ladder would enable such a difference using those types of instructions.

> Do schemes other than ladder actually have a chance in the market?
<clip>

Other schemes exist. There are grafcet (SFC) and state logic. Siemens (since we have been talking about their products) offer them as add-on packages. The reason why these are not more popular probably has more to do with their poor implementation, and the fact that as expensive add-on packages you cannot take for granted that everyone would have them. Siemens markets them as "engineering tools", and as not being for mere maintenance personnel to
understand.

If you want to combine advanced programming capabilities with traditional methods, then you should think of how to combine state logic (or SFC) and ladder in the same program. Such a system should support the the state logic
or SFC at a very fundamental level, not as an "add on" which auto-generates a mass of cryptic STL. People need to perceive the state logic or SFC as being basic PLC instructions - e.g. state logic subroutines contain state logic instructions, and ladder subroutines contain ladder instructions (with no STL being visible at a lower level in either case). People could then program in ladder or in state/SFC or in a combination of the two.

Complex data manipulation for special algorithms or for MMI interaction could be done using a conventional interpreted computer language (e.g. Basic/Python/TCL/etc.) in separate subroutines. These could operate synchronously (as part of the scan) for things like calculations, or
asynchronously (not part of the scan) for things like writing MMI interaction code.

The reason why something like this has a chance in the market is that ladder does things like sequential control or machine mode selection very poorly. There is nothing in ladder which gives a general overview of what a program normally does or what it is *trying* to do at that moment. In other words, what ladder does poorly is the first thing a maintenance person (or anyone else) wants to know about a machine when they are asked to fix it.

Ladder's greatest weakness however is state/SFC's greatest strength. State diagrams or SFC are not difficult to *understand*, they are just difficult to *write* if you have no experience with them.

"Lock-in" applies to programming methods as much as it does hardware or programming software. In order for people to progress to more advance methods, the transition has to be made as smooth and as gentle as possible. They shouldn't have to change to a completely new environment in order to try something new, nor should they have to switch to a completely new method in a single leap. This is why I believe that ladder and state/SFC should be combined in a PLC (or soft logic system) at an equal level.

--

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

 

Dear Curt,

>The argument I keep hearing is that the electrician who has to fix the
>thing in the middle of the night has a good chance with ladder logic. <

I do not understand why an electrician has to fix software in the middle of the night. Would you accept your teeth being patched continuously by a nurse because the dentist didn't do a good job at the beginning? Unless we're talking about simple applications (and being "simple" should lead to no problems at any hour of the day), current PLC applications are not exactly a mere replacement of good old relay-crowded cabinets. A true PLC programmer (and not a sloppy one) is needed for design, developing and troubleshooting. Patching here and there does not solve bad application design or bad software developing. If there's a frequent need to fix problems, I bet it is not the PLC itself nor a programming language issue.

>Actually, I suspect many would have a better chance with well written
>Pascal, for example, than with STL. But any mention of high level
>languages for PLCs or control in general, is shouted down summarily.
>I'm curious why STL, more difficult in my mind, doesn't raise howls of
>protest. Nor do Siemens' Object Orientation features. STL as an
>Intermediate Language for compilation doesn't surprise me at all. That
>they expose it to users and have "networks" not representable in LAD
>or FB chips away at the electrician argument. I _have_ modest
>programming abilities and it's pretty tedious to slog through. It
>certainly wouldn't be my first choice for a large project. I can see
>it used like inline assembler, to do things the other languages can't
>or for efficiency's sake. Do schemes other than ladder actually have
>a chance in the market? <

Yes, schemes other than ladder have really a chance in the market (the dear, well known, worn-out "Ladder vs. Others" thread). just use them where they can really help. SCL (a Pascal-like language) is great for data management and can save a lot of pain but it's absolutely not suggested for pure logic. SFC (Graph7 and Hi-Graph) is great for sequential control but it eats memory which may be precious in small applications. About the subject of this thread "Passing a UDT/Struct to a FC/FB in Siemens S7", UDTs are another powerful feature that must not be feared but rather mastered.

>This might well explain AB's popularity here. Is the mix of automation
>folks different overseas? More CS oreinted? Or do poeple just use what
>is provided? It's the contradictions in automation that intrigue me. <

Contradiction is choosing a specific kind of PLC and pretending it to behave as a different one. AB is certainly a good PLC (as other brands are) with own features and behavior, it is widely used in Europe too. Integrators surely choose it for good reasons (except to ease electricians fixing sloppy programs, I hope...) and to benefit of its specificity. Siemens specificity is STL and OO.

best regards
Luca Gallina

 

<snip>
> Also, as the direct successor to the S5, the S7-300/400 was intended to make
it easy for their existing customer base to switch to the new product line.
Older customers who want to see STL can still see STL. There are people who
haven't progressed from STL to ladder, let alone from ladder to anything
more
modern.
<snip>

I'm little bit an experienced S7 user (5 years or so). I started programming of S7 with LAD (before I worked with AB PLCs). But after few problems I couldn't solve with it I started to use STL. So from my point of view switching from STL to LAD is hard to call "a progress".

<snip>
> As for "efficiency", STL is no more "efficient" in code execution than is
ladder. The PLC executes the same code and STL or ladder are just
representations on your computer screen.
<snip>

That's only partially true. For Boolean instructions STL and LAD are comparable. But with anything else LAD translator (which translates LAD into STL) adds some overhead. Sometimes some 50% of extra code.

Regards,

Jacek Dobrowolski

 

Hi tecnog

On August 26, 2004, tecnog wrote:
> Dear Curt,
>
> On August 19, 2004, Curt Wuollet wrote:
>>The argument I keep hearing is that the electrician who has to fix the
>>thing in the middle of the night has a good chance with ladder logic. <
>
> I do not understand why an electrician has to fix software in the middle of
> the night. <

Because the machine is down and costing a lot and by far, the easiest way to find out what's going on is to look at the program. The object is to find out what mechanical or electrical contrivance is not working as planned, not to fix the software which in most cases has worked for years.

Just thought I should clarify.

Regards

cww

 

On August 26, 2004, Dobrowolski, Jacek wrote:
<clip>
> I started programming of S7 with LAD (before I worked with AB PLCs).
> But after few problems I couldn't solve with it I started to use STL.
> So from my point of view switching from STL to LAD is hard to call "a
> progress".
<clip>

The reason you cannot solve certain problems in ladder is that the S7-300/400 do not have ladder equivalents to all STL instructions. I consider ladder to be "progressing" from STL as the representation is intended to convey the intent of the program more clearly to someone who is unfamiliar with it.

I don't mean to imply that ladder is a perfect or even a good higher level language, it is just better than STL in this respect. The limitations of ladder in the S7-300/400 are limitations in Siemens' implementation of it.

There is a clear trend in the computer programming field towards "higher level" languages. This is due to a trade-off between efficient use of hardware and efficient use of programming manhours (for writing and more important - maintaining) has tilted strongly in favour of economizing on manhours. Just as computer programming has progressed from assembly language to C/Pascal to Java/Python/Perl, PLC programming is "progressing" from STL to ladder to ??? (state? SFC?).

> > As for "efficiency", STL is no more "efficient" in code execution than
> > is ladder. The PLC executes the same code
<clip>
> That's only partially true. For Boolean instructions STL and LAD are
> comparable. But with anything else LAD translator (which translates LAD
> into STL) adds some overhead. Sometimes some 50% of extra code.
<clip>

50% overhead at a local level may be true for some particular construct (e.g padding out with extra NOP instructions). Globally over an entire typical program, the extra overhead would be much smaller.

If you are trying to save scan rate, then the instructions which slow down the scan the most are things like timers, counters, math operations, and subroutine calls. You would have to actually do fewer of these operations. This is difficult in practice as generally each timer, counter, etc. has a defined purpose whether you are using STL or ladder. Trimming a few boolean operations out saves you little in practice, as these tend to execute so fast that their proportion of the scan time is much less than their relative instruction count may lead you to believe.

If you are defining efficiency in terms of minimising memory usage then again, it is normally difficult to save significant amounts of memory by writing in STL as opposed to ladder (although there may be special cases). You are
probably better off using a language which lets you concentrate on creating the simplest possible program than on trying to shave off a few instructions here and there. Going to extremes to minimise memory usage in PLCs is seldom justifiable, unless the PLC happens to be undersized for the job, and you are trying to avoid replacing it.

--

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