How a DINT can be converted to a POINTER

Hello,

I know that a DINT can be converted to a POINTER by shifting the double word left by 3 bits. but I don't understand how it works?

for example I will load mw10 in mw20:

L 20

SLD 3  ==> after shift left 3 bit of 20 the result will be 80!!

TAR1

L MW10

T MW [AR1 , P#0.0]    

I appreciate your help.

BR               

Med_selmi

Hello,

I know that a DINT can be converted to a POINTER by shifting the double word left by 3 bits. but I don't understand how it works?

The address format in S7 is as follows (let's put aside the area part):

p#byte.bit (e.g. p#20.1) , but this is only mnemonics.

The same in binary looks like this (and what you can see in ACCU1 after e.g. L p#20.1):

2#0000 0000 0000 0nnn nnnn nnnn nnnn nbbb, where n...n is binary coded byte and bbb is binary coded bit.

So when you load to ACCU a desired byte number and you want to get a proper address to the byte you must shift it left by 3 places. Which, completely accidentally , is equivalent to multiply by 8.

BTW:

Med_selmi

L 20

SLD 3  ==> after shift left 3 bit of 20 the result will be 80!! <- rather 160

TAR1 <- here, rather LAR1

L MW10

T MW [AR1 , P#0.0]

Towome

Hi,

do something like this:

L Adress1// INT i.EG 10 for MW 10

ITD

SLD 3

T #Pointer1 // DWORD

L MW [#Pointer1]

Regards,

Towome

 Thank you for your reply, my question was about demonstration of the result of shifting left how it will be pointer.

I want to understand why we have to SLD 3 to get pointer with initial address, even when I use word and SLW 3 then transfer to register.

I attached your example and as you see the result after shifting was 80, because if we use binary representation of 10 and shift left 3 bits, its normal to get this 80, but how we get 10 in indirect?

jacek d

 

Med_selmi

Hello,

I know that a DINT can be converted to a POINTER by shifting the double word left by 3 bits. but I don't understand how it works?

The address format in S7 is as follows (let's put aside the area part):

p#byte.bit (e.g. p#20.1) , but this is only mnemonics.

The same in binary looks like this (and what you can see in ACCU1 after e.g. L p#20.1):

2#0000 0000 0000 0nnn nnnn nnnn nnnn nbbb, where n...n is binary coded byte and bbb is binary coded bit.

So when you load to ACCU a desired byte number and you want to get a proper address to the byte you must shift it left by 3 places. Which, completely accidentally , is equivalent to multiply by 8.

 

BTW:

Med_selmi

L 20

SLD 3  ==> after shift left 3 bit of 20 the result will be 80!! <- rather 160

TAR1 <- here, rather LAR1

L MW10

T MW [AR1 , P#0.0]

 thank you very much that's what I want to understand, but if you more explain by replacing p#20.0 by integer then show me how binary representation works. 

Med_selmi

 thank you very much that's what I want to understand, but if you more explain by replacing p#20.0 by integer then show me how binary representation works. 

Is this clear to you ? 

jacek d

 

Med_selmi

 thank you very much that's what I want to understand, but if you more explain by replacing p#20.0 by integer then show me how binary representation works. 

Is this clear to you ? 

 This is very basic, I think you don't understand me. 

For example:

L 5        ==> 0000 0000 0000 0101

SLW 3  ==> 0000 0000 0001 0100 ==> equal to 40

LAR1 ==> normally the content of AR1 is 40

So why the result of L MW [ AR1, p#0.0] is MW 5 and not MW40 ?

Med_selmi

 This is very basic, I think you don't understand me. 

For example:

L 5        ==> 0000 0000 0000 0101

SLW 3  ==> 0000 0000 0001 0100 ==> equal to 40

LAR1 ==> normally the content of AR1 is 40

So why the result of L MW [ AR1, p#0.0] is MW 5 and not MW40 ?

Because the content of address registers in S7 is interpreted as below:

2#0000 0000 0000 0nnn nnnn nnnn nnnn nbbb 

nnnn nnnn nnnn nnnn - 16 bits for coding the byte number (offset)

bbb - 3 bits for coding the bit position.

So, to get byte number you should remove the last three bits, and this what remains interpret as natural binary code.

thank you very much, it's clear now after reading your posts and this topic.

So we load the content of ACCU 1 to AR1 as address (<byte>.<bit>) not as value.

BR