Stupid Siemens S7-300 Questions

Greetings all,

I have had the task of programming a S7 thrown at me and while I have been studying manuals for a while, I am not sure of what the "Industry standard" methods are for programming S7. A couple of thoughts as I start my code:

1) Motor start/stop circuits... FB or FC, which is best suited?
2) What is the M memory best used for? Set-Points, Recipe? or?
3) Alarms/PB's from an HMI(TP270) grouped in a DB? or?
4) If I have several machines run by the same PLC, is there a good
way to group the logic of each machine? Perhaps in numbering the FC's or FB's or?
5) Any other pointers for first time Siemens programmer?

I should note I have 15 years of A-B programming experience, but this processor is giving me fits.

Thanks.

If you goto Simatic (in Start list) then S7 manuals you will see Programming with Step 7. Also in that list is System and Standards for S7300-400.

FB is Function Block FBs are blocks with a "memory" which you
can program yourself.
FCs contain program routines for frequently
used functions.
Look in Chapter 4 of Programming with Step 7.

Look at the Appendix in Programming with Step 7, pages 86-90

1) Motor start/stop circuits... FB or FC, which is best suited?

I would use an FB and Instance DBs if you will have multiple instances of the same code. That said, you can do the same thing with FCs and indirect addressing. There really isn't a wrong way. Personally, I think you should start out with an FC for some basic code, and once you get the hang of S7 a bit, then go for the FBs

2) What is the M memory best used for? Set-Points, Recipe? or?

I use M memory very rarely, but if I do, I use it as global memory. For instance, I might want to store the system time in M memory and make it available to all of my functions regardless of which DB is open. I use DB/DI memory for all of my bollean logic, setpoints, etc. In fact, you can easily write your programs without using any M memory at all

3) Alarms/PB's from an HMI(TP270) grouped in a DB? or?

Yes, I would.

4) If I have several machines run by the same PLC, is there a good
way to group the logic of each machine? Perhaps in numbering the FC's
or FB's or?

The numbering doesn't matter. But try to use canned functions for all machines. I routinely use one PLC for mutiple machines, but none of the functions are specific for one machine.

5) Any other pointers for first time Siemens programmer?

Think out of the box. A lot of people think Siemens is difficult, but it's mostly because they have always used something else, and Siemens really is a little different. I've used Siemens for 15 years, and I think it's easy, and would probably find AB difficult for the first six months. Set up a test station, ask a lot of questions, try to learn STL and FBD in addition to ladder, do a lot of reading and you'll do fine.

2) What is the M memory best used for? Set-Points, Recipe? or?

Click to expand...

I came very near to starting a new Thread on this subject after reading a Thread in a German forum on good programming practice recently, where several contributors said that for them a program making heavy use of M memory was automatically a bad program (or one written by an S5 programmer who had not properly transitioned to S7). The general opinion was that with the STAT and TEMP variables in FBs and FCs, M memory was no longer necessary and everything else which needed to be generally available belonged in DBs.

Having said that, I'm fairly sure I came across a situation a few months ago where for some particular function (possibly an SFB or SFC) the parameter HAD to be in M memory and not in a DB. For the life of me, I can't remember where or what it was. I remember it because I have developed my own programming style for S7 (being entirely self-taught, never having had the opportunity to take any Siemens courses and having no previous PLC experience) and mainly for reasons of organisation have taken to holding most of my general variables in DBs. For this one instance I had to take the variable out of its DB and put it in M memory.

I would not disagree with anything that S7Guy has said....

But, he is very experienced with S7 and I have seen snippets of the way he works here on this forum.

I would say, program the way that works best for you. If you want to use all merkers and only store data in DB's then do it that way. At the end of the day, you have to write and understand this program, it's your choice.

S7Guy, can you cast your mind back to your first Siemens program, (S7 or S5) did you program them then the way you do nowadays, did you use indirect addressing and FB's etc as much then as you do now? I am curious as to the answer mainly because I tend to stick with the programing style I learnt with and worked with, that is as much as I possibly can in ladder, I only 'delve' into STL when I really need to

Like S7Guy, I also tend to find Siemens easy, but only in the realms of the type of program I have to write, there is still that steep learning curve there when I need to use a function that I haven't come across before.

Still, I prefer S7 to S5..

Paul

Use A FB to write a subroutine that contains it own variables that are kept from scan to scan. These will have a datablock associated with them to keep this info. You can incorporate the data from a FB into the datablock of another FB if it is called from that FB.

Use FC's for subroutines that don't contain data that has to be kept between scans. You use these by taking the values passed into them and calculating a result or results that is/are returned.

There is a shortage of pre-built S7 commands but you have the power with FB's and FC's to write your own.

As for controlling multiple machines from one PLC. If the machines are the same, write a single FB where the inputs for the machine are passed into it, the outputs are returned and call it separately once for each machine using a different data block for each call.

Edit: I actually wrote this and got called away awile before posting so sorry for the duplications.

Having said that, I'm fairly sure I came across a situation a few months ago where for some particular function (possibly an SFB or SFC) the parameter HAD to be in M memory and not in a DB.

Click to expand...

No, there are no limitations that would force you to use M memory, but there are cases where DB data is not allowed. Instead, you would have to create a local variable (in L memory), initialize it with DB data, and use that instead.

S7Guy, can you cast your mind back to your first Siemens program, (S7 or S5) did you program them then the way you do nowadays, did you use indirect addressing and FB's etc as much then as you do now? I am curious as to the answer mainly because I tend to stick with the programing style I learnt with and worked with, that is as much as I possibly can in ladder, I only 'delve' into STL when I really need to

Click to expand...

Well, I started with S5, so I couldn't use S7 stuff like UDTs, arrays, IDBs, and the such. But I did start out with STL and a ton of indirect addressing. And since I worked on European machines and programs that rarley coverted over to ladder, I never got into "ladder mode" at all.

I agree completely that "At the end of the day, you have to write and understand this program, it's your choice." Bit eaw also said he has 15 years of AB experience, so machine control logic is not new to him. If he has a fairly complex program to write, I think he is probably up to the task of using every tool Siemens provides, not just the tools he has used in the past.

Paul raises a point that I occasionally have also wondered about S7Guy. Do you maintain all your equipment yourself or do the customers take over after delivery? While I'm extremely impressed by your programming skill (I'm still trying to fully appreciate all the details of the UDT Thread!) and would love to be able to even get near to it one day, I've also had the situation, that all of (the few) systems that I've been involved with were destined to be maintained by shift electricians after I was out the door and I've developed what I consider to be a healthy humility about what constitutes good programming style, especially where conventional indirect addressing etc. is concerned. Having said that, your recent post with de facto symbolic indirect addressing struck me as something that probably could be followed by a normal, reasonably competent, shift electrician. I'll be going back to that Thread in the future to soak it up.

In the meantime, I'm going to stick to the principle, if I've got enough memory and CPU power, (which will presumably depend on the project's finances), I'll stick to easy to follow spaghetti, rather than always aspire to the "best" programming style.

That said, sometimes it's a trade off, for my test picture in ProTool, I had the choice of using the ProTool Multiplex addressing system, which was a fairly hefty learning curve and will probably be anything but intuitive to the poor sod who is going to have to maintain this system. The alternative was 21 Pictures - one for each module - sometimes you've just got to bite the bullet!

Do you maintain all your equipment yourself or do the customers take over after delivery?

Click to expand...

They take it over after delivery (I don't think many of my customers even have Step7). The style I use is pretty much described in the UDT thread, and you can see that it is self-documenting. In the cases where I use pure indirect addressing, it is contained in functions that never have to be troubleshot. And unless it's purely by accident, I don't think anything converts to ladder (I like to put everything in one network and separate the logical sections with comments).

Of course, that might sound kind of scary, so I'll add some caveats:

1. I program in STL because it is much faster to develop (saving the customer a lot of money) and uses far fewer instuctions to perform the same logic.
2. STL is actually quite simple to troubleshoot. I can take a guy who is kicking and screaming about it, sit him in front of my computer, and in ten minutes he understands how to interpret the accumulators and RLO (I've done this with the typical union electrician). I don't see what people make a fuss about.
3. I include tons of diagnostics. Every project I've worked on includes an HMI, and I display everything from a graphical representation of the actual I/O cards to listings of every internal parameter of all the drives. In essence, the HMI displays everything that anyone could ever hope to find by going online with the PLC. Think about it: When someone goes online, what do they usually find? The reason that the machine isn't working or an error in the code? My guess is that they find out what is keeping the machine from working (limit switch not met, drive fault, etc). As long as I display the state of everything on the HMI, they don't need to go online.
4. I do exhaustive testing. I mean, exhaustive! I know it's hard to anticipate everything, but I try to go the extra mile. After I think I've found all of my bugs, I'll get an untrained operator and tell him, "Do whatever you want. See if you can make it fail", and sure enough, he'll find something I didn't think of. By the time I finally walk out the door though, my code is "hardened".
5. Would I code in the more traditional ladder style if a customer held a gun to my head? Sure, no problem. But after explaining to a customer why I do what I do, they pretty much let me alone. It's a matter of trust and confidence I guess. I haven't screwed anyone over yet.

Sure, I'll have a few bugs show up over time, but since I've given them so much diagnostic data and logging, it's very easy for them to describe the exact conditions, so I can almost always figure out what went wrong and make a fix.

The last major project I finished contained 7 416s, 350 Micromaster drives, thousands of IO points, etc, and they don't even have the source code. It has been over a year and a half, and the system is chugging along 24/7 with only a couple of phone calls from them.

That said, does anyone need a pretty good S7 guy? My current project is nearing completion, and I am ready to tackle something else.

3) Alarms/PB's from an HMI(TP270) grouped in a DB? or?

Click to expand...

Alarms via the alarm system in Protool (TP270) is one of the few places where I recommend to use Merkers.

Why ?

1. Because editing the symbol comments with Merkers are much easier than with DBs.
I create the alarm texts in Protool, and then I import them into the STEP7 project via an Excel file. Saves me a lot of work and avoids making errors. You cannot do the same with DBs (at least not so easily).

2. You may want to service the alarms in a program block that manipulates all the alarms as words rather than individual bits.
Overall I have found this to be easiest with Merkers.

Longwinded explanation starts here:
I simply use word logic without any indirect addressing at all.
I have found word logic to be easy when the addresses are Merkers, because you can assign symbols with types to say M200.0 (BOOL) and MW200 (WORD).
You cannot do the same with DB addresses. Making a symbol (with a comment) for a BOOL address, blocks you from making a symbol for the same group of bits with a type of WORD.
If you used DB addresses, then you would have to do the word logic without type checking or symbols, and I prefer to have both.
I hope that the above makes sense.

(Quote
Having said that, I'm fairly sure I came across a situation a few months ago where for some particular function (possibly an SFB or SFC) the parameter HAD to be in M memory and not in a DB.


No, there are no limitations that would force you to use M memory, but there are cases where DB data is not allowed. Instead, you would have to create a local variable (in L memory), initialize it with DB data, and use that instead.

Click to expand...

That's true, but as I say I had that problem a few months back and for me, at that time, not being able to use a DB meant HAVING to use M memory. It was only after reading the Threads on good programming practice at SPS-Foren.de last week, that I came to fully appreciate how you could use STATS and TEMPS instead of M memory.

That said Jesper's arguments for using M memory for Alarms was interesting. That part of the job is looming up in the near future, so I'll probably be back soon looking for more info!

Sorry, it's not involved with thread but I MUST say:

Even I haven't used any Siemens (mostly AB, in past also Omron and Mitsubishi), the use/choose of memory areas seems too complicated. Why it should not be made easier (AB is I think good example)?
Also most of people I know who have used Siemens have said, that's far too difficult (read not easy), compared with other brands.

My appologies to Siemens fans.

Hundikoer,
Siemens is not easy, but with the trouble comes power. You can make your own custom functions to control entire entities and re-use them in the same project. For instance all the logic to control a chemical bath can be put in one function reused for several baths with different data blocks to keep the values separate. If I ever get to S7 Guy's level I'm sure I'll be able to make code even more transportable. All that said I'd still rather work with GE or Mitsubishi if starting an original project instead of something that I've done most of before.

I can understand people's frustrations with siemens, But when you get past the first few hurdles - It isnt to bad.

With Respect to S7Guy, I can honestly say that reading his posts gives me a different approach to things and i feel that my progression in the S7 world is down to people like him,Jesper and Many others who frequent this forum.

I now use Array's,UDT's etc within my programming - Something 12 months ago i wouldnt honestly have a clue about.

Still a long way to though

Best Regards

Steve

DesertDog and others
Iam sure that all different brands have their pros and cons, but doing simple things should be easy, even with high-end PLC series.
But I am sure this subject won't give use any reasonable answer (only brand X can do that and brand Y cannot, etc.)

BR
Lauri