S7 Addressing - Silly question!

I know this is a silly question, but it's irritating me nonetheless.

We all automatically start WORD and DWORD addresses on an even address boundary, however, nowhere in the Help files, or other sources, can I find an explicit statement to this effect. Indeed, on the contrary, in a colleagues "Programming 1" course notes, which I've borrowed, I find the statement: "The memory of the S7 PLC is universally Byte-oriented" (loosely translated from the German!). They then go on to demonstrate the consequences of this with examples in which all the WORD and DWORD addresses are even!

Taken at face value, I would think that the statement at least implies, that you could define a WORD or DWORD on an odd address. The funny thing is, the Symbol Editor will allow you to create a WORD or DWORD on an odd address, without complaining. On the other hand in a DB, you are always forced to an even address.

Anybody know where we can find this Black on White?

Edit: I've been digging through "The Bible" (Berger!) to see if he could throw any light on the subject, but all I've been able to find so far, is an example where he takes a DWORD - MD24 and splits it into it's component part including MW25, comprising MB25 and MB26. Does this mean that apart from convention, there is no reason why a WORD or DWORD on an odd address boundary should not work. Or could it be that there could be problems passing parameters between FBs, FCs, SFBs, SFCs etc.?

Knowing the hardware

RMA, if you look at a hardware manual for 68000 or PowerPC you will see that these processors will readily access memory on even word boundaries.
The memory is set up to be accessed on even addresses.
Addressing data on odd boundaries requires that the data be swapped on the bus and also that two memory accesses are required. Intel processors can do this but it is very inefficient. Most DSPs can't handle access odd bytes. In fact the DSP I use at work TMS320C33 can ONLY access 32 bits at a time. In this case a byte, int and long are ALL 32 bits.
More on this later because I must go to work.

Does the S7 300 Series use one of these Processors? I know that the S7-300 and S7-400 CPUs have different Processors, but I've no idea which ones they use. In a Siemens FAQ referring to the differences in execution of the JMP instructions between the two machines Siemens explained that this had to do with the fact that the S7-300 used a compiler-machine and the S7-400 had an ASIC (whether they actually meant an Application Specific IC by that, or something else, I'm not sure).

You summed it up quite well, the editors will automatically increment the addresses to give you even byte numbers for WORD and DWORD data. From a program point of view however, you can access DB1.DBW1 or MW341 (for example) as a word if you really wanted to.

I strongly suggest sticking to the even address for words convention.

I believe the even address for words and doublewords comes about from the conversion from Step 5, where Step5 datawords DW are accessed as Step7 word DBW(2n).

Roy, in the S5 and S7 worlds it is faster to access a word on an even byte boundary versus an odd byte boundary. So, “L DBW 1” takes longer than “L DBW 2”, because it has to access DBW 0 and 2 to get to DBW 1.

For instance, these are the execution times for an S7-416:

L DBW 10 = 80ns
L DBD 10 = 160ns
L DBB 10 = 80ns

You can see that the processor “thinks” only in terms of 16 bits, as it takes twice as long to load a 32 bit variable, but takes the same time to load an 8 bit variable.

Now, let’s run a test to prove this. We’ll start with some benchmark code:

In OB1, I inserted this code:

Code:

[/font][/size][/font]
[font=Arial]	 OPN DB	10
	 L	 #OB1_PREV_CYCLE[/font]
[font=Arial]	 L	 L#50000
t1: T	 MD 400
	 L	 MD 400
	 LOOP t1
[/font][font=Arial][size=2][font=Arial]

You can see that I am performing a simple loop of 50,000 iterations. On my S7-416, the resulting scan time is 37ms.

Now, let’s put a simple load/transfer inside the loop:

Code:

[/font][/size][/font]
[font=Arial]	 OPN DB	10
	 L	 #OB1_PREV_CYCLE[/font]
[font=Arial]	 L	 L#50000
t1: T	 MD 400
	 L	 DBW	0
	 T	 DBW 10
	 L	 MD 400
	 LOOP t1
[/font][font=Arial][size=2][font=Arial]

The scan time is now 45ms, which is exactly what I would expect since the execution time of a 16 bit instruction in a 416 is 80ns, and we have in effect added 100,000 instructions to the scan.

Now, let’s change the words to odd-byte boundaries:

Code:

[/font][/size][/font]
[font=Arial]	 OPN DB	10
	 L	 #OB1_PREV_CYCLE[/font]
[font=Arial]	 L	 L#50000
t1: T	 MD 400
	 L	 DBW	1
	 T	 DBW 11
	 L	 MD 400
	 LOOP t1
[/font]
[font=Arial][size=2][font=Arial]

The scan time is now 53ms, an increase of another 8ms. So, this is in line with my above statement that when you access a word based on an odd byte, it needs to grab two words, not one. We should be able to prove that by changing the code for doubleword access:

Code:

[/font][/size][/font]
[font=Arial]	 OPN DB	10
	 L	 #OB1_PREV_CYCLE[/font]
[font=Arial]	 L	 L#50000
t1: T	 MD 400
	 L	 DBD	0
	 T	 DBD 10
	 L	 MD 400
	 LOOP t1
[/font]
[font=Arial][size=2][font=Arial]

The scan time remains at 53ms, as expected.

For one last test, let’s do a doubleword L/T on an odd byte boundary.

Code:

[/font][/size][/font]
[font=Arial]	 OPN DB	10
	 L	 #OB1_PREV_CYCLE[/font]
[font=Arial]	 L	 L#50000
t1: T	 MD 400
	 L	 DBD	1
	 T	 DBD 11
	 L	 MD 400
	 LOOP t1
[/font]
[font=Arial][size=2][font=Arial]

Now, the scan time is 61ms, an increase of another 8ms. So, in this case, the processor has to access six bytes for each doubleword, not four.

So, like a lot of things in the Siemens world, they give you the option of doing something even if it doesn’t really make sense, which is why you can enter DB10.DBW11 in the symbol table even though it is counterproductive when it comes to scan times. As for why DB variables are always aligned on an even byte (for non-byte variables), it is probably a function of the DB compiler, not some inherent limitation of the processor.

Thanks for the explanation S7Guy, that was interesting.

So the implication in Berger that odd addresses are legitimate and it's only convention (and speed) that keeps us using even addresses, is correct.

Obviously, I wouldn't dream of using odd WORD or DWORD addressing, apart from anything else, it could really confuse sombody who has to work with the program in future. I was just interested as to whether there were any situations (perhaps very obscure) where it would actually cause problems.

To S7Guy, How do you enter DB10.DBW11 in the symbol table ? I can only put I,Q,PIW,PQW,Timers, flags, counters, DB, FB,FC,OB,UDT.

There are reasons to access words add odd boudaries also:
For example, I have some BECKHOFF bus terminal modules connected to S7 via Profibus. Their register addresses are:

1Byte Status, 1Word value. Then follows the next module wit the same layout. So if I read a bunch of them in as a block with SFC14, I get every second value on an odd byte boundary.
There are two possibilities to circumvent this:
1. Configure the terminals for values only. But I need the status of some of them.
2. Configure the terminals/bus coupler to expand the status to a word. But this will expand Profibus telegram length by one third. So the impact to speed is less when the CPU accesses odd addresses.

The worst with it is that there seems to be no way to construct a UDT with odd word adresses. Step7 allways adds a fill byte after status, so I cannot use a UDT that reflects the structure of this external data.
There should be something like #pragme pack in C.

Simon, when I read Roy's statement, "The funny thing is, the Symbol Editor will allow you to create a WORD or DWORD on an odd address, without complaining. On the other hand in a DB, you are always forced to an even address", I just assumed that he found a way to enter DB10.DBW1 in the symbol table. Personally, I rarely use the symbol table anyway, so I wouldn't have known that you can't. The point still stands that even though Siemens will allow us to address DB10.DBW5 or MW13, it really doesn't make sense to do that, especially if scan time is an issue.

Zottel, that's an interesting problem you describe. I also find it annoying that you can't have a single byte in a UDT without a filler byte, and the closest I could come to doing this was creating an array of bytes (or CHARs), in which case I could then symbolically access odd byte addresses. But in your case, you only have one byte, so an array won't help.

That said, I question one point that you make:

2. Configure the terminals/bus coupler to expand the status to a word. But this will expand Profibus telegram length by one third. So the impact to speed is less when the CPU accesses odd addresses.

Click to expand...

Have you actually ran a test to verify that there is an impact on speed? I ran the tests above with byte values, and the code didn't run any faster, which makes sense because Siemens works wiith words when it accesses the memory map. If I were you, I would expand the status to a word and I'm willing to bet that it takes the same amount of time to get the data with the telegram.

S7Guy said:

Zottel, that's an interesting problem you describe. I also find it annoying that you can't have a single byte in a UDT without a filler byte, and the closest I could come to doing this was creating an array of bytes (or CHARs), in which case I could then symbolically access odd byte addresses. But in your case, you only have one byte, so an array won't help.

That said, I question one point that you make:


Have you actually ran a test to verify that there is an impact on speed? I ran the tests above with byte values, and the code didn't run any faster, which makes sense because Siemens works wiith words when it accesses the memory map. If I were you, I would expand the status to a word and I'm willing to bet that it takes the same amount of time to get the data with the telegram.

Click to expand...

I didn't test it. First, I was just convinced that transporting an extra byte over 1,5M Profibus must take longer than the 80ns extra time you measured for the misaligned access. Second, I wanted to "maintain space" with respect to max telegram length for future expansions. Last, I have the same thing when writing output data to these modules. And I did not research for what might happen to the BECKHOFF modules if the filler byte before status would become non-zero for some reason...

I have, however, an FC at the beginning of my program, where I copy all data from the peripherals to internal memory. The main purpose of it is: I have redundant sources for some values needed and I can switch to spare signals there.
As a side effect, my program can deal with aligned and symbolically addressable data everywhere after.
At the end, there is similar FC for the output data.

I have done test like S7Guy proposed

I did them on a 8086 20 years ago. I had a data base that was all word aligned. I then added on byte to the beginning of the data base to make the rest of the the data base aligned on odd addresses. This significantly slowed down readind and writing the data. The code fetching was not affected because of the way the prefetch queue worked. Notice I said the whole data by was now odd byte aligned. I don't think you will see a difference if you only change a few variables here and there.

Data structures should have their fields aligned word aligned. A byte would take up two bytes so the next word would still be even aligned. This caused many bugs when copying data structures because people often would not remember to count the extra byte used for padding. In Microsoft C all data structures are padded so the data fits on even address unless you use the key word packed. Note 32 bit processors should have their data dword aligned. So 32 bit data can be fetched in one bus access instead of two. This means a byte may need three bytes of padding to fill out the address map to the next 32 bit boundary.

This is NOT a silly question. It is good to know what really is happening under the hood.

I agree, it isn't silly at all. A lot of engineers have made poor programming choices in the past simply because they didn't understand how the processor worked.

By the way, there is a very useful pdf doc that describes the execution times of each instruction under various conditions. It is called 423op_e.pdf, and can probably be found on the Siemens site. It is probably the only Siemens doc I regularly refer to.

Heres a link to the PDF S7guy mentioned:

http://down.siemens.seoul.kr/indown.asp?path=ownftp\SIMATIC_MANUAL_collection-2003-05\Manual/423op_e.pdf

Steve.

Gee... Thanks, Stevo...

Now all I have to do is learn Korean!

Aside from the timing issue, which might or might not really be an issue at all, the general scheme is that you have access to any byte in accessible memory, odd or even.

You can specify any byte, odd or even, as the base and then indicate the "size" (number of bytes) you want...

• Byte = 1-byte
• Word = 2-bytes
• DoubleWord = 4-bytes

Memory is available (within memory-types) as a "Free-Range" grid to be used anyway you want without those damnable "ZONING LAWS"!

The general form for accessing a bit is... memory type (starting byte address) . (bit#)

The general form for accessing a Byte, Word or DWord is... memory type (size) (starting byte address)

The key to handling data in this kind of environment is "knowing" what you got and where it is.

If you happen to "map" a set of Inputs to a DoubleWord and then find that, for a particular case, you only need to examine the content of the second byte of the first or second word, then you might only need to call for the odd address associated with the second byte (unless the initial base address was odd... then you would call for an even address).

In terms of the capability provided by the S7, it doesn't matter whether or not you would want to access data based on odd addresses... the point is, you can (Thank You, TI!).

You can grab bits based on an odd byte-address or grab Bytes, Words or DoubleWords based on an odd byte-address. It's called "flexibility". Use it as you will, but, as in all things having to do with PLCs... use it carefully!


So... Pop-Quiz...

If VW100 = VB100 and VB101, what is VW101 composed of? What is VW201 composed of?