Siemens S7 programming

Hi,

I truly suggest you get this book and try to get yourself into the S7 basic course if possible.

"Automating with Step 7 in STl and SCL" by Berger

I'm experienced with Siemens PLCs, so drop me an e-mail if you need more help.

Regards,

Wisdom Ramavhulela
 
I would like to say that PLC programming is not for everyone. Firstly, if you are not familiar with the 3 different languages, then you have not looked into why it is there. I have programmed many different PLC's and I can in my Professional Title as a PLC Programmer say, Siemens is probably the best and most versatile PLC and Programming Language ever used.

There is a reason why you cannot do certain things, because you break programming basic rules. If you cannot understand that, then maybe go back to your handheld, or something easier.

People go on courses, and study this subject for a couple of years before they become proficient, let alone competent, now you want to do it on a weekend. In many ways you actually insult the competent people, by slandering a product you have no idea about. I think that is why you get no positive feedback on this subject, and I don't think Siemens have the time to waste on people who don't have time to put in effort.

If programming a Siemens was so difficult, why is a large amount of the world's most sophisticated equipment run on them?

This just proves that some people want to put the effort in to learn, and others will make a rash decision based on incompetent observations.

Ian Myers

 
C
On balance, I know some very competent programmers that think Siemens programming stinks. I myself have never seen anything quite so tedious and obnoxious to untangle as a large program with bits and pieces in different languages one not far removed from assembler. And I have programmed in everything from toggling ML in with the front panel switches to 5GLs.

If there were a payoff for the effort it would be different, but I just don't see a big advantage. And I think I understand where they are coming from with their approach. It does give you nearly the flexibility of a general programming language like C.

From a programmers point of view that's ok. But it can negate most of the (few) good things about PLC programming. And the people who like it seem to write stuff for the confusion factor. When you have to work a lot with other people's code, almost anything is easier to work
with. And it doesn't matter whether I want to invest the time or not, the downtime is still expensive.

Regards
cww
 
In reply to Curt Wuollet: The "S7" label doesn't tell you anything about the programming language used. The S7-200 series have no relationship at all to the S7-300/400 series, other than the plastic case being more or less the same shade of dark grey.

I understand that in many markets the S7-200 product line outsells the S7-300/400 line several times over. That is, it outsells it in terms of number of units. Measuring sales in euros might give a different result, since an S7-300/400 costs several times as much as an S7-200.

The S7-200 was designed by the TI team around the time that Siemens bought TI's PLC division. It is a fairly conventional "Japanese" style PLC with IEC addressing. If you've ever programmed an Omron or Koyo PLC, you would feel right at home with an S7-200. Both TI and Siemens (as well as GE and GE-Fanuc) used to sell re-labelled Koyo PLCs. The S7-200 was the replacement for that product niche (Siemens stopped selling Koyo PLCs, and Koyo launched a direct sales organisation through Automation Direct).

The S7-300/400 (the 300 and 400 are essentially the same, except for packaging and the I/O rack size) are designed as the direct successor to the S5 series. The S5 series was the Siemens mainstay for many years and the S7 300/400 was intended to provide an upgrade path for those customers. The S5 and S7-300/400 aren't hardware compatible and are not 100% software compatible, but rewriting an old S5 program to run on an S7 300/400 is fairly straight forward. Siemens even has a conversion program which is about 80% - 90% successful for simple programs.

The S5 was an old design which was a contemporary of the AB PLC-2 and PLC-5. The S5 was based around the Intel 8031 series of microprocessor, which Siemens had a license to make. They also had a custom coprocessor module which they used in some S5 models to speed up some of the boolean logic. Siemens squeezed an amazing amount of functionality out of a simple 8 bit processor. The penalty for this though was that each S5 instruction was fairly primitive and only slightly above the level of the 8031 assembly language. Have a look at the 8031 assembly language and the S5 statement list (IL), and you can see the resemblance.

By contrast, AB took a different approach and used minicomputer technology in their early PLC designs. The early PLC2s used 4 AMD 2900 bit slice processors to create a custom 16 bit CPU. It was more expensive in terms of hardware, but they had fewer software limitations as a result.

The end result of all this is that the S7-300/400 is a fairly primitive PLC in terms of its software design. By "primitive", I mean the individual instructions in most cases offer very little abstraction from the original underlying hardware of the S5. Siemens has tried to compensate for this with a sophisticated programming IDE, but many people find that the programming software adds a lot of complexity without doing anything to simplify the PLC itself. This is where many of the complaints come from.

If you compare the instruction set of a conventional PLC (such as the S7-200) to an S5 or S7-200/300, you will find that "conventional" PLC instructions contain a selection of instructions intended to solve typical automation tasks. In contrast the S5/S7-300/400 instruction sets are a large collection of very simple instructions which require multiple instructions to accomplish the same thing as a single "conventional" PLC instruction. Boolean logic instructions don't differ much between any PLC. The differences are primarily in word, math, comparison, and timer/counters instructions. Theoretically, the S5 or S7-300/400 are more "flexible", but I've never seen a case where that flexibility had any practical use.

To give a real world example, soon after the S7-200 came out I did a comparison of it to the S5-95U to see what sort of applications it could be used in. I rewrote an existing S5-95U program as an S7-200 program. What I found was that the S7-200 program was less than half the size of the S5-95U program. I didn't do the same test for an S7-300/400 program, but I would expect it to be comparable in size or even somewhat larger than an S5 program. I will get back to this point later.

When many people write an S5 or S7-300/400 program, they tend to write a lot of it in IL rather than ladder. There are several reasons for this. First, the Step-5 software was absolutely wretched and made writing any program difficult. People tended to write large complex IL rungs because the software made it hard to write smaller less complex ladder rungs. The newer Step-7 software is not as bad in that respect, but people are still carrying over their experience from Step-5.

Secondly, it simply isn't possible to do everything in ladder on an S7-300/400. With an S7-200 (and many other PLCs), every IL instruction has an equivalent ladder representation. Many (possibly the majority of) S7-300/400 instructions have no ladder representation. In addition, many S7-300/400 ladder "instructions" are actually composed of several IL instructions arranged together in a set pattern. This means that most possible combinations of IL simply cannot be recognised by the programming software.

Thirdly, the challenge of writing a difficult program for an S5 or S7-300/400 appeals to some people. It is the same sort of pleasure that you would get from solving a difficult puzzle. You get the opportunity to come up with really creative algorithms, or to write something that none of your co-workers would ever have thought possible. If you like writing software, the S5 and S7-300/400 offers more scope for coming up with creative solutions to otherwise routine problems. It also offers scope for writing programs that nobody else will ever understand (and which you yourself won't recognise after a week).

Finally, the fact that S5 and S7-300/400 PLCs are more difficult to master than other PLCs appeals to some people. They look at it from the point of view that if it was hard to do, they must have been very smart to have solved it. Other PLCs might be easy, but if you can program an S5 or S7-300/400, then you must be a "real professional".

I found the S5 PLCs to be rather "fun" to use, once I got used to them (although the extra work involved in doing anything with an S7-300/400 takes a lot of the "fun" out of it). From that point of view, I rather liked them.

On the other hand, I have to look at the practical side of things as well. PLC programs are written to operate machines, not for my amusement. From that perspective, a PLC program that is simple and can be easily understood by anyone is better than a complicated one. Also, if I can write a program that does the same thing but is half the size, then I have a program that probably has half the number of bugs and which cost a lot less time to write. The reason we use PLCs instead of writing C programs for embedded computers is to get a machine running as quickly and cheaply as possible. Any PLC has to be judged on the basis of how well it accomplishes that.

 
J

James Ingraham

Ian Myers: "Siemens is probably the best and most versatile PLC and Programming Language ever used."

I can't even express how much I disagree with that statement.

Ian Myers: "There is a reason why you cannot do certain things, because you break programming basic rules. If you cannot understand that, then maybe go back to your handheld, or something easier."

Wrong direction, I'm afraid. I don't want MORE constraints on what I can do. I want to not worry about the underlying memory map. I want to index an array by a variable (in ladder). I'd like to add an int and a float together. I'd like to compare a word and an int. These are all things that other systems let me do. They aren't "basic rules." They are limitations of Siemens/Step 7.

Once I was writing a rung of ladder logic, and suddenly it snapped into IL. I rewrote the rung... and it snapped in to IL again. It simply couldn't express what I wanted in LD. I ended up separating the logic into two rungs, with a temporary bit to glue them together. I've never had this happen in any other system.

One time I was looking at a rung of logic online. All of the input conditions were true, but it wasn't setting the output condition. I monkeyed around for an hour trying to figure out what was going on. Finally, I exported the routine, deleted it, and then re-imported it. It started working. I've never had this happen in any other system.

I've never seen any programming language so strictly enforce type safety, to the point that you can barely do math at all. We switched to using millimeters instead of inches so we wouldn't need floating point numbers.

I could go on.

Ian Myers: "People go on courses, and study this subject for a couple of years before they become proficient, let alone competent, now you want to do it on a weekend."

True. But I've gone through that learning curve now with a rather large number of different control schemes. Siemens was more difficult than most.

Ian Myers: "In many ways you actually insult the competent people, by slandering a product you have no idea about."

I have an idea. And it's not slander if it's true. I didn't just sit down for a weekend and go, "I don't like this." My company has gone through several projects using Siemens, and several of us have tried our hand at it. Maybe we're all just really stupid. But we do just fine with Allen-Bradley. If you have to be twice as smart to accomplish the same task with Siemens, does that really make it a good product?

Ian Myers: "I don't think Siemens have the time to waste on people who don't have time to put in effort."

Siemens has made it QUITE clear to us that they have no time to waste on us. That's fine. They're a multi-billion euro company and we're little fish. We'll find someone who DOES want to work with us.

Ian Myers: "If programming a Siemens was so difficult, why is a large amount of the world's most sophisticated equipment run on them?"

Why did Microsoft beat out CP/M and Apple? Why did VHS beat Betamax? Basically, Siemens is a safe choice. Who could fault someone who chose the Big Name Company? We have the same problem with Allen-Bradley in the States. Market success is not the same as technical superiority.

Ian Myers: "This just proves that some people want to put the effort in to learn, and others will make a rash decision based on incompetent observations."

Funny, I think that statement applies equally well to what I just said about choosing Siemens because they're the biggest.

-James Ingraham
 
J

J. S. Nielsen, Denmark

Hello Bapi,

I have made some usefull blocks(FC/FB) for Siemens S7 that I can send to you for free by e-mail if you want. The name of these blocks is "Blokke.zip" that you retrieve from Siemens S7 software under "File".

Included in these blocks are also an All-in-one PID-Controller that have been used in many plants all over in Scandinavia.
All-in-one means that this Controller is an analog as well as a step-controller in the same block with much more features than normal Siemens software.

Look forward to hear from you or from others that may reading this note.

Kindly regards
J. S. Nielsen
Denmark
 
L

Luca Gallina

>Why did Microsoft beat out CP/M and Apple?
>Why did VHS beat out Betamax?
>Basically, Siemens is a safe choice.

dear James,

Siemens *has become* a safe choice. Competitors had a looooong time to demonstrate they were better, and I'm afraid Siemens is not to blame if many competitors did not succeed: just think at Siemens' HW/SW cost, for it has *always* been quite pricey.

Over and over again, if you do not like Siemens and their STL, simply do not use Siemens products. On the other hand, why should I give up an environment and a language that allows me to *write* PLC code rather than to *draw* it? As long as my "typing" can beat your "drawing" 2 to 1, I'll keep on developing code in shorter time.

About possible "STL is write_only code" or "STL is cryptic" replies: as long as I'm still successfully in business (and with happy customers) after 20 years of STL coding, it means ones have to provide evidences other than a simple "STL is bad" affirmation ;-)

Kind regards

Luca Gallina
 
C

Curt Wuollet

Hi Luca

That's a programmers point of view and valid as far as it goes. Now, I'll program a complex mission critical system in what I happen to like at the moment. Something obscure like FORTH or maybe just assembler. I'll abstract all the addresses just for fun. Then, five or ten years from now, I'll introduce a non-obvious failure that causes the thing to be an extremely expensive space heater. We'll wait a couple shifts until everyone is really up tight and angry, I'll take my phone off the hook and we'll see how long it takes for you to find it. Or better, you get to work over the phone with an electrician doing the hands on.

I'm not, as many know, a big fan of modeling everything with relays. But I am a big fan of RLL when it comes to troubleshooting on downtime with good tools. Much of my distaste for S7 programming comes from having to find and fix problems, on downtime, with management standing around, on some very large systems with thousands of lines of code on several PLCs and some really, really, clever coding. The coding is so clever that the factory guy takes a couple more shifts to figure it out on the phone with the authors.

My point is, machines aren't all about programming. Fixing them under duress gives you an entirely different viewpoint on complexity.

Regards

cww
 
J

James Ingraham

Luca-

I have to disagree, I'm afraid. It's true that lots of people have gone up against Siemens and failed. It's also true that smaller competitors have managed to find niches and continue to survive. And of course Rockwell is bigger in the US than Siemens, and Mitsubishi is bigger in Japan. There's no PLC manufacturer that is the be-all, end-all, the way Microsoft is with the desktop OS.

Luca: "if you do not like Siemens and their STL, simply do not use Siemens products."

I wouldn't if I had any choice. As a machine builder I often have to do what my customer wants.

Luca: "...allows me to *write* PLC code rather than to *draw* it?"

Actually, RSLogix lets you do this as well. Has for years.

Luca: "As long as my “typing” can beat your “drawing” 2 to 1, I’ll keep on developing code in shorter time."

I actually do usually draw rather than type my ladder. This is not because drawing is faster; obviously you are correct that typing is quicker. Rather, it's that drawing speed is not the limiting factor. Figuring out the logic is what takes time, not the actual inputing of the logic. This is true in every language. I type a solid 50 words per minute, but I can't actually CODE that fast.

Luca: (slightly edited) "one has to provide evidence other than a simple '“STL is bad' "

Okay. Virtually all of my customers specify in the contract that we use Ladder Logic only. There have been only a very few exceptions. In one of those exceptions, all of the maintenance people were upset that management had allowed STL.

-James Ingraham
Sage Automation, Inc.
 
I do agree with him,because I know to program Siemens,AB,Modicon PLCs. Among them Siemens is the best for programming in minimum number of networks,Good accuracy,easy editing,,,,,
So Bapi continue with Siemens, If you have any doubt on any block,go to help (press F1), You can do it because these are man made only!!!
 
J

Jan S. Nielsen, Denmark

I try to send "Blokke.zip" for Siemens S7,
but if it doesn't succeed you may send an
e-mail directly to me as an exception.
It would be better if "Control.com" could
store "Blokke.zip" as free downloadig for
anybody - is that possible and how do I do
that?.

Regards
Jan S. Nielsen, Denmark
L-N@mbox301 . get2net . dk
 
J

J. S. Nielsen, Denmark

>Hi,
Can you send me the Blokke.zip file. I will test and send you any comments.


Hello César Garcia

Send me an e-mail so I can attach the file "Blokke.zip" + lockdiagram.pdf for the PID-Controller, so you better understand what happen inside the block, unless you unprotect the block, but why
should you do that? - it will become no better than it already is.
I have tried to contact "Control.com" directly so anybody can download the file because it is for free.
(I soon retire from my active working life)

Regards
J. S. Nielsen, Denmark
[email protected]2net.dk




 
L

Luca Gallina

>Virtually all of my customers specify in the contract that we use Ladder Logic only. There have been only very few exceptions. In one of those exceptions, all of the maintenance people were upset that management had allowed STL.<

dear James,
it proves only that the maintenance people was comfortable just with ladder, not that STL is not good as a language.

Regards
Luca Gallina
 
L

Luca Gallina

Dear Curt,

That is a programmers point of view and valid as far as it goes.
yes, mine is indeed a programmer's view ...aren't we the originators of the troubles and the ones to be to blame? ;-)

Just to clarify my position: professional ethics wants me to do my best to develop rock-solid software, for the customer has probably spent lots of money on new machinery and his production will rely also on the quality of my work. Personally I wouldn't feel good if I did something sloppy or garbled.

Then, five or ten years from now, I'll introduce a non-obvious failure that causes the thing to be an extremely expensive space heater. We'll wait a couple shifts until everyone is really up tight and angry, I'll take my phone off the hook and we'll see how long it takes for you to find it. Or better, you get to work over the phone with an electrician doing the hands on.
Do you want me *really* believe a company would build a "complex mission critical system" and run an "extremely expensive space heater" without proper program documentation and constant maintenance personnel training?

Do you want me *really* believe they also expect the initial developer to immediately find out a "non-obvious failure" five or ten years after the plant has been handed over to the customer?

My point is, machines aren't all about programming. Fixing them under duress gives you an entirely different viewpoint on complexity.
I worked on a number of applications/plants that could be stopped without sensible loss of money, so I do know what working under pressure means. It meant to me an even more accurate job.
Almost 100% success is what you do normally expect by aerospace engineers or surgeons. I do believe it is possible (obviously at a cost) also in automation.

My experience says that downtime is what the customer pays for his savings at plant/machinery design time. The lack of proper documentation and bad (or inexistent) maintenance personnel training add more troubles.

So you stated you don't like S7, but are then you telling me that non-Simatic based programs run flawlessly at once, like magic? And that ladder code is always neat and easy to troubleshoot?
We should separate problems due to real software bugs to those due to poor software design. A real bug could be nasty and hard to find in any language, non-Siemens systems are no exceptions.

I agree that there are a number of wannabe programmers around, but I'm pretty sure there are either many good ones that can be picked. And when you buy new equipment you can ask to have a look at the code before signing the acceptance certificate.
Your choice.


Regards
Luca Gallina
 
C

Curt Wuollet

Hi Luca
>
That is a programmers point of view and valid as far as it goes.
>
> yes, mine is indeed a programmer's view ...aren't we the originators of the troubles and the ones to be to blame? ;-)
>
> Just to clarify my position: professional ethics wants me to do my best to develop rock-solid software, for the customer has probably spent lots of money on new machinery and his production will rely also on the quality of my work. Personally I wouldn't feel good if I did something sloppy or garbled.<

Your customer won't feel good if the staff he has on site can't fathom what you were thinking when you did the software. And while he should certainly have nothing but BsCS types working on his mission critical equipment, it's difficult to get the honors types from MIT to consider working in a foundry or a chicken plant. So he has to make do with electricians and the occasional itinerant automation type willing to do all the scut work required before you can even work on the equipment.

>
Then, five or ten years from now, I'll introduce a non-obvious failure that causes the thing to be an extremely expensive space heater. We'll wait a couple shifts until everyone is really up tight and angry, I'll take my phone off the hook and we'll see how long it takes for you to find it. Or better, you get to work over the phone with an electrician doing the hands on.
>
Do you want me *really* believe a company would build a "complex mission critical system" and run an "extremely expensive space heater" without proper program documentation and constant maintenance personnel training?<

Absolutely, how many examples do you want? As a matter of fact, I have never seen what I would consider proper program documentation and have never had the luxury of even initial training, let alone constant. In the real world, factories revolve around production and anything non-productive has a way of being permanently neglected.
What you usually get to work with is a collection of printouts and miscellaneous component docs and if you are lucky, a copy of the program with tags, if not, you get to work without the tags.

> Do you want me *really* believe they also expect the initial developer to immediately find out a "non-obvious failure" five or ten years after the plant has been handed over to the customer?<

They are, for sure, gonna want _somebody_ to find that problem "right now" and they will certainly look you up if they can find you. It would be a much better day for you if it got fixed before then. That is when having code that his people have a chance of understanding becomes very valuable. And it decreases your chances of finding yourself on an airplane headed for an unpleasant
reception. Where I have been working, it's about 2 shifts before someone is coming from the vendor.

>
> My point is, machines aren't all about programming. Fixing them under duress gives you an entirely different viewpoint on complexity.
>
> I worked on a number of applications/plants that could be stopped without sensible loss of money, so I do know what working under pressure means. It meant to me an even more accurate job.

> Almost 100% success is what you do normally expect by aerospace engineers or surgeons. I do believe it is possible (obviously at a cost) also in automation. My experience says that downtime is what the customer pays for his savings at plant/machinery design time. The lack of proper documentation and bad (or inexistent) maintenance personnel training add more troubles.<

In the real world, stuff fails. And often, the last person who knew anything about it left after that last incident.

> So you stated you don't like S7, but are then you telling me that non-Simatic based programs run flawlessly at once, like magic? And that ladder code is always neat and easy to troubleshoot?<

So, I won't tell you that. I will say that ladder is at least approachable by common maintenance types. And even though I can eventually figure it out even if you write in machine language, eventually is never acceptable. In fact, the best case is seldom acceptable. And it would be nice if the night shift at least took a
shot at troubleshooting before they call me at 3:00AM.

> We should separate problems due to real software bugs to those due to poor software design. A real bug could be nasty and hard to find in any language, non-Siemens systems are no exceptions.<

It has nothing to do with whose bug it is or whether it's hardware or software. It's all about how soon you can find out.

> I agree that there are a number of wannabe programmers around, but I'm pretty sure there are either many good ones that can be picked. And when you buy new equipment you can ask to have a look at the code before signing the acceptance certificate. Your choice.<

If only people would do that. They should have never signed the check on a lot of systems that I've seen. And they seldom think of all the deliverables they should get or if anyone in their organization can understand and maintain the thing. Or if the vendor will release the information or if it's over the barrel anytime you need service. But they don't. And then it's the poor maintenance guy at fault because there's no way to find out what sensor isn't working or where things are at.

You may see these arguments as way too literal and completely ignorant of programming esoterica. But a machine that is not maintainable by the people you can reasonably expect to be around
is a faulty and broken machine, regardless of how elegant the programming model is. Because that's what the customer thinks. If you can't get it and keep it running, it's junk. Many wonderful
machines are quietly rusting in a warehouse someplace for this reason. And many more cost way too much in downtime for even
simple things that are too difficult to find. That's probably my last perspective as a maintenance type. I'm looking to get out
of the game.

Regards
cww
 
L

Luca Gallina

mistyping: I skipped a NOT

"I worked on a number of applications/plants that could *NOT* be stopped without sensible loss of money"
 
Hello All,

It was a very interesting thread to read about and was very happy to read various opinions. I don't want get caught between the crossfire but would like to write-in my opinion. SIEMENS S5/S7 as compared to AB Make PLCs is a better option to program but may be, is not a very technician friendly option when it comes to troubleshooting.

The concept of Time Interrupts and Process Interrupts (I don't say unique) in S5/S7 PLCs is a very novel way of using interrupts. Of course, one may argue that time interrupts are mostly used for blinking fault indicating lamps. I find STL/IL programming is very easy as compared to LADDER Logic (Strictly my personal view only).

Being a very big company with a lot of resources at their disposal, SIEMENS does things in a very systematic way and that systematic approach shows in their product design. I would also like to say that Allen Bradley PLCs are simple, less complicated and very straight forward to write your code pictorially or otherwise. Yes Allen Bradley's documentation/brochures/manuals are very good while you can not say the same about SIEMENS. Some times I feel that SIEMENS takes extra time and make their manuals/write-ups more complicated for the reader. I sincerely hope I did not offend any body here.

Regards,
RK Sastry
 
Top