S7 TIA Portal: How can I find out the memory address of a tag?...

[Mas01]

Hi,

Have a look at this picture...

How can I find out the memory address of this tag?

It was created by adding it to DB "Data_block_1", but I would like to know the memory address that's been assigned to it.

It there a way to find this out?

Thanks

 

[Mas01]

p.s. "Laser1 mm" is not a retained tag.

 

[mk42]

1) Why do you want the memory address?


2) If you're using optimized DBs (the default), then there is no memory address you can see. The compiler takes care of it all sneaky in the background, but it's faster in runtime and takes up less space (hence "optimized").


You can change the DB to be non-optimized (uncheck the box in the DB properties), which means that every tag in the DB gets an assigned address offset, of the form DB1.DW6, or whatever. I don't think you can read that address in runtime in the PLC, but if it exists it will hover over top of the tag name like it does for M/I/Q bits.



ps I'm pretty sure retain status doesn't matter.

 

[Mas01]

1) Why do you want the memory address?
I'm asking for a colleague working on another project. He asked me this questions, but I didn't know the answer.

2) If you're using optimized DBs (the default), then there is no memory address you can see. The compiler takes care of it all sneaky in the background, but it's faster in runtime and takes up less space (hence "optimized").
Yes, I'm using the default DB settings, so it is optimised.


You can change the DB to be non-optimized (uncheck the box in the DB properties), which means that every tag in the DB gets an assigned address offset, of the form DB1.DW6, or whatever. I don't think you can read that address in runtime in the PLC, but if it exists it will hover over top of the tag name like it does for M/I/Q bits.



ps I'm pretty sure retain status doesn't matter.
Okay - I thought maybe the retained tags might have an allocated memory address carried over from one power-up to the next.

Thanks for the reply.
Some comments/replies embedded in the quote.

 

[L D[AR2P#0.0]]

In my experience the optimised less space/executes quicker doesn't happen - for example a bool in an optimised DB uses up a byte of space. An array of 1000 bools takes up 1000 bytes whereas in a non optimised DB the array takes up the space of circa 1000/8 bytes (+ some overhead for the block header).
Execution time tests with a real plc show practically no difference. Where the optimised scores is if you need a very large DB as the largest DB for non-optimised is 64kB.

 

[mk42]

In my experience the optimised less space/executes quicker doesn't happen - for example a bool in an optimised DB uses up a byte of space. An array of 1000 bools takes up 1000 bytes whereas in a non optimised DB the array takes up the space of circa 1000/8 bytes (+ some overhead for the block header).

Supposedly, this is a difference between 1500 and 1200. My understanding is that the 1200 compiler automatically rearranges things to pack the data into the smallest space possible, whereas the 1500 uses 1 byte per bool to optimize for speed instead.


In practice, I think there's more going on for both than the simplified picture in the manual. In 1200, it looks like the DB size grows in 8B chunks, at a minimum. Assuming it's related to the new LINT/LREAL data sizes.

Execution time tests with a real plc show practically no difference. Where the optimised scores is if you need a very large DB as the largest DB for non-optimised is 64kB.

Very true about the size.


What I've heard is that the speed ends up not really being a noticible in elementary data types, but it becomes bigger for UDTs/arrays.


Haven't ever had a chance to sit down and test it myself.

 

[parky]

The change from absolute addressing i.e. DB10.DBW20 to symbolic addressing was introduced to try & make code transportable between platforms, however, I'm sure many know this is not true i.e. I/O has many different forms in different platforms & certain functions & special cards really makes this difficult anyway, some like RA have bit the bullet & gone to symbolic addressing it's just memory like the older PLC's, the compiler allocates memory instead in reality it's just a way of making things easier.
Many other platforms have kept the existing memory allocation i.e. things like DB's M bits etc. this makes it a little bit easier for backward compatibility, siemens probably just create DB's in the higher area that are not accessable in normal address space. Mitsubishi have done the same thing, the compiler has a range of variables that also exist in the older platforms but reserves them for allocation during compile time, this means they do not change until re-compiled. for example D registers can be used as global (have a fixed address) if allocated an absolute address like D100, (User selectable for example D0-D7999) local or globals without allocated addresses will be allocated at compile time these reside in the D9000> region not normally used in normal programming.
In general even local variables are not destructive as the compiler will allocate memory not used until that memory is in short supply then it will re-use memory locations more than once but as modern processors have plenty it is unlikely that this will occur. In most of these "compatible" IDE's this means that an HMI or coms system cannot read/write these symbolic only areas so have to be globals with physical memory addresses, RA is different I can only assume that the symbolic table must be downloaded to the PLC for HMI's etc. to get the physical address, I believe that other platforms are moving this way I think Mitsubishi are or have now a feature where the symbolic addresses are downloaded so it will poing to the correct physical address but that probably will only apply to the latest offerings of the platforms. Siemens S5 was a little different than most other platforms, the PB's, FB's & DB's when written to the PLC memory a sort of Fat (File allocation Table) was populated with the physical address space for the blocks, so when a block was written to the PLC the old block was not ovewritten or deleted, the block was put in spare memory & in the PLC tidying up routine the "FAT" table was updated with the new pointer to that block just like hard disks are done. in the older S5 after a time the memory would fill up & you had to do a compress to clear out the redundant blocks, later versions did this automatically on a download of a block.