I am new to Siemens programming and I am learning a bit of programming using LAD logic.
What I do now is use only the OB1 and do all my little programs there only and check by using the simulation feature. I am using Siemens S/w version 5.2 and mostly the CPU is S7 300: 315 2DP.
I desperately want to know how I can use the FC,SFC,SFB,DB for creating my programs with better flexibility.As of now I am using only the OB1 to write all my program in it.Can I use other Ob's also ?
How do I call the different Functions form my main program and how do they return the values ?
Any help with a small example would be most appreciated.
Is there any way I can get some real programming examples , easy enough for a beginner like me ?
Thanking you all in advance
Manuals and programming examples have been installed on your computer along with Step 7. Look for manual "First steps with Step 7" and "Working with Step 7" in the Simatic--> Documentation directory (from the Start button).
They will show you the way to use FCs, FBs and DBs. Follow the step-by=step project they use as an example.
Programming examples are refered to in the manuals and used to illustrate different points. Many are available through Step 7 standard installation. When you open a project in Step 7, there is a tab for example project. Commentaries are well-thought and useful (if you have installed Step 7 in a language you can read).
Hope this helps,
Step 7 would be my last choice for a beginner. I find it less pleasant than using a handheld programmer. It seems like a collection of tools tossed together.
Thank you very much for your e-mail.
I did try to understand the examples provided in siemens. They are nice but difficult to understand especially for a Newbie like me. I think I would be able to touch them only after a while.
Can you help me with a simple example??
A simple approach to take is as follows:
1)Insert a Function Block into the blocks folder.
2)Treat the FB as if it were a virtual PLC:
2.1)At the top, the declaration area, define inputs at the INPUT section and outputs at the OUTPUT section. Internal variables are defined in the STAT section.
2.2)Write your logic in this FB using only the variables that you defined in the declaration area.
2.3)Save and close the FB
3)Open OB1 and drag your FB from the Instruction Overview browser (the instruction library). It will be in the folder "FB blocks"
4)Allocate a data block (DB) for this instance of the FB call. You can call the FB multiple times with different DB. If you are in LAD then just type in DBx where the red question marks are atop your FB. "x" needs to be a number like 1 or 36 or something.
5)fill in the Inputs (left side of FB) and the outputs (right side of the FB). For example if you have declared an input to your FB like "START_MACHINE" then you might type in "StartPB_1001" or I1.0 at that input.
looking for field support for S7 in our automation cell. we are using Motoman robots with Krass Mafii injection press tied thru PLC.
designed in Germany and looking for support in Ohio, north central near Bellefontaine.
Re: question posted by Bapi (on April Fool's Day! 2006)
It is now the day of the royal wedding (29/4/11) and as a beginner I have been pulling my hair out for days trying to find the same answer.
The answer was kindly provided by you on 15th April 2006.
As Siemens point out:
Engineers use LAD
Programmers use STL
Designers use FBD
Function Blocks belong to all but sometimes people like Bapi and myself can't 'see the wood for the trees'.
Speaking as an agnostic, online forums such as this one sometimes are 'a God send'. :0)
Many thanks joeS7. "Live long and prosper".
while appreciating your time and far from wanting to start a flame, I'd like to ask us all whether we should *really* keep on answering these kind of questions... We're talking about automation and engineering, not housewives' how-to-apple-pie and we *do expect* aggressive approach to
problems: who'd hire or rely on an engineer that doesn't even bother to explore the software package he just installed on his PC? The "start button->simatic->documentation" path is primary school stuff, still we have "want-be-engineers" posting such questions!
Again, it's not a matter of negating a help, everybody has been a beginner. But there's much more involved (and dangerous) in growing lazy minds.
Thankyou for sharing your ideas about various approaches to a problem.I am sure you make your employer very happy
Let me gently and politely explain what is being said here. Everyone had to begin someplace and somehow, there's nothing wrong with asking questions. Lately what I, and probably others who consider it politically incorrect to comment are seeing, is people who should probably not be doing controls yet, doing controls.
Programming a PLC is a great convenience compared to other ways of controlling machines and processes. But it is a minor part of those tasks. Understanding how to control what you intend to control is far more important than what tools you use. Much of the documentation has traditionally been targeted at electricians. The reason for this is that they are already familiar with controlling things and can most often interpret a ladder diagram and do things safely. More recently, there has been an increasing trend towards electronic knowledge. math and traditional programming as these people get drawn towards the hardware end of industry. Most people who have these types of knowledge can productively and _safely_ add PLCs to their toolbox.
But simply programming a PLC without this background is unlikely to produce good control solutions and worse, can be extremely hazardous to life and property. That's why, if the problem is that you can't understand the documentation or what is being accomplished with PLCs or don't want to acquire the prerequisite background, the responsible solution is not to do it anyway. And while it is often a judgment call, without knowing what the person asking the question knows, it's often not a good thing to help people do what they might not qualified to do. And that's coming from someone who has tried to help a lot of folks with electronics and instrumentation.
I *am* an employer.
And irony doesn't help much.
Read the manuals first, then post your questions: you'll be welcome.
I would like to respond to Luca. I have recently had email traffic with you in regards to your training sim (Faurecia Interior Systems). I would advise that you be a little easier on persons trying to make it in this field. Every PLC programming language has its problems and in this case my opinion of Siemens S7 is that it is about the most unfriendly software I have ever had to use. I am new to Step 7 and I would rather go to the dentist who is out of novacaine then program in 3 programming languages thrown together in 1 program. I am always willing to help anyone, even with the basics due to the fact we are small community and someday I may need help on something that they know more about.
Fred D Eckert
Yes, maybe I was a bit too rude. But I think that posting questions (which means "taking others' time and attention") without even bothering to flip the front cover of the manuals is a bad and unrespectful habit (and I snapped, sorry).
About your Siemens S7 opinions, get a pair of boxing gloves and jump on the ring... In the A-list, as in other communities, there are hot positions at both fans and detractors' corners. ;-)))
My hint: If you do not like Simatic S7, drop it and select something else you feel more comfortable to work with. Personally, I dropped Allen-Bradley and others...
Dear Curt & Luca
Siemens has a far more complex way of programming than most automation equipment manufacturing companies and while this makes it hard for newbies, it also sets them apart from the rest as far as power and abilities are concerned.
What is however sad is that such a powerfull system has such a poor reputation amongst end users primarily as result of the lack of helpfulness they encounter when seeking assistance from those in the know. I myself have fallen foul of this superiority attitude of Siemens when we still had our own local office/branch and I got the impression they felt that they were doing me a favor by speaking to me at all. Sad to say that the only assistance we get these days is from small systems integrators (at a price).
Needless to say, every PLC I have installed from there on has been an Omron as they are even prepared to provide me with on site support and advice is only but a phone call away no matter how "stupid" the question. They know that they will be the first ones I turn to the next time I have the need of a PLC for a project.
In reality, unless you are intending becoming a systems integrator installing & programming a lot of PLCs, I would not suggest that you bother learning how to program Siemens PLCs as it is just too complicated for occasional use.
If you look at the time wasted pointing fingers at someone asking what was deemed to be a stupid question, it could have been halved by just being helpfull. I'll bet that he would think twice before asking another question for fear of being crucified for not understanding what he read.
Thanks for the opportunity to raise this issue.
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.
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.
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.
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.
>Why did Microsoft beat out CP/M and Apple?
>Why did VHS beat out Betamax?
>Basically, Siemens is a safe choice.
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 ;-)
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.
[quote] That is a programmers point of view and valid as far as it goes.[/quote]
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.
mistyping: I skipped a NOT
"I worked on a number of applications/plants that could *NOT* be stopped without sensible loss of money"
> [quote] That is a programmers point of view and valid as far as it goes.[/quote]
> 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.
> [quote] 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.
> [/quote] 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.
> [quote] > My point is, machines aren't all about programming. Fixing them under duress gives you an entirely different viewpoint on complexity.
> [/quote] > 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.
I tend to agree with Curt. I work mainly in maintenance mode, keeping the existing processes going and making incremental improvements. We buy our equipment and expect to maintain it ourselves. This means that troubleshooting and the modifications are done with a lot of reverse engineering. Any extra sophistication that would make a developer's life easier, almost always makes our efforts more difficult.
If you're an OEM and can afford to have well trained S7 experts, create libraries, take advantage of all the S7 languages, then great - go with Siemens.
If you are an end user with minimal maintenance staff and have the OEM service your gear, then go with your OEM's favorite brand.
If you are an end user and intend to maintain it yourself and have different age equipment, varying skill levels of maintenance staff (due to seniority, shift assignments etc.), various types of processes supported by this staff, then KISS.
In my opinion, S7 (the 300/400 kind, I haven't used the TI style) does not lend itself to troubleshooting on the floor - the clumsy interface impairs your ability to get all the information you need quickly. Every extra click and keystroke is frustrating and distracting when the plant manager is looking over your shoulder! The more toys you give a software guy, the more he's going to play, but doesn't mean he's trying to help >>you<< win.
Of course, there is nothing preventing Siemens from making decent pragmatic tools for these PLCs. They would certainly have enough examples to follow. It seems to be a target audience issue. There is a definite Siemens style of programming as well. You see it from large established EU firms that have a large programming and technical staff and on large complex projects. Perhaps it permits more code reuse, or it's easier to divide projects up among several groups. Or it provides justification for a large programming and technical staff :^) But these programs are almost impenetrable when a problem arises and you need to find it, right now. And talking someone through the maze on the phone simply sucks compared to something that takes you to the logic right now. If you only work on the one machine, it's probably OK once you know your way around. It's just not an Ad Hoc system.
In reply to curt wuollet:
I would say the Siemens Step-7 software is quite good (by the standards of the automation industry) in the sense of what it is trying to accomplish, but it isn't targeted at the casual user or maintenance person. It's targeted at someone who writes S7 programs day in and day out. The people who write S7 programs tend to like Step-7, the people who deal with it only casually tend to dislike it (although some maintenance people like it as well).
I don't know if you ever tried the Siemens Step-5 software (for the S5 PLCs). To anyone who has had to deal with Step-5, Step-7 was a welcome relief.
Siemens had a version of Microwin that would work with the S7-300. It was a good idea in theory, but the problem was that it would only work with basic I/O cards, and not with any of the intelligent modules (e.g servo modules). The result was that you would still have needed a copy of Step-7 anyway to handle the machines that had intelligent I/O cards. To add to the problem, the data file formats for the two programming packages were not compatible. Because of those problems I don't think they sold many copies.
I have to agree though that a lot of S7-300/400 (and S5) programs are often needlessly complex. The S7 PLC gives you more than enough rope to hang yourself. Good programmers will keep their programs simple. Bad programmers will try to use every possible feature in the S7 even for the simplest of tasks. The big problem is that a lot of the bad programmers think they are very clever, and that if other people can't understand their programs it's actually a sign of how smart they are. You see this less with simpler PLCs (including the Siemens S7-200) simply because those PLCs don't have the same degree of flexibility as an S7-300/400.
The S7-300/400 was an evolutionary development of the S5. Siemens was rather limited in how much they can change while still providing a straightforward migration path for their existing customer base. I think that for every feature in the S7-300/400 you'll find a big existing customer demanding that it be there.
To simplify the S7-300/400 much they would need to discard backwards compatibility (much like Koyo did with their new "Click"). They could try to do that by growing the S7-200 upwards, and that might be what they have in mind for the S7-1200. I don't know what plans they might have in mind though, or even if they think there is a problem at all.
Yes, if I were reaching hard for nice things to say about step 7, I do concur that it is better than step 5, if only in the sense that drowning may be better than being burned to death. Step 5 issues were different, after navigating several levels of completely non-intuitive menus, it did present you with a working ladder diagram and you could troubleshoot with it. I've often wondered if you couldn't use TI or Koyo (automation direct) tools on some of the older Siemens stuff. Siemens also has the habit of using about 50 variations of programming cable gadgets that all look alike but are not interchangeable. It's a really hard system to like on an ad hoc basis, which sums up maintenance. I imagine in an all Siemens shop, where you could keep all that sorted out and you had nothing to compare it to, you might get comfortable with it. I do question if there is a good enough reason for all the complexity. It does seem that every other PLC vendor can accomplish _all_ the same things without it. Aren't PLCs supposed to be simpler to program than writing assembler or machine code? I prefer C to assembler for the same reason.
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.
Sage Automation, Inc.
>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.<
it proves only that the maintenance people was comfortable just with ladder, not that STL is not good as a language.
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.
I am one of Luca's very happy customers. I *LOVE* picking his work apart just for the learning experience and simple direct elegance... he his correct to say what he has.
As for other PLC programming systems, each has their advantages and disadvantages. As for people, their are programmers and those who think they are programmers. A programmer does not care if it is Cobol, Fortran, C++, Lisp, Assembly, etc. He (or she) will program like the mountains the mountain climber climbs: Because they are there. The rest, the just complain.
Yes, but all those languages you mention can be done with the same tools. And you have a choice of many tools. And I'd rather program in any one of them rather than Step 7. No mountain climber will start with tangled, knotted, ropes and dull crampons. And I'd just as soon not have to climb a mountain just to program a PLC:^)
>> Why did Microsoft beat out CP/M and Apple?
>> Why did VHS beat out Betamax?
>> Basically, Siemens is a safe choice.
> Siemens *has become* a safe choice.
---- sniped by moderator
> Over and over again, if you do not like Siemens and their STL, simply do not use Siemens products.
STL may be great for engineers, because you can program it so fast, but at 3am on a Sunday morning, when all the programmers are safely dreaming their sweet dreams, and a production machine is broken down, it will be an electrician who will be called to fix it. Someone who is also replacing blown lights, and adjusting sensors, and fixing the control room air conditioner for the precious operators who shut down when they sweat. Someone who an employer is never going to spend money on to learn STL, because they simply won't use it enough, and will forget it. So when the program is written in ladder, the hard working electrician/technician, has got some chance of seeing the conditions in order to determine where in the process the problem is. But if it's all written in STL, and the person in question doesn't have 10+ years experience on THAT process, and so already knows every permissive and quirk, then that machine isn't going again until the engineer can be roused from his bed (if he's even in the same country), and can tell someone what is going on. I can deal with ladder, I can deal with FBD (because we learn simple boolean algebra, and it's not a big leap), but if the program is written in STL, and I'm not going to be using it to fault find. Your STL may be fine on small machines and plants, but in a major production facility, it's a dog.
I can't agree more, I really won't use or recommend Siemens products to anyone I like. There are far too many good alternatives that don't require I do things their way. That is to say, I don't get their value proposition, all factors considered. I've used them a lot and they didn't grow on me. They are just harder and more expensive to use. That's a great selling point.
> 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.
---- snip ----
This is not an issue of this is good/bad hardware. All of automation programming is moving away from the original concept: replace relay logic with a graphical representation that will allow those who understand and use relay logic to use a computer based control system.
The purpose of this was to facilitate the ability of technical people without a CS degree to be able to work with (but not necessarily design) PLC software. Siemens is not a PLC it is a industrial computer.
The people who are purchasing this equipment do not understand the difference and it is certainly not the people who use it that are buying in. The changes started when MB bought Mopar. Then MB bails after draining a couple of bil from Chrysler and all we got left with was S7. No stinking t-shirt or anything!
I saw the same type of problem mentioned above and I was not particularly enthusiastic about S7 afterward.
Perhaps the thought process for buying German technology is the same for buying German cars: it's German, it has to be better! Maybe, but at what cost? And when the Germans can't figure out how the S7 or the automobile work, that indicates that there may be better choices out there.
My thoughts for what they're worth...
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!!!
You desperately need to read the manuals first.
Siemens Step7 systems, as all other systems as well, are not suitable for "improvised programming".
Thankyou for your e-mail.
Well... I find Siemens as a sea full with information but dificult to find and when you find it it is difficult to comprehend.
So my friend I ask for your help.
Myself also a newface to SIEMENS S7 FAMILY; surfing the books & hubs to learn the system. pls let me know whether you r interested to share ur knowledge with me about SIEMENS S7. if so pls contact me at my mail id, firstname.lastname@example.org . hope i'll get a favourable reply.
thanx & regards...
this is abdullah jan from pakistan.
i want some information about (PLC S-7)
how can i upgrade the software of them.and complete proccess of reinstalong of the software of that.
its mean i have software copy in my another harrd disk. so i want to reinstaling method of it. when my plc software CURPPTED.
i hope you will give me info about that.
You have set out on a quest. Siemens is not the easiest, but in my opinion one of the most powerful. Trick is to understand the tools they give you and their intent. OB1 is your main call. Almost no legal operations should be performed here. Do this in an FB or an FC (I prefer the use of the FB) and call it in OB1. Simple subroutine programming.
SCL is useful for craeting blocks that will be used many times, like Conveyor or Motor. Then you can call the respective block in ob1 and tie your in's and out's to the block.
Good luck and try this book... "Automating with Step 7 in STl and SCL" by Berger. Can be very helpful with programming examples. Also comes with a disk of examples.
One has to take a Siemens Level 1 programming course before one can even try to understand a written program. So I suggest take a Siemens Level 1 programming course, and start from there just like I did.
Then there is profibus interface, STL, SCL and graph.
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.
Another good book is "Step 7 in 7 Steps" by C.T. Jones. I found it very helpful when I moved to Step7.
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.
J. S. Nielsen
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
Jan S. Nielsen, Denmark
L-N@mbox301 . get2net . dk
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)
J. S. Nielsen, Denmark
HI J. S. Nielsen,
Could you, please send me the zip file? my email is email@example.com
The dude simpy wants some programming examples that incrementally break down the programming process/flow. There is no examples that clearly show how it is done. Basically the same thing that I am looking for.
It is good that some people have the decency to at least answer the question, explaining that Siemens Simatic is rather difficult and complex in comparison to other languages. It's interesting to find out that Step 7 is powerful but difficult. It seems comparitive to the power of C and the simplicity of Visual Basic.
Just because you understand it, doesn't mean that you are smarter than everyone else and everyone else is stupid. Your answer doesn't provide any guidance or a solution to the problem. Why can't people simply offer some examples and manuals? Why not just give me a map of Detroit, when I am in LA and tell me the reason that I am lost, is because I am not trying hard enough?
Please tell us where the resources are. If you are not gonna offer any assistance then just don't say anything at all. You're bogging down the forum with a stupid rant equivalent to why Mac is better than PC and it's not helping us make any progress.
In my experience, smart people who easily understand certain skills and concepts generally make terrible teachers. They look at you as if you are an idiot, when they lack the ability to convey and teach what they so easily understand. In reality, we are all capable of learning these concepts.
I would reply simply that the resources are there and what you look for, is an easy way to understand that which is not easy. Part of the problem with examples is that the complexity allows, some would say enforces, a variety of programming styles. There is no one way to break programs up or tie them together. And there aren't many small, easy to understand examples around. These PLCs tend to be used for large complex problems.
As far as manuals, the Siemens site has lots of them and they can be downloaded free. There is no "Step 7 for Dummies" type that I am aware of, but I haven't looked very hard. In a way, what you are saying is exactly what we have been trying to tell you, the product is not very approachable and has a rather daunting learning curve. The best help that I can provide is that some C and assembler programming experience is a great help in understanding the concepts they have exposed to the automation programmer.
This is not mean spirited or evasive, the simple fact is that you have to be familiar with some fairly low level, that is close to the hardware level, methods and concepts before what they are doing makes much sense. I'm sorry it's not easy, but that's the way it is.
>... They look at you as if you are an idiot, when they lack the ability to convey and teach what they so easily understand ...
Hello dear "Idiot"
I understand your anger, because I had the same feeling when I started to program PLC's, Siemens S5 and later on also S7. Here you have my e-mail for respond on your anger, so I can attach a zipped work of mine for Siemens S7, that really helps - no smart words, just solid help.
Jan Steen Nielsen, Denmark
Mr Jan S.
Please can you send me some instructions for the Blokke.zip
really need help.
angel_scaggs [at] hotmail.com
I take issue with this assessment.
Take your example of C vs Visual Basic. There's a dramatic difference between the two, and quite often the requirements of a project will determine which language to use... things like development time, low-level hardware access, GUI requirements, target system, execution time, etc. In some cases, C is advantageous. In others, you'd be fool to use C.
The difficulty and complexity in Siemens grants the programmer ZERO advantages over, say, an Allen Bradley Controllogix. Zero advantages. No matter the requirements of the system, it will almost always be much easier and more straightforward with Allen Bradley, especially for a beginner. (Barring any oddities like being locked into an incompatible network protocol... AB is only slightly better at Profinet than Siemens is with Ethernet/IP.)
Having worked extensively with both, I just can't take seriously anyone who disagrees with this.
Anytime I come across a Siemens programmer who raves about how great TIA Portal is, I know right away I've come across a guy who lives and breathes Siemens and has never worked with other high-end controllers. Sure, coming from Step7 5.5 (or, God forbid, Step 5), it's a HUGE leap forward... but it's practically unusable for large projects.
Siemens is today where Allen Bradley was 15 years ago, when AB was shedding off the shackles of RSLogix500. At the time when RSLogix5000 was in its infancy (which lasted until version 12 or so), it was releasing very buggy development software and buggy hardware. The new crop from Siemens is no different... and it'll be a few years before it's stable enough to use in industry. I say that after some hard lessons learned in the field, so consider it a warning.
>Can you send me the Blokke.zip file.
>Thank You very much !
I believe you all are looking for this link: http://controlwiki.com/images/5/5c/Blokke.zip
Hope that helps!
How to get "Blokke.zip" file for
Siemens PLC S7-300/400 series, prepared for Siemens simulator and with lot of comments for every function.
You may download this useful program as follows:
1) Call "Controlwiki.com"
2) Call "PLC_Archive"
3) Call "PID_Controller"
4) Download "Blokke.zip" under the blue text.
5) Open "Blokke.zip" by "Retrieve" under "File"
with Siemens S7 PLC software, ver. 5.3 or later.
Hope this helps in your daily work with Siemens!
Jan Steen Nielsen
Hi there folks
To answer the original post; if you wrote your code in OB1 only using a S7-300 is most probably grossly shooting over the goal.
I write PLC-programs in whatever system the customer wants me to and Step7 is not an easy program to use if you are not already familiar with PLC-programming.
I disagree with a lot of the posts, all systems has it's pros and cons but Step7 is a fairly good system once you have learned it.
But as i mentioned earlier i don't think you need such a complex sytem. If you want to stick with Siemens you could probably do with a Logo! and that has an easy graphical programming language.
And there is a lot of other easy to use small system PLCs out there.
To all those professional programmers who love to use Siemens, great, fine and dandy, wonderful.
But bear in mind, most of the time a professional programmer IS NOT the end user and maintaining equipment falls to a technician.
While on the subject of technicians, it is not the fault of the poor sap who was hired to be a technician who now has to put on the hat of a programmer. And usually, that hat is put on in the middle of a production run, out of the blue, without "years" to train or develop specific knowledge of a PLC language. He or she has OJT with management breathing down their neck and everyone commenting on his incompetency, while the "professional programmer" is sent to high cost training seminars to "learn".
Yes, in a perfect world, the hands on guys have full training, knowledge, and years of application experience.
In the real world, it is a guy who has very limited, if any, training, mechanical/electrical/instrumentation/machining knowledge on several hundred pieces of equipment, and years of fire fighting to rely on.
So, my question is, do you blame the guy who has been put in a position in which he can not be successful?
First off I would like to suggest you not get hung up on this discussion.
What I have learned from programming both AB and Siemens is that if you are familiar with AB, then Siemens is easy to learn, except for STL. LAD between both is very similar. AB ST and Siemens SCL tend to follow the MS VB code language with there own variations. FBD is FBD.
The main difference is the execution of the programming.
My experience with AB has not yet come across any programming language like Siemens STL.
I learnt to program in LAD, FBD, and Code (ST or SCL).
AB has certain functions that do not work in a certain programming language. IE: The PIDE function does not work in LAD.
Sometimes Code language is more efficient. However, not everyone knows Code language.
>I desperately want to know how I can use the FC,SFC,SFB,DB
>for creating my programs with better flexibility.As of now I
>am using only the OB1 to write all my program in it.Can I
>use other Ob's also ?
1. Look at FBs and FCs as routines. More so with version 16 and later, as Add On Instructions. If you are familiar with AOIs, then you already know how to program FBs and FCs. Only minor variances on how they are implemented.
Conceptually they are similar.
2. Think of OB1 as your Main routine in AB.
Use the main routine to call your AB subroutines.
Use OB 1 to call your Siemens subroutines.
3. SFCs and SFBs are equivalent ABs prebuilt functions.
IE: SFB4 is the equivalent to ABs TON. Timer function.
4. Siemens DBs are equivalent to ABs Tags.
Siemens uses two types DBs. Instance and general.
Instance DBs are generated when calling an FB.
General DBs are created by you.
In Siemens, you can create function tags and call them directly like you do in an AB program. However, to use a DB tag, you have to use the DB path.
IE: DBnn.DBX 0.0 or DBnn.DBW 2.
If using Symbol Information: "Global Data".TagName.BitName or "Global Data".TagName.
5. OBs other than OB1 are similar to ABs SFs (System Functions).
For starters, do not worry about other OBs until you are ready to move on to more advanced issues and control.
IE: OB82 is an IO Fault routine. When an IO fault occurs, OB82 is called. If no program is in OB82, it defaults to what Siemens programmed it to do. If you want some logic to execute on an IO fault, then you program the OB82.
ABs default IO fault control is configured in the module. If you want some logic executed on an IO fault, then you program it in a routine.
>How do I call the different Functions form my main program
>and how do they return the values ?
1. In your LAD editor, add an empty box to the network. in the blank space, type in the FBnn, or FCnn, where nn is the FB or FC number.
If you call an FB, it will require you to enter a DBnn.
If you call an FC, it will not require a DB.
2. To use a system function, you can enter SFBnn or SFCnn if you know what it is.
If not, then you need to get it from the Library. Don't worry, the library is just as confusing as ABs. Unless you use the function regularly and know what it is, you need to read the description and try it out to see if it what you need. Same way with AB.
Most functions fit the average usage, however, if you need a specialized function, you may have to program it yourself.
>Any help with a small example would be most appreciated.
>Is there any way I can get some real programming examples ,
>easy enough for a beginner like me ?
It would take to long to provide examples for all the different aspects of programming.
What I would do is an internet search for a particular example of what you are trying to accomplish. IE: the use of a timer to pulse a light.
Or post a routine from an AB program and ask if someone could provide an equivalent function in Step 7.
The advantage is that you know what your AB routine does and providing a Siemens example allows you to follow the Siemens equivalent and see how the program is equivocally executed.
I found this link to a list of S7 Functions.
There is also an Excel spreadsheet link.