s5 and s7 difference

F

Thread Starter

fids

i just want to know the difference of s5 and s7.
what are the features found in s7 that can't be found in s5. that's all thanks.
 
M

Michael Griffon

The first thing to mention is that there are two completely different kinds of S7, the S7-200, and the S7-300/400. There is no resemblence between these two other than the colour of the case.

The S7-200 is a very conventional PLC and is very easy to program. It requires significantly less programming work (and a smaller program) to control a machine using an S7-200 than it would be to do the equivalent with an S5. The programming software is easy to use, and the product manual is much better than the usual from Siemens.
The S7-200 however is limited in application to smaller machines, and has a
smaller range of I/O modules available. The networking capability is also limited. The larger S7-200 CPUs are equivalent in capability to an S5-95U (except for the range of available I/O modules). If it fits your application though, it is a very good PLC.

The S7-300/400 is directly evolved from the S5 series. Various parts of the architecture have been modified or renamed, but it is recognisable to anyone with S5 experience. This initial recognition may be difficult though, because of the very poor documentation which is available. The documentation seems to consist of two types - overly simplistic (almost childish with the cartoons), or overly complex (you have to know exactly what you are looking for and
where it is located before you can find it).
There is a much wider range of specialty I/O available than for the S7-200 although not as much as there was for the S5. The networking seems to be quite extensive (as long as you want to talk to Siemens stuff).

I won't try to make a long list of what is different between the S5 and S7-300/400. I will just mention what I found most significant from a programming perspective.
- FBs have become FCs, and PBs have become FBs. There are no SBs. Both FBs and FCs can take formal parameters.
- There isn't the same limitations on what instructions can be used in certain types of blocks.
- DBs still exist, but some CPU models allow fewer of them. Watch out, because the software will let you program them, the CPU just won't let you download them.
- OP communication is built in - no more FB5x.
- Memory addressing follows (sort of) the IEC guidelines. Flags are 'M' instead of 'F', and data block addressing is more flexible.
- FBs (which you now use instead of PBs) can have local memory in the form of an "instance data block" (IDB) which you can associate with each FB. This IDB is separate from any regular data block which you may be using for conventional purposes. The intention is that you create variables which are local to that FB (which would be most of them) in the IDB. Some people use IDBs, and some don't.
- FCs (which you use in place of S5 FBs) can also have local memory, but none of it is "static" - it is non-retentive and the contents are lost as soon as the scan exits the FC. This is intended as temporary scratch memory (instead of having S5 "scratch flags").
- There are more data types, and the PLC is more picky about using the correct types in the intended way. This is theoretically "better", but can be inconvenient at times when you want to address individual bits in a byte. You have to work around this by various indirect means.
- There is a big selection of "standard" blocks (FCs), but there are very few of them which I would find useful in any application I woud do.
- The PLC can operate on double words (4 byte words) and can do floating point math.
- There is a genuine one shot nstruction. Actually there are 2 - positive and negative transition.
- There are various new instructions and addressing modes and some changes to existing ones. The special OBs have also changed.

I also have some general comments on using the S7-300/400 programming software (Step-7). The S7-200 uses entirely different software, and the following only applies to Step-7.
- The software (Step-7) is rather overly complicated for what it actually does. There is also more work involved in starting a program. I learned it just by using it, but a lot of people find it hard to understand without taking the training course.
- The way the programs are stored on disk makes managing a collection of them a big headache. There are literally hundreds of files involved in one program nested deeply in what must be dozens of subdirectories which the software creates. If you are trying to find a file date stamp to see when someone last worked on a program, you are out of luck. You will need to have very good procedures for managing your programs, and some very disciplined people. When dealing with outside contractors (who don't have to live with the results of sloppy working practices) you are guaranteed to have trouble.
- The disk copies of the PLC programs are enormous. 10 to 20 megabytes is not unusual for a program that probably only has a total of 100K or less of actual program and symbols. I would suggest zipping each program when you store it and include a date version as part of the name (e.g. "ABC123 15-JAN-2002.ZIP").
- You can "integrate" Protool/Protool Light with the Step-7 software, but we've found (as end users) that the disadvantages of this outweigh any hypothetical advantages.
- There is a "light" version of Step-7 which is cheaper, but it can't use any I/O modules except the simpler ones or any networking functions.
- There is a large collection of add-on software packages, but I haven't used them in a real project.

There is software available that will convert most of an S5 program into an S7-300/400 program. The reason it can do this is that the S7-300/400 was designed to make this transition possible. You should find the S7-300/400 rather familiar once you get over the different look. Read up on the memory addressing, and also the data types.
 
E

Eulalio Aguilera

S7 is an actual PLC from siemens, so there ara instructions in the software of S7 that you can't use or find in S5. Also there are more
dedicated cards for s7 easier to program.
S5 software is most found in DOS.
s7 is easier to use by windows based software.

The programing strategy is the same one.
 
S

Siemens_S7_User

A comment on Michael Griffin's response-

Learn how to use the "archive" and "retrieve" and your programs will not be so large.

If you click on blocks and look to your left- there is a column called "last modified" there is the last time someone changed and saved your program.

Name these??
"You can "integrate" Protool/Protool Light with the Step-7 software, but we've found (as end users) that the disadvantages of this outweigh any hypothetical advantages.

As you can see I am a Siemens fan but you dont know Step 7 very well.
 
D

Donald Pittendrigh

Hi All

Mr Griffin's evaluation of the S5 and S7 differences has about it the jaded hallmark of a Simatic S5 basher of the late 80's and early 90's. No doubt he feels his opinion to be valid however there were some very important issues that he missed. I will confine my comments to the S7300 and 400 range of PLC's, I personnally feel the S7200 is the proverbial "Mickey mouse" gimmick, although it does have some desirable features related to size and cost, and some features that make it the superior PLC of choice for low end applications. I do not operate much at the bottom end of the PLC food chain so have little experience of these little PLC's.

There are obviously several similarities between S5 and S7 and that is rather obvious as they are both programable in the same 4 basic languages. This however is where the similarity really ends, the S5 package for all its supposed windows compatibility has been ported from the CPM operating system, there have been comments by others labelling as a DOS pakage. I am sure its originators are flattered, they should be. It is a CPM package, until very recently it ran on a CPM emulator under DOS.

There are some options such as Hi Graph and SCL that are advanced programming packages for the S7 that had no parallel in the S5, these packages make things possible on the S7 that were not even dreamed about in S5.

S7 is programmed using a windows package which is critically resource hungry, there are certain hardware benchmarks which if not realised will make your S7 programming experience a misery.

Generally speaking Mr Griffin is correct in his observations about this package, I for one despite being a big Siemens fan, have always felt that the step7 package misses the ability to switch the programmer on and quickly make a program evaluation and then switch off again. I have never timed it but it probably takes from 10 to 15 minutes for me to unpack my programmer until I can see the contents of the PLC program. Some scaled down, quick and dirty version should be available for this type of need.

The Step 7 package despite the above criticisms is a programmers dream, it has fully customisable screens which allow you to set up the appearance and operability of the package with many flexible options. There are many tools available which can be switched on or off, to deal with symbols and comments while programming, and various drop down menus and pick lists that allow you to quickly and effectively find the address you are looking for, provided your symbols list is corectly set up.

It is true that the program files are cumbersome in the structure in which they are stored on the hard drive. At the cost of hard drive real estate today, even in the flea ridden South African economy, the size and no. of files the program uses are of very little interest. Mr Griffin incorrectly implies/states that it is not possible to find out details of the file changes by way of time and date stamps. Every program block, and I don't mean PB, I mean every bit of code which constitutes a block, has its time and date of origin and time and date of last modification tracked, this is displayed in the default setup of the programming package in the block list, and if you missed this one, you were clearly not paying attention. In addition every block in the program can be compared to the same block in another program file or in the PLC to determine changes in the last valid date and time stamp. This function does not require the inspection or validation of the directories on the HDD, it is a standard button pushing Step 7 function. Once again if these basics of the Step 7 package have not been mastered then your appreciation of the package is not likely to be too good.

The issue of backing up S7 programs is also a standard button pushing excercise, most programs for single PLC backups will be stored on one stiffy with ease, either in arj or zip format, there is no need to pick directories and files for the backup, the programming package is simply told where to store the backup, what Step7 program it is you wish to backup, and which of the 2 file formats you require, click OK and the job is done. Hardly a complicated excercise as Mr Griffin has implied. Re-creation of the program file is as simple.

The remainder of the evaluations made by Mr Griffin are in the main correct however some clarity is required on the issues of FC's and FB's. An FB has only one feature that an FC doesn't, and that is an instance data block. In every other respect they are identical in the programming capabilities. An instance data block is an automatically created DB which is created in the image of the FB variable header. It forms the brunt of the difference between S5 and S7 programming. In most S5 PLC's it was not possible to address DB's in bit form. In the S7 it is possible to use data in any form and format you desire. The data structure of the header, and thus the DB, can be set up to allow for the most comprehensive naming structure of variables imaginable. For example a variable in the data block for a machine has the structure

"Positioner_data.Power_pack.Pump_1.Overload"

as opposed to :

"Positioner_data.Power_pack.Pump_1.Isolator"

or

"Positioner_data.Power_pack.Pump_2.Overload"

and

"Positioner_data.Power_pack.Pump_2.Isolator"

This is acheived by the simple and effective grouping of common variables into STRUCT's in the DB. The naming convention if correctly applied forces an ordered organisation of variables into structured blocks of data. The random undisciplined use of flags and other memory areas is thus avoided, the use of uncommented or undocumented variables without symbols is not possible. Talk about discipline of contractors in the creation of backups and program changes, how about the discipline to plan and document every variable in the PLC according to a designed master plan and forcing all programmers and maintenance personell to adhere to the plan. By allowing the use of instance data blocks ONLY for the temporary and intermediate storage of variables it is possible to control standards as has never been done before. If Mr Griffin and any others have missed this point in S7 programing, they can be excused for thinking that an S7 is an S5 in fancy clothing, but their opinions will be validated by the depth of their understanding.

There are many instructions in the S7, especially for arithmetic calculations, which simply were not dreamed of in S5, it is difficult for me to name a function I would like to have in the S7, that doesn't exist, and I do a great deal of rather advanced programming.

There are a great number of standard FB's and FC's and for that matter OB's as well, this observation is correct. A great deal of these blocks are made available for the sake of adherence to the IEC1131 and in my opinion are of secondary importance. There are standard function blocks which are used to read diagnostic information from the PLC, for example to know about the status of the PLC hardware. There are blocks which are used to implement the many and varied communication functions of the S7, there are standard PID control algorithms, these all included on the CPU at no extra charge. The documentation of these blocks is perhaps difficult to handle as has been stated, largely because of the sheer volumes of information and the difficulty of indexing it to suit all searches for all people from all perspectives, howevre Mr Griffin and of course others, the next time you need to access a manual for information about one of these blocks, I would suggest you try "picking" it with your mouse from within the program editor and pushing F1 - the help key - I find the answer this way for 99.9% of my queries, for the other 0.1% I usually find the cross references in the index of the elctronic (CDROM) or a text search using the F3 button provides the answer painlessly. I for one do not find the S7 documentation to be interesting reading material, I doubt that anyone has started reading the standard FB manual on page 1, and turned off the light after reading the last page of the book, rolled over and had a good nights sleep. There is a horse and carriage thing in the presentation of such documentation and if I may propose putting the ability to find the right answer in the right place in the shortest possible time, is the first and foremost requirement. and the in depth documentation of of the nitty gritty details second, I say to Siemens 10 marks out of 10 on both counts. It ocurs to me that most of us don't A) use the right mouse button often enough, and B) press F1 often enough.

Now this is getting to be a long story and there is still a lot to say, so on the subject of Protool which was briefly mentioned, there is no reason why it should not be integrated into the S7 package. It operates the same way whether this is done or not, for non-S7 programs, and for S7 programs it is dumb if you do not take advantage of the automatic generation of tags in the OP or TD which is consequently available. This is a hallmark of the Siemens TIA or totally integrated automation concept, which makes the generation of tags and setting up of the communications a matter of childs play. Mr Griffin the reason why FB5? is no longer required is because the S7 does not require a DB as mailbox to ship information up and down between the OP and PLC over profibus. I have not use FAP from an S7 as it would not make much sense but as that is how you were most probably communicating with the S5-OP link, I must add that if you used FAP for the S7 - OP link, you would still need FB5?, only it might be an FC or have a different number.

The hardware on the S7 provides a far greater range of CPU's and I/O cards, thereby allowing you to choose more appropriate hardware for your plant, and hence saving costs. I do not like S7400 I/O cards, I find them incredibly restrictive in the space provided to get all the wires into the front connector. In every machine I have built excepting one, we used Profibus and ET200M for all the I/O's, if I have my way, that's the way it will stay.

The S7 CPU's are much faster than S5, there is virtually no comparison, most CPU's are at least 10 times faster than their S5 equivalents. There are some S5 CPU's that were in the same speed ballpark, but they remained little used as most clients could not afford them, (well that's in my country anyway).

The intelligent modules of S5, were called CP's IP's and WF's. Mr Griffin is correct, there were a great deal of them, there was also a great deal of duplication. The functions which were covered by the S5 peripherals, are all available in S7 equivalents, there are far fewer S7 modules as the modules are more flexible and therefore cost effective. Don't forget that the S5 set of peripherals grew according to industry needs as the product range matured, the S7 range was planned and mostly available on the day the first PLC hit the streets. Many S5 applications required the use of these intelligent modules, but due to the superior processing power and speed of the software and hardware of the S7, you may not always need to use an intelligent module, a software solution would do the job.

I am not going to address the issue of the addressing ranges of the PLC, I consider them to be adequate for the purpose for which the PLC was intended, in other words, if you select the right CPU for the job in terms of processing power, I believe Siemens has the recipe right, and you will also have an appropriate addressing range for the intended function. This is a matter of opinion and of course there are some areas of automation where the PLC program performs only trivial program functions but has a great deal of inputs and outputs, for these exceptions you will unfortunately just need to use a bigger CPU, lifes like that, full of exceptions.

Lastly there was a criticism made by one of the respondants to this thread about the PLC not reacting to a DB number that was out of the range for the PLC, I do not understand this, it is not possible to download a datablock to the PLC and call it up in the program if it is outside of the addressing range of the machine, this much is clear, if this was done in S5 the PLC would go into stop automatically but could be programmed to keep running if that was the desired reaction. In S7 the system works differently, and smarter, the PLC does not by default, go into stop, it does have a SF light on the CPU which will come on to let you know there is a problem. When this light is on the CPU has diagnostic information to communicate about its status, this can be read out in great detail usinbg a programmer, or, can be read without a programmer by using standard FB/FC's and then displayed on an HMI. There is nothing the PLC cannot find out about its status, inside the program you can get as much and more information than the S5 ISTACK by using std FB/FC's If you need the PLC to go into stop for such a prgramming error, this is a simple thing to set up. I am sceptical that it was possible to load a DB with a number outside of the available addressing range into the CPU, but I will not make the statement that it is not possible as I have never tried to do this, I have always checked the addressing range of the CPU before designing the software and trying to download it, but that's just the way I am.

Bye for now
Donald Pittendrigh

 
L

Luca Gallina

At 22.56 15/01/02 -0500, you wrote:
<clip>
> - The way the programs are stored on disk makes managing a
>collection of them a big headache. There are literally hundreds of
>files involved in one program nested deeply in what must be dozens of
>subdirectories which the software creates. If you are trying to find a
>file date stamp to see when someone last worked on a program, you are
>out of luck. You will need to have very good procedures for managing
>your programs, and some very disciplined people. When dealing with
>outside contractors (who don't have to live with the results of sloppy
>working practices) you are guaranteed to have trouble.
<clip>



Hello Michael,

what above sounds a bit too catastrophic... ;-)

Each block has its own "created" and "last modified" event timestamping (at least my Step7 v5.1 shoes them), thus program modifications date/time should be easily traced within S7manager, with no need of checking the project internal files date and time. Anyway I never relied on automatic timestamping, I don't want to be misled by an uncorrect PC clock setting. I prefer a good bunch of backup zipped copies (named in yyyymmdd format where 20010205.ZIP stands for February 5, 2001 , so they show already sorted in any file browser) where the programmer himself assign the correct date to each ZIP file, taking care of including a text file with the necessary notes.

Each S7 block allows lots of comments, there's no reason why not to write a log of modifications along with date and name. The "sloppy programming practices" and undisciplined maintenance people will guarantee troubles using any PLC...


<clip>
> - You can "integrate" Protool/Protool Light with the Step-7
>software, but we've found (as end users) that the disadvantages of this
>outweigh any hypothetical advantages.
<clip>

This interests me...which are the disavantages (as end users) of integrating Protool projects into S7 projects?

best regards
Luca Gallina
 
N

Nijssen.Ronald

With the S7 Siemens has created a PLC that is IEC1131 compliant in his programming languages, yet still supports programs for the S5. To be more precise, 98% of the application ports without problem, there are some uncommonly used S5 instructions that are different in S7 In S5 you had OB's (Organization Blocks )(other PLC's call them Tasks), in S7 you do as well in S5 you had DB's,(Data Blocks) in S7 as well, but: in S5 a DB contained WORD data, in S7 the Data is symbolic and of any elementary or complex data type (e.g. structures, arrays). You can create a WORD only DB in S7 to make it look like a S5 DB In S5 you had PB's (Program Blocks), in S7 you have FC's (Functions) In S5 you had FB's (Function Blocks), in S7 you have FC's In S7 you have a FB as well, but it is the IEC FB, this implies, Inpu-Output-Static Data that instantiates every time in a Data structure
(DB) when you call the FB. This can result in very efficient programming methodologies. In an FB you can also declare other FB's as static variables, thus allowing one FB (for example for a Tank) also to contain the FB's for several Valves around the tank. Each time you call the "tank" FB you generate its Valve FB's automatically

In Step7, the engineering tool for SIMATIC (S7, Networks, HMI) projects, you can use up to 8 languages within one project

Regards
Ronald
 
M

Michael Griffin

> Each block has its own "created" and "last modified" event timestamping (at
> least my Step7 v5.1 shoes them), thus program modifications date/time
> should be easily traced within S7manager, with no need of checking the
> project internal files date and time.

Yes, but you have to start up the software and load the program to see that. You can't use the date stamp from Windows Explorer. Possibly there is one particular file that I could look at, but if there is I don't know which one that is. If I have to organise a collection of revisions, I generally have a lot more things to worry about than just some PLC programs.

> Anyway I never relied on automatic timestamping, I don't want to be misled
> by an uncorrect PC clock setting. I prefer a good bunch of backup zipped
> copies (named in yyyymmdd format where 20010205.ZIP stands for February 5,
> 2001 , so they show already sorted in any file browser) where the
> programmer himself assign the correct date to each ZIP file, taking care of
> including a text file with the necessary notes.

We've taken a similar approach (as I noted in my original message). However,
we use a three letter month code instead of a numeric one, so that it is very obvious to someone who doesn't know the 'code', that the characters represent a date.

<clip>
> The "sloppy programming
> practices" and undisciplined maintenance people will guarantee troubles
> using any PLC...

That is true, but some systems give people more rope to hang themselves
with. I thought the originator of this thread would appreciate the suggestion.
By the way, I find "sloppy practices" to be more common among programers subcontracted to machine builders than among maintenance personnel. Some of them tend to win their business on a "low bid" or "immediately available" basis and more often than not set a project further behind rather than contributing to it. Some people have difficulty understanding that the less expensive programmer is the one who doesn't have to keep coming back to fix
things.

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

Michael Griffin

I will leave out the personal comments. I am sure Mr. Pittendrigh won't mind if I don't reply in the same vein.

On January 18, 2002 11:47 am, Donald Pittendrigh wrote:
<clip>
>I personnally feel the S7200 is the proverbial "Mickey
> mouse" gimmick, although it does have some desirable features related to
> size and cost, and some features that make it the superior PLC of choice
> for low end applications. I do not operate much at the bottom end of the
> PLC food chain so have little experience of these little PLC's.

You seem to have some admiration for it, even though you feel it is a "gimmick". It is really quite a serious PLC, particularly the 22x series. The small PLCs of today are being used in applications which used to use the larger models 10 years ago. The bottom end is a growing market. And yes, in this environment, size and cost matter a lot more to customers than features or the convenience of the programmer. I would say though that I could write a program for an S7-200 with less effort than I would expend to accomplish a similar task with an S5.


> There are obviously several similarities between S5 and S7 and that is
> rather obvious as they are both programable in the same 4 basic languages.
> This however is where the similarity really ends, the S5 package for all
> its supposed windows compatibility has been ported from the CPM operating
> system, there have been comments by others labelling as a DOS pakage. I am
> sure its originators are flattered, they should be. It is a CPM package,
> until very recently it ran on a CPM emulator under DOS.
<clip>

No, you are confusing the PLC with the programming software. When I said that someone who was familiar with the S5 would recognise the S7-300/400, I was referring to the PLC architecture, not the programming software. I would say that Siemens went to considerable effort to make the architecture an evolutionary one rather than doing something radically different. The intention no doubt, was to make the transition from S5 to S7 easier for their
existing customers.

Indeed, now that I think of it, Siemens wrote a manual called "From S5 to S7" (or something similar to that) which I found to be the most usefull information on finding out how the S7 really worked. I would strongly recommend this document (it can be down loaded from the Siemens web site) to the originator of this message thread.


> S7 is programmed using a windows package which is critically resource
> hungry, there are certain hardware benchmarks which if not realised will
> make your S7 programming experience a misery.

Actually, I have found it to be not too bad, provided you have enough RAM to run it and a big enough hard drive to load it on. You don't need the latest super fast computer to use it. Perhaps it may slow down though with a really
large program or if you have a lot of blocks open at one time.

> Generally speaking Mr Griffin is correct in his observations about this
> package, I for one despite being a big Siemens fan, have always felt that
> the step7 package misses the ability to switch the programmer on and
> quickly make a program evaluation and then switch off again. I have never
> timed it but it probably takes from 10 to 15 minutes for me to unpack my
> programmer until I can see the contents of the PLC program. Some scaled
> down, quick and dirty version should be available for this type of need.
<clip>

This has been one of my actual criticisms of it, at least for users like ourselves. We have a large number of small machines (mainly located along conveyor systems), each with its own PLC. We don't need the features intended for managing large systems. The full software package is rather expensive too. While this is somewhat of a problem for people who use it a lot, it can be a serious problem for small machine builders who only use it ocassionally. There aren't a lot of Siemens users in my area, and it is difficult for someone local doing business with us to pay for a package like that out of the business they do with the few Siemens customers there are around. This restricts the number of companies we can hire for something involving an S7-300.

Siemens has tried to address this in two ways. One is with a Step-7 "mini" package. This is a lower cost, restricted version of the regular Step-7. It oesn't address the problem of too many features to learn, just the cost of buying it. However, the way the package was restricted makes it not very useful. Rather than limiting you to only using the lower end CPUs, it limits the type of I/O modules you can use. For example, you can't use a servo module with it. The Siemens reps discourage people from buying it, because they know that the customer will have to upgrade before long anyway when they need to use a module it doesn't support. Furthermore, you can't use any networking functions.
The second way they have attempted to address this problem is with a "Step-7 Light" (or something similar to that). This is a very different package which is supposedly (I haven't seen it yet) low cost and easier to use. However, I believe it still has the limitations on which I/O modules you can use, and no networking. It has the additional problem of that it uses a different file format than the regular Step-7. While I am not a fan of the file format Step-7 uses, I am even less of a fan of conversion programs as they often will not work properly on some programs.


> It is true that the program files are cumbersome in the structure in which
> they are stored on the hard drive. At the cost of hard drive real estate
> today, even in the flea ridden South African economy, the size and no. of
> files the program uses are of very little interest. Mr Griffin incorrectly
> implies/states that it is not possible to find out details of the file
> changes by way of time and date stamps. Every program block, and I don't
> mean PB, I mean every bit of code which constitutes a block, has its time
> and date of origin and time and date of last modification tracked, this is
> displayed in the default setup of the programming package in the block
> list, and if you missed this one, you were clearly not paying attention.
<clip>

Perhaps I wasn't clear enough in my explanation, but I believe I said the *file date stamps* could not be used. The internal date stamps you see in the "Step-7" software are obvious - you can't miss them. I haven't found any obvious or easy way of using the date stamp of a particular *file* representing the entire program though. If you know an answer to that, I
would appreciate it.

If you are sorting through the files for a project (of which the PLC is only one element) to organise them, you don't want to have to start up the programming software just to see which is the newer version. I believe you earlier commented that you found the software rather slow to start up.
When you only have your own work to organise and sort out, it is easy to keep things straight. When you have to sort out other people's as well as your own, it isn't so easy. Sometimes stuff is missing, sometimes they give you the same thing twice, sometimes they give you something that is several versions old. Now multiply this problem by several hundred programs of various types plus thousands of schematics, plus operating manuals, plus etc. If you have a date stamp which is close to the expected time and date, you know that what you have is probably correct. This is why computers date stamp their files.
You might say that "this is a project managment issue", well I won't disagree. It's just that some types of data are more difficult to manage than others.

> The issue of backing up S7 programs is also a standard button pushing
> excercise, most programs for single PLC backups will be stored on one
> stiffy with ease, either in arj or zip format, there is no need to pick
> directories and files for the backup, the programming package is simply
> told where to store the backup, what Step7 program it is you wish to
> backup, and which of the 2 file formats you require, click OK and the job
> is done. Hardly a complicated excercise as Mr Griffin has implied.
> Re-creation of the program file is as simple.

The "archive" function of Step-7 just calls pkzip. Whether you use the archive function in Step-7, or whether you use Winzip from Windows Explorer (right click on the directory), the end result is the same. People can decide for themselves which they find easier. You're going to have to use Windows Explorer to copy the zipped file somewhere in either case. The point is though, you should zip everything before you store it even if storage space is not an issue, and you should give the file a version number so you can track it.

> The remainder of the evaluations made by Mr Griffin are in the main correct
> however some clarity is required on the issues of FC's and FB's. An FB has
> only one feature that an FC doesn't, and that is an instance data block.
> In every other respect they are identical in the programming capabilities.
> An instance data block is an automatically created DB which is created in
> the image of the FB variable header. It forms the brunt of the difference
> between S5 and S7 programming.

The instance data block is also what gives FBs static data.

> In most S5 PLC's it was not possible to
> address DB's in bit form.
<clip>

I wasn't aware of this. The S5 references I've read didn't say anything about any restrictions on CPU version when addressing individual data bits, although I admit the feature is rather poorly documented to begin
with. Which CPUs was this not allowed in? This is a feature I've seen used very rarely and I avoid it myself.

> By
> allowing the use of instance data blocks ONLY for the temporary and
> intermediate storage of variables it is possible to control standards as
> has never been done before. If Mr Griffin and any others have missed this
> point in S7 programing, they can be excused for thinking that an S7 is an
> S5 in fancy clothing, but their opinions will be validated by the depth of
> their understanding.
<clip>

I don't believe I said that the S7 is just an S5 in a new package. I said that anyone who was familiar with the S5 would recognise an S7. I don't know what other PLCs you have worked with, but if you compare an S7-300/400 to various other types of PLC, you will see a much stronger resemblence between an S7-300/400 and an S5 than you would with any other type of PLC.
The OBs, FBs. FCs, and DBs are are all easily understood by someone familiar with an S5 even if they are not exactly the same as the S5 equivalents. The I/O addressing is similar, the timers and counters work the same, and virtually every significant S5 feature has been carried on into the next generation in some form.

Yes, the S7-300/400 has new features, and I don't doubt that many of them are better than what was in the S5. However, that wasn't the point. The point is that someone who is familar with S5 PLCs (such as the originator of this
thread) will not have to learn a completely different PLC with the S7-300/400. There is continuity between the generations. I believe that Siemens intended it this way.

> The documentation of these blocks is perhaps difficult to handle
> as has been stated, largely because of the sheer volumes of information
> and the difficulty of indexing it to suit all searches for all people from
> all perspectives, howevre Mr Griffin and of course others, the next time
> you need to access a manual for information about one of these blocks, I
> would suggest you try "picking" it with your mouse from within the program
> editor and pushing F1 - the help key - I find the answer this way for
> 99.9% of my queries, for the other 0.1% I usually find the cross
> references in the index of the elctronic (CDROM) or a text search
> using the F3 button provides the answer painlessly.

I think you are missing the point here. The question isn't one of how to look up the syntax for a particular instruction. The problem rather is that of someone who doesn't know anything about the PLC. He can worrying about things like where the 'F1' key is after he knows where to start. There is no point in even loading the software on your computer until you know something about the PLC. Perhaps this point didn't strike you as significant because after working with S5 PLCs for years, you found the S7 to be, well - familiar.

My criticism of the S7-300/400 documentation is that it consists of either
colourful cartoon characters leaping about the pages joyfully telling you how wonderful the S7 is (I believe you mentioned something about some other PLC being "Mickey Mouse"?), or the sort of gory detail of use only to someone who is already intimately familiar with what they were dealing with. I found the former to be an annoying waste of time, and the latter of no help in discovering how it all worked together.
The one document that I found to be really useful in understanding the S7-300/400 architecture was the one written to explain the S7 to people already familiar with the S5.

> I for one do not find
> the S7 documentation to be interesting reading material, I doubt that
> anyone has started reading the standard FB manual
> on page 1, and turned off the light after reading the last page of the
> book, rolled over and had a good nights sleep.
<clip>
I have seen well written manuals (for other products), and I do actually read them. Pretty often they will tell you how you are supposed to use their product, and usually they are right.


> Now this is getting to be a long story and there is still a lot to say, so
> on the subject of Protool which was briefly mentioned, there is no reason
> why it should not be integrated into the S7 package. It operates the same
> way whether this is done or not, for non-S7 programs, and for S7 programs
> it is dumb if you do not take advantage of the automatic generation of
> tags in the OP or TD which is consequently available.
<clip>

Since we have a lot of small machines, we have a lot of OPs, but relatively few tags per OP. Automatic generation of tags for the OP isn't really a big deal in this situation. On the other hand, we will more often need to change just the OP program (to change some text) or sometimes to replace an OP (reload the program without changes). Also, most PLC program changes do not involve OP changes.
Since we are dealing with two separate devices whose programs do not often change together, we are dealing with two sets of changes to track and manage. It is easier for us to deal with the OP program separately in these cases. Our needs as end users are different from the person who created the program.

> The intelligent modules of S5, were called CP's IP's and WF's. Mr Griffin
> is correct, there were a great deal of them, there was also a great deal of
> duplication. The functions which were covered by the S5 peripherals, are
> all available in S7 equivalents, there are far fewer S7 modules as the
> modules are more flexible and therefore cost effective. Don't forget that
> the S5 set of peripherals grew according to industry needs as the product
> range matured, the S7 range was planned and mostly available on the day the
> first PLC hit the streets. Many S5 applications required the use of these
> intelligent modules, but due to the superior processing power and speed of
> the software and hardware of the S7, you may not always need to use an
> intelligent module, a software solution would do the job.
<clip>

However, certain Siemens customers have been staying with S5 PLCs (the larger models) because the special cards they needed were not available with the S7 series. I am not familiar with the specifics of these cases, but have only been told of them by Siemens representatives. They said that it will take some time before all the functionality of the older generation is addressed one way or another. It is something for someone to investigate though if they are currently using any specialised cards.
I have been told though that there will be no Basic modules ever. If anyone is using these to decode specialised serial protocols, then they will need to do it in the CPU somehow. We haven't had to address this problem yet, but we will eventually on future projects. We currently have a number of these on CP521 Basic modules on existing equipment.


<clip>
> Lastly there was a criticism made by one of the respondants to this thread
> about the PLC not reacting to a DB number that was out of the range for
> the PLC, I do not understand this, it is not possible to download a
> datablock to the PLC and call it up in the program if it is outside of the
> addressing range of the machine,
<clip>
I believe you are reacting to a caution (not a criticism) I stated about being careful to use DBs that are within range of the CPU model. It is possible to enter a data block into Step-7 that is outside the valid data block address range for that CPU. The CPU will refuse to accept it when you try to download it though.

I've done this so I know it can happen. It was a bit disconcerting though, as I had made a mistake in reading the addressing specifications for that CPU, and then a further mistake in assuming that if the programming software accepted a data block address it must be valid. Some time was lost re-writing the program to work within only half the range of data blocks I thought I could use, but fortunately I wasn't on a critical schedule.
The questions you had about how the CPU would behave with an invalid DB number loaded into it didn't arise, since it refused to accept it and I could only load data blocks into the CPU which were within the valid range.


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

Donald Pittendrigh

Hello Mr Griffin and others

I didn't intend any personal comment, I couldn't effectively do that as I have never met you, the comparison I drew, was intended, and if you are
offended then I have made my point.
Sorry for that.

> I will leave out the personal comments.
I am sure Mr. Pittendrigh won't mind
> if I don't reply in the same vein.
>

> You seem to have some admiration for it,
even though you feel it is a
> "gimmick". It is really quite a serious PLC,
particularly the 22x series. The
> small PLCs of today are being used in
applications which used to use the
> larger models 10 years ago. The bottom end is a
growing market. And yes, in
> this environment, size and cost matter a lot
more to customers than features
> or the convenience of the programmer. I would
say though that I could write a
> program for an S7-200 with less effort than I
would expend to accomplish a
> similar task with an S5.

I have a great deal of admiration for anything with Siemens written on it, excepting a cellular phone, I thought that was rather clear from my lengthy and impassioned response to your first posting. Now enough!

I agree the S7200 is easy to program compared to an S5 there is no way I can find it in my heart to compliment the user friendly aspects of S5 or its programming package, I used it because of the flexibility of modules in the hardware range, and the programming features which other PLCs had only standard function blocks for. I like to master my own destiny when I write software, I hate looping together some other guys blackboxes, I only sleep well at night if I know I did it right, and for that I need to know what is inside, S7200 gives me a bit of a quesy feeling in this regard, but at the end of the day, yes a great little!! PLC, most of the systems I deal with are 1000 I/O plus and require a high degree of automation to which effect I do a fair bit of work in SCL and Hi-Graph. S7 200 cannot do this and to this effect in my working environment makes it "mickey mouse", not a derogatory comment, but something like patting your kid brother on the head.......

> No, you are confusing the PLC with the
programming software. When I said
> that someone who was familiar with the S5 would
recognise the S7-300/400, I
> was referring to the PLC architecture, not the
programming software. I would
> say that Siemens went to considerable effort to
make the architecture an
> evolutionary one rather than doing something
radically different. The
> intention no doubt, was to make the transition
from S5 to S7 easier for their
> existing customers.
> Indeed, now that I think of it, Siemens
wrote a manual called "From S5 to
> S7" (or something similar to that) which I found
to be the most usefull
> information on finding out how the S7 really
worked. I would strongly
> recommend this document (it can be down loaded
from the Siemens web site) to
> the originator of this message thread.

I would strongly endorse the first of the above statements, on the subject of the architecture, I wonder how they would have changed it, had they
decided to be "revolutionary" about it.

I have made some minor (at this stage) experience of PLC direct and find the new approach to their programming of logic in Visio to be most
refreshing, however there is still a similarity between this most non-conformist and revolutionary approach, and the Siemens architecture, at the end of the day it is rather difficult to visualise any program as anything other than a collection of subroutines ( PB's and FB's and FC's) called up and managed by some overall control program (OB's), and what you call them and how you control the Global and local data needs of the software doesn't change the fact that it is required and what its function is.

> Actually, I have found it to be not too
bad, provided you have enough RAM to
> run it and a big enough hard drive to load it
on. You don't need the latest
> super fast computer to use it. Perhaps it may
slow down though with a really
> large program or if you have a lot of blocks
open at one time.

You are correct in the assesment of the processor speed althoug it makes a difference it does not improve the performance as much as the PC's resources do, lots of RAM is not enough, I have a machine with a 512 and 256 Mbyte RAM chip in, it compiles a protool file in 13 seconds, my laptop has 512 meg, compiles the same file in 27 secs and my PG740 with admitedly only a pentium MMX something or other, and 128Meg of RAM takes aroung 20 minutes.

I do program in SCL Hi-Graph and ProTool fairly extensively, if you only use these tools sometimes you may not notice, but if you sit with protool or Hi-graph all day, you soon see the meaning of resource hungry.

I have clipped out the responses on the Step7 light etc. I understand they are limited capability budget versions of the Step 7 package, I have never looked at them as they do not provide the features I require, and have the same functionality as the full package which to me means the same interface, just as slow, and not capable of dealing with the spectrum of hardware likely to be found in a typical PLC in my environment.

> Perhaps I wasn't clear enough in my
explanation, but I believe I said the
> *file date stamps* could not be used. The
internal date stamps you see in the
> "Step-7" software are obvious - you can't miss
them. I haven't found any
> obvious or easy way of using the date stamp of a
particular *file*
> representing the entire program though. If you
know an answer to that, I
> would appreciate it.

I also thought they were rather obvious, why can't you use the date and time stamp on the ZIP file. I retain all my backups as a record of the job in progess. I use the ZIP form of backup not the ARJ, not for any particular reason, and I use 4 alphas to identify the file, and 4 numerics to identify the date, when I create the file name, I seldom make multiple backups during the same day of work however sometimes it is neccessary when you are about to do something which you suspect will have an undesirable outcome, these files I store in a directory of my hard disk called Trash and give them any old name, the last backup at the end of the day stays on the harddrive. At the end of the project I clean up the directory for that machine and keep only the backup I handed over to my client. The Zip file, externally will not tell me what the status of the S7 files is inside of itself, the only way to know who did what is toenforce your contrators to submit a change report, you could do this in a simple text or excel file recording the salient points. If you can't trust the guy he will write any old rubbish in the change report as well. I don't know how this procedure can be best controlled in your environment, but I am sure the directory structure of the S7 project, cumbersome as it
surely is, has little to do with the matter.

> The "archive" function of Step-7 just
calls pkzip. Whether you use the
> archive function in Step-7, or whether you use
Winzip from Windows Explorer
> (right click on the directory), the end result
is the same. People can decide
> for themselves which they find easier. You're
going to have to use Windows
> Explorer to copy the zipped file somewhere in
either case. The point is
> though, you should zip everything before you
store it even if storage space
> is not an issue, and you should give the file a
version number so you can
> track it.

The correct form of an S7 backup is an ARJ or a ZIP file generated from inside Step7, there is no need to use explorer to manage the backup process. I don't and I also backup onto the server on my office network from within Step7. If you persist with manual intervention with the Step7 directory structure by running PKZIP externally, you are surely going to pay the price sooner or later, and it will never be simpler than the button clicking tools Siemens has provided on the File menu for that prupose.

> The instance data block is also what
gives FBs static data.

This and so much more, I have too many "programmers" in my environment who figured their experience on S5 would get them around the corner when changing to S7. The, "from S5 to S7 or whatever it is called book", to which you refer, was very good, but I'd rather it had never been printed, S7 is very very different to S5 and if you don't look at it from a new perspective when you start making the transition, then you will always be looking for the DO instruction and others like it. S7 runs on S5 type programs this is true, but it runs better and looks better and is easier to work with when you maximise your use of the NEW features such as instance DB's.

> > In most S5 PLC's it was not possible to
> > address DB's in bit form.
> <clip>
>
> I wasn't aware of this. The S5
references I've read didn't say
> anything about any restrictions on CPU version
when addressing individual
> data bits, although I admit the feature is
rather poorly documented to begin
> with. Which CPUs was this not allowed in? This
is a feature I've seen used
> very rarely and I avoid it myself.

In the S5-115U with 945 CPU and in the S5-135U from the CPU 922 upwards and therefore in the 155U as well, and if I am not mistaken, also in the 150S, it is possible to do bit addressing of DB areas. It is hardly a tool to be avoided, to say this, is to say it is O.K. to use F0.0 but not to use FW0, to every function it own character. In the less powerfull CPU's it takes a ton of logic to deal with the status of one bit within a DW, there were some very limited bit handling features in these lower CPU's, but I don't recall using them very often, we used to transfer the DW's to "scratchpad flags" at the beginning of the block and then save them again at the end, in the long run it was easier.

> I don't believe I said that the S7 is
just an S5 in a new package. I said
> that anyone who was familiar with the S5 would
recognise an S7. I don't know
> what other PLCs you have worked with, but if you
compare an S7-300/400 to
> various other types of PLC, you will see a much
stronger resemblence between
> an S7-300/400 and an S5 than you would with any
other type of PLC.

Now here is an interesting point, I only work with Siemens PLC's, I try from time to time to find alternatives, but I believe that my real skills are my understanding of machines and software, and this is what I sell to my clients, I believe I do my client an injustice if I decide to try and specialise in all PLC's instead of just one, I intend to know and understand as much as I can possibly find time for, about the PLC range I support. To involve myself with other brands of PLC's dilutes the time I have available to deal with the product in depth. I have turned down contracts because the customer won't use a Siemens PLC and I no doubt will do it again. Some clients have spent money on training and spares in some other PLC range, and the investment is to big to allow them to make a change, I cannot serve these guys as I feel I should, and so would rather someone else did the job. I do not believe the measurement of voltage is better done with a Fluke multimeter than any other, it is a question of the tool you know and understand best, it is for this reason I make the above statements with great conviction!!!

> The OBs, FBs. FCs, and DBs are are all
easily understood by someone familiar
> with an S5 even if they are not exactly the same
as the S5 equivalents. The
> I/O addressing is similar, the timers and
counters work the same, and
> virtually every significant S5 feature has been
carried on into the next
> generation in some form.
> Yes, the S7-300/400 has new features,
and I don't doubt that many of them
> are better than what was in the S5. However,
that wasn't the point. The point
> is that someone who is familar with S5 PLCs
(such as the originator of this
> thread) will not have to learn a completely
different PLC with the
> S7-300/400. There is continuity between the
generations. I believe that
> Siemens intended it this way.

This comes back to an earlier point, the reasons for the similarities between a box of Smarties and a tube of Smarties is obvious. For those
unfamiliar with Smarties, please substitute M&M's , funny, they also kinda look like Smarties, fancy that!!!!

> My criticism of the S7-300/400
documentation is that it consists of either
> colourful cartoon characters leaping about the
pages joyfully telling you how
> wonderful the S7 is (I believe you mentioned
something about some other PLC
> being "Mickey Mouse"?), or the sort of gory
detail of use only to someone who
> is already intimately familiar with what they
were dealing with. I found the
> former to be an annoying waste of time, and the
latter of no help in
> discovering how it all worked together.
> The one document that I found to be
really useful in understanding the
> S7-300/400 architecture was the one written to
explain the S7 to people
> already familiar with the S5.

Siemens documentation has never been the reason why people like the equipment, with this I must agree, but I really don't know what the cartoon characters are, to which you refer, I wish you would scan and email a sample to me at my personal email.

My manuals are all in PDF format or in very conveniently bound A4 size books. I find their content to be to the point and accurate, this as opposed to the old S5 files, in many differing physical sizes, and mostly translated literally from the German manuals, and this by someone with obviously limited capability of the English language. There is no comparison, believe me, I started with S5 PLC's when there were no manuals so I have been there.

> I have seen well written manuals (for
other products), and I do actually
> read them. Pretty often they will tell you how
you are supposed to use their
> product, and usually they are right.

Before I did a single project with S7, I cloistered myself with an S7-416 CPU and some Profibus ET200M cards and I did nothing, and I mean nothing else, for 3 months, but study S7, take it apart break it and then fix it again. I did it this way because I could not afford the specialist training or the time for it, which would require an lengthy and expensive trip to Germany, and there was no-one in my country with the capability to teach me at that time, there probably still isn't.

I have never read any PLC manual from cover to cover for the sake of reading material, for this I would prefer Harry Potter, I have to find the information I want when I need it, quickly, it must be accurate, it must not read like English and sound like German or Vice Versa, Siemens has produced an admirable set of reference tools for the S7 300 and 400, the most impressive move was to put them in PDF form and make them available on the Web for free, 10 points out of 10 to Siemens I wonder what if any other manufacturers do this.

> Since we have a lot of small machines,
we have a lot of OPs, but relatively
> few tags per OP. Automatic generation of tags
for the OP isn't really a big
> deal in this situation. On the other hand, we
will more often need to change
> just the OP program (to change some text) or
sometimes to replace an OP
> (reload the program without changes). Also, most
PLC program changes do not
> involve OP changes.
> Since we are dealing with two separate
devices whose programs do not often
> change together, we are dealing with two sets of
changes to track and manage.
> It is easier for us to deal with the OP program
separately in these cases.
> Our needs as end users are different from the
person who created the program.

I understand what your words mean, I am not familiar with the work situation you describe, but suffice it to say, I designed and commissioned the PLC programs for a series of container crane re-furbishments, I think in the end it must have been a dozen or more, each crane had 2 TD20's on it, the backup of S5 and TD was probably a total of around 15 - 20 files including the Profibus config files. That was a problem, to have one file for the project with all machines in, would have been a dream, that is now possible, and even to have one file per machine would have been an improvement.


> However, certain Siemens customers have
been staying with S5 PLCs (the
> larger models) because the special cards they
needed were not available with
> the S7 series. I am not familiar with the
specifics of these cases, but have
> only been told of them by Siemens
representatives. They said that it will
> take some time before all the functionality of
the older generation is
> addressed one way or another. It is something
for someone to investigate
> though if they are currently using any
specialised cards.
> I have been told though that there will
be no Basic modules ever. If anyone
> is using these to decode specialised serial
protocols, then they will need to
> do it in the CPU somehow. We haven't had to
address this problem yet, but we
> will eventually on future projects. We currently
have a number of these on
> CP521 Basic modules on existing equipment.

I would like to help, please forward my email address to someone who has this problem, he is being misled.

I don't know of any S5 intelligent module that cannot be plugged into an S7 PLC I have personally done one, I think it was a WF721, because the client was mislead by a mis-informed salesman about the avaiability of SSI interfaces in the S7 modules.

The CP521 closest equivalent is a CP340 or a CP341, the CP521 Basic was programmed in BASIC and the program stored on an EPROM in the card as I recall it.

I have written a protocol compiler/decompiler for serial communications with the InTouch S5 driver earlier, before the CP341 was released with the RK512 procedure on board. I did the programming in SCL, it was a breeze and worked well enough except for a bug which I discovered in dealing with continuation telegrams which as a fault of the InTouch driver.

> I believe you are reacting to a caution
(not a criticism) I stated about
> being careful to use DBs that are within range
of the CPU model. It is
> possible to enter a data block into Step-7 that
is outside the valid data
> block address range for that CPU. The CPU will
refuse to accept it when you
> try to download it though.
> I've done this so I know it can happen.
It was a bit disconcerting though,
> as I had made a mistake in reading the
addressing specifications for that
> CPU, and then a further mistake in assuming that
if the programming software
> accepted a data block address it must be valid.
Some time was lost re-writing
> the program to work within only half the range
of data blocks I thought I
> could use, but fortunately I wasn't on a
critical schedule.
> The questions you had about how the CPU
would behave with an invalid DB
> number loaded into it didn't arise, since it
refused to accept it and I could
> only load data blocks into the CPU which were
within the valid range.

And this is why I don't use the manuals for light reading, it obviously didn't help you either.

Anyway to conclude, and I mean this is MY conclusion on this thread, I am sure this rattling of sabres and exchange of ideas between myself and Mr Griffin has illustrated a great deal of the differences between S5 and S7, the thread's originator must have a reasonable understanding of the picture by now, I am surprised to find myself typing these epistles, it is out of character, when I first read the thread I was dis-inclined to respond as the applicant didn't have any specific questions, and so in my opinion hadn't made much effort to do his homework and was maybe taking the easy route, which I am sure happens quite often in this forum. But for what it is worth, there is not any reason in my mind why I would ever want to work on an S5 again, obviously I will, but I will never have a preference for S5 over S7, and this was my first love in PLC's up until just a short while ago. A search of the archives will show records of my previous comments to this effect.

Regards
Donald Pittendrigh
 
B
> I have never read any PLC manual from cover to cover for the sake of
> reading material, for this I would prefer Harry Potter, I have to find the
> information I want when I need it, quickly, it must be accurate, it must
> not read like English and sound like German or Vice Versa, Siemens has
> produced an admirable set of reference tools for the S7 300 and 400, the
> most impressive move was to put them in PDF form and make them available
> on the Web for free, 10 points out of 10 to Siemens I wonder what if any
> other manufacturers do this.


AFAIK, all of the PLC venders have websites were you can download their manuals in electronic format.

I'd like to add a little bit to this discussion. I have not used either S5 or S7. The people I know who have extensive S5 experience just hate it, but generally like the S7. One guy wrote most of an S7 program using Excel and some custom excel macros he wrote. He then just pasted it into the S7 programming environment. Not something I would attempt with AB.

The key seems to be to get past the German arrogance and appreciate the S7 for what it can do for you. I'd be willing to bet if they made it just a hair more user freiendly they would do much better in the market place.

Bob Peterson
 
Top