Memory Addressing in a Siemens S-300 CPU (315-2DP)

Hello.

I'm new here and new the Siemens CPUs. The CPU has no documentation and I'm a little lost on the Siemens website.

I understand how their I/O addressing works but I'm not sure how the internal memory addresses work in terms of available addresses for my work bits and data blocks.

I'm looking at the symbol table from a pre-existing program and they're using memory addresses all the way up to 200. Some are bit addresses, some are words, and some are double precision.

How do I know how many memory words are available?
Are they just sequential from 0 to the highest address?

Thanks in advance for the help.

I'm not an expert either, but I've put in a few of these & I'll try to answer your question... the number of bit memories available is dependant upon your CPU... 1028 for CPU 312, and 2048 for any other S7-300 CPU or up to 16383 for the S7-400 CPUs - check their ST-70 catalog for additional info. This limitation applies only to the 'M' bit memory & not data.

Siemens has a few different layers of memory available to use, so it can be complicated at times laying out your format...

1. Memory bits are a free-form type of memory which can be set to retentive with CPU configuration, and allow for quick access time use within the program. Addressed as M0.0.

2. Data blocks which you format to your requirements - bits, words, integers, reals - any of these can be combined in datablocks. If you do not name the data block, then you will only see the bit address in the program (not the symbol). Within the program you would address a data-bit as DB10.DBX0.0 - DB10(or Db of your choice).DBX(X denotes bit)0.0. The help file should help you address the rest correctly. Data is always retentive.

3. Local memory is defined within the block itself, and only exists for the single-cycle execution of the block - I use this for temporary values in complex calculations since Siemens has yet to come up with a 'Compute' block like A-B These values are set in the pull-down menu at the top of the page & in the program are preceeded with a #.

D-oh! I guess it would help if I had logged in before I posted my reply lol


Hopefully that may answer your question.

I'm at home at the moment and therefore don't have any documentation available. However, in the documentaion for your CPU you'll find how much memory is available for Merker (M-memory) at a guess for a 315, it's probably either 2048 Bytes or 4096 Bytes. The addresses are sequential.

It would be helpful if you could give a bit more information about what you want to do. Do you need to modify an existing program, or do you need to create a new program for which the 315 CPU is a requirement?

The S7 system is actually laid out to support object oriented programming to a high degree. For this reason, you don't really need to (or want to) use M-erker memory very much. You can use Global Datablocks to hold general information (which protects you from addressing Bits, Bytes and Words (or DWORDs) inadvertently from multiple sources (without this being immediately evident). By creating FBs with their associated DBs, you can create standard program modules which you can use many times with multiple "instance" DBs.

The whole business is neither easy nor intuitive, but it is powerful. If you give a bit more information, you'll receive more than enough help here to solve your problems!

Hello Beggar;

If you open the Hardware config editor online, and then look at the CPU properties, you will find a tab giving you all the memory information for your particular CPU.It will give you your I/O range, number of M bytes, number of FB/FCs you can program, and available SFCs for this processor.
Hope this helps,
Daniel Chartier

Also worthy of mention is the static data area (as opposed to temporary data) available within function blocks (not available in functions). Static data is stored in a data block and is hence retentive and valid after every scan. Static data can be very useful for storing edge detection bits instead of using marker bits. Static data is not suitable for global data though.

Static data is not suitable for global data though.

Click to expand...

Why? What's to prevent access to an instance data block from any OB, FC or FB in a program?

Regards

Ken.

Beggar

You say the CPU has no documentation. Oh well, let's fix that problem. Even Siemens has a thing called a web-site where you can get several GB of manuals/catalogues/guides/specifications etc. Try this link - it didn't take long to find this spec sheet for the 300-series CPUs

http://www.sea.siemens.com/autogen/docs/plc/s73/dl/S7-300_CPU_specs.pdf

or the equivalent for the 400-series (you didn't mention which you have) -

http://www.sea.siemens.com/autogen/docs/plc/s74/dl/S7-400_CPU_specs.pdf

Pick which ever you need - you see, beggars can be choosers.

Try starting at their home page (sea.siemens.com) and a little judicious navigation from there should lead you to all sorts of other documentation.

Regards

Ken.

Quote:
Static data is not suitable for global data though.


Why? What's to prevent access to an instance data block from any OB, FC or FB in a program?

Click to expand...

I seem to remember somebody commenting recently that you shouldn't do this, but my query as to why not didn't produce any reaction.

I'm doing this, apparently successfully, but if there is any mysterious circumstance under which it could give problems, I'd sure like to know about it!

RMA

As a programming philosophically one could decide that the STATIC variables in an instance DB should only 'belong' to the FB of which that is an instance. No other function should be allowed to alter them.

However there is no reason why this philosophy absolutely has to be followed. I've regularly used TON timers in a multi-instance FB, and adjusted their preset values by writing to the mult-instance data block from other FCs. The multi-instance FB just does the job of running the timers based on the values it finds as STATIC variables in its DB.

As ever, the biggest source of potential problems in these situations is the programmer not the PLC!

Regards

Ken.

As ever, the biggest source of potential problems in these situations is the programmer not the PLC!

Click to expand...

Wich is particularly true where I'm concerned.

I agree with Ken on the static data issue. I build my entire programming philosophy around being able to access the static data globally. When you sit down and think about it, there isn't any reason that these variables can't be treated like evrything else.

The absolute location of a variable in an instance data block depends on the interfaces and static data declarations of the function block(s). If you access the absolute location of the variable outside the function block, you will have to remember to update the location reference manually or recompile the source code you have saved if the function block interface changes.

Simon,

Same goes for accessing the static declarations in a data block from within its own FB - if you use absolute addressing.
But no sensible programmer does that, right?

Ken