Step7 - Use M or DB?

Hello everyone,

I have a question regarding Step 7. I am converting an Allen Bradley SLC 5/04 program to the Siemens S7-300 platform.

I know that the Siemens PLC provides "memory areas": I, Q, M, D, T, C. SLC 5/04 PLCs provide "data files": N10, B11, C16, etc.

My question is:
For temporary bits and/or words that are sometimes needed inside the program, should I use memory area M or should I create DB for that purpose? What use are M's for? Somewhere I saw that some M's are used by the CPU itself. Is it safe to use M's extensively in the program?
I believe that DBs are retentive whereas Ms are volatile. Is this correct?

Bobby1234

Some M flags are retentative, the amount is configurable. If you open the hardware profile of your project and then open the CPU properties, there is a tab for retentative memory. There you can specify the amount of M flags, timers and counters to be retentative.

Data Blocks have historically (from S5 days) been used for data storage and flags for internal memory, although with S7 this is now becoming blurry.

Blocks now have TEMP declarations where you can identify 'scratch' memory. Traditionally in S5 you would use flags 200 and above and these could not be given unique identifiers for each use. The TEMP overcomes this and allows identification of 'scratch' area data.

FB's additionally have STAT declarations, this area stored in instance DB's and therefore become data for a particular block call that can be saved and restored the next scan, which is why they call FB's, blocks with memory.

You can access this data anywhere by opening the instance DB.

Flags are used for memory that is available in all block calls. without having to open DB's.

Data Blocks (not instance) would be similar to the old S5 use, for data storage (presets etc).

Of course you do what you want when programming.

small diference

Hi,

As stated by PeterW the diference between flags and DB are blurred in S7. But there is a penalty in using a bit from a DB (using S7-300).
Operation U with E/A 0.1us
Operation U with M 0.2us
Operation U with L (TEMP) 0.3us
Operation U with DBX 1.4us
Operation U with DIX (instance DB) 1.4us

Regards,

Kelkoon

Another important fact to note concerning the use of fully addressed DB bits (DB100.DBX0.0 for example) is that the global DB register will now reference DB100

Example (a random one):

OPN DB1
A DBX0.0
A DBX0.1
= M100.0 //save in temp
A M100.0
A dbx0.2
= Q0.0
A M100.0
O dbx0.3
= Q0.1

if you replaced M100.0 with say DB100.dbx0.0 then the above code would not perform the same logic as once DB100.dbx0.0 has been referenced the currently open global DB would switch to DB100 as opposed to DB1 as expected.

SimonGoldsworthy said:

Another important fact to note concerning the use of fully addressed DB bits (DB100.DBX0.0 for example) is that the global DB register will now reference DB100

Example (a random one):

OPN DB1
A DBX0.0
A DBX0.1
= M100.0 //save in temp
A M100.0
A dbx0.2
= Q0.0
A M100.0
O dbx0.3
= Q0.1

if you replaced M100.0 with say DB100.dbx0.0 then the above code would not perform the same logic as once DB100.dbx0.0 has been referenced the currently open global DB would switch to DB100 as opposed to DB1 as expected.

Click to expand...

I had a barney with my previous employers about this sort of thing.

They refused to set up and use any UDT's as they didn't know what they were for, so after I restructured a couple of DB's using UDT's to make it easier to scroll to the area I wanted to see. They initially bollocked me for changing their precious code, then seeing what I had done, realised how useful UDT's could be.

So they went UDT mad and generated loads of DB's using UDT's and replaced flags everywhere with DB's, I went spare when I saw the code coming through.

I couldn't get through to them that they were adding instructions and scantime to the program. I believe something like twice tyhe amount of words and 4 times the scan per instruction.

Each instruction, such as 'A DB2.DBX4.3' starts by opening the DB. Even if the DB was already open it would still take up time, and was constantly changing the open DB, sometimes 5 or 6 times on one network.

Then they thought that the DB opened at the beginning of the block was still active (DOH).

DB retentive? step7 siemens

bobby1234 said:

Hello everyone,

I believe that DBs are retentive whereas Ms are volatile. Is this correct?

Bobby1234

Click to expand...

I'll put my question here as it is similar.

Are DBs retentive?

If so, how , if not , how do I get around this?

I need setup data to be entered for a number of different possibilities. Each possibility will be selected from the operator.

I made a table of possibilities in a DB and thn use move block SFC20 to moe the correct block into the program.

Today for some reason all this data dissapeared. I have been using it this way for a couple weeks with no issues and the power goes off every day over night.

How can be sure this wont happen in the field?

I went to the hardware configuration and see that I can not select which DBs are retentive. Do I take from this that they all are? or they all are not?

Thanks,

Do you mean the DB with the original table was full of zero's, or the DB did not exist ?

L D[AR2 said:

Do you mean the DB with the original table was full of zero's, or the DB did not exist ?

Click to expand...

The initial values were still there but the data that I added for each item was all zeroes.



Also why do some DBs open in the DB parameter window and some open in the editor window?

Double click in the Simatic Manager or right click open object. DB99 opens in DB parameter window, DB 94 opens in the LAD/STL/FBD editor window.

And I can't edit the structure of DB99 anymore. Is this because it is used in the program or online?

Global DB's open in the editor window. You can change the structure of the these DB's as you wish in the editor. Instance DB's or DB's created to be of type UDT open in the DB param window. To change their structure you must change the interface of the FB's in the case of an instance DB, or change the structure of the UDT in the case of the latter.

The values in the DB look good to me - exactly how did you change the values, and which values are you referring to ?

DB values resetting

The data loss issue is common when using instance data blocks where the variable definitions are in the function block concerned. If the FB header is changed, any data block that uses these FB definitions will re-compile and be reset to zero. To avoid this, generate a source from the DB which saves the actual values. Then, if the DB contains zeros, compile the DB from the source and the modified values will return. (the source may have to be massaged if the variable names have changed)

bobby1234 said:

Hello everyone,

I have a question regarding Step 7. I am converting an Allen Bradley SLC 5/04 program to the Siemens S7-300 platform.

I know that the Siemens PLC provides "memory areas": I, Q, M, D, T, C. SLC 5/04 PLCs provide "data files": N10, B11, C16, etc.

My question is:
For temporary bits and/or words that are sometimes needed inside the program, should I use memory area M or should I create DB for that purpose? What use are M's for? Somewhere I saw that some M's are used by the CPU itself. Is it safe to use M's extensively in the program?
I believe that DBs are retentive whereas Ms are volatile. Is this correct?

Bobby1234

Click to expand...

There are also less M's then the amount of data that you can save in your DB-area's.

With MMC's (micro memory card) all your DB-data is automatic retentive.

dahnuguy said:

I'll put my question here as it is similar.

Are DBs retentive?

If so, how , if not , how do I get around this?


I went to the hardware configuration and see that I can not select which DBs are retentive. Do I take from this that they all are? or they all are not?

Thanks,

Click to expand...

You have a MMC and all your DB's are thus retentive. If you did not had a MMC you could define in the HW-configuration the DB-area's what you want te be retentive. The number of area's then depends on the used cpu.

ivo.maenen said:

You have a MMC and all your DB's are thus retentive. If you did not had a MMC you could define in the HW-configuration the DB-area's what you want te be retentive. The number of area's then depends on the used cpu.

Click to expand...

yes

I have an MMC.

yes

I read that the DBs were automaticaly retentive.

But I observe the data dissapering.

Retentive to me means always there.

Now I am doing heavy edits to several portions and generating new code daily, so I suspect that this is the reason I am losing data.

I like the idea of making the source code with the values in place. That will be nice if that works the way I hear it.

Thanks to All.

They are not always retentive because: after a MRES the DB-data will be again the last actual values that you sended from your pc to the cpu. Normally these actual values will be the same as the initial values, but they can be different.

If you use SFC20 then you will acces the DB-values that are in the load-memory of the cpu. This is usefull if you do not want your DB to be in the workmemory (in order to save cpu-memory). To do this (saving cpu-memory), your DB must be unlinked.

I read that the DBs were automaticaly retentive.

Click to expand...

This is usually the case, but not always. In some CPUs there is a memory limit for how many DBs may be retentive. This applies to the 317, for example and, I suspect, but don't know for sure, to the 319 as well.

If your problem with the disappearing data in the DBs is with process parameters which get changed occasionally by the operator, then there is a solution by creating an "unlinked" DB (on the second page of the DB parameters when you create it) which then only exists on the MMC card. When the operator modifies a parameter you then use SFC84 (from the System Function Blocks in the Standard library) to write the new data to the unlinked DB. In OB100 you then use SFC83 to read the data back before restarting the OB1 cyclic scan.

Obviously, this is no use if you're losing constantly changing plant values, since you can't continuously write to the MMC card.

Edit: Just occurred to me - if you pull the the MMC card and plug it back in, when you reboot you'll find you have the first actual value that was stored in the DB.



You'll find a good discussion about the peculiarities of DBs in this thread.