pointer question

darren.s

Member
Join Date
Apr 2005
Posts
46
Hello people !

Im trying to understand pointers and indirect addressing.
when i look at some posts on this site and some info in the berger book. there seems to be different ways of inserting code to get the same result.
ie i am right in saying that the statement

LAR1 P#DBX20.0

Is the same as saying

L P#DBX20.0
LAR1
 
Yes, it's the same thing. There are cases where you can include it in one line, and cases where you can't, so that's why you will see it both ways.
 
so taking the second statement
L P#DBX20.0
LAR1
i know its easy for you guys i just want to understand it properly.
am i right in saying
that the pointer is loaded into AKKU 1 and then transfered to AR1
 
I believe the restriction on LAR1 p#??? applies to parameters of a function call. Here you must use L p#??? then LAR1.

It is also worth mentioning (as it is in Berger) that AR1 is used to reference elements of complex data types passed as parameters. e.g. If Motor is an input parameter of type UDT, then beware of the following:

L Motor.Act //This will change AR1 !
 
That doesn't ring a bell Simon. I can't see how that instruction is changing AR1 simply by loading a value into the accumulator. Can you describe the conditions?
 
Here is an example (in FC1) that shows AR1 first being loaded with zero, then L Motor.Speed is executed and hey presto, AR1 is no longer zero. (Compile the code and then call FC2, monitor FC1 to see what happens)


FUNCTION FC 2 : VOID
TITLE =
VERSION : 0.1

VAR_TEMP
Pump : UDT 1;
END_VAR
BEGIN
NETWORK
TITLE =call fc1

CALL FC 1 (
Motor := #Pump);
NOP 0;
END_FUNCTION


FUNCTION FC 1 : VOID
TITLE =
VERSION : 0.1


VAR_INPUT
Motor : UDT 1;
END_VAR
BEGIN
NETWORK
TITLE =AR1 changing example

LAR1 P#0.0; //AR1=0
L #Motor.Speed; //AR1=870000A0 !
END_FUNCTION


TYPE UDT 1
VERSION : 0.1


STRUCT
Speed : INT ;
END_STRUCT ;
END_TYPE
 
Ahh yes, now I see what you mean. The same thing applies to AR2 when using FBs. In fact, an FC is the same thing as an FB when passing in a UDT. Or, another way to look at it is that the STAT variable in an FB is nothing but a complex variable. Remember that project I posted where I called the FBs unconditionally without parameters? Well, you can do the same thing while using parameters, except that you have to be careful about AR2. I have a sample project that decribes this, and maybe I can dig it out at lunchtime.
 
OK Simon, you have my curiosity up. After compliling everything and I call FC1 from OB1, what value or tag do I put on the MOTOR handle of FC1? I created DB100 with the UDT1 and called it TEST.
 
Maybe Simon isn't around because of the time difference, but maybe I can help.

You don't need a DB at all. Just create UDT1 with a single variable Speed of type INT. In FC2, just make a TEMP Variable called #Pump of data type UDT1. Then create FC1, with input variable called #Motor of type UDT 1.

When you call FC1, just enter #Pump, and it will point to UDT1 via the local variable. When you monitor FC1, you will see that S7 "remembers" where the UDT is coming from via AR1. If it didn't do this, it would have no way of using complex variables as parameters. Also, to see the real effect, insert a few variables before the #Pump variable in the local data so that the local offset is not 0. Make sense?
 
I thought I'd already posted this but it seems to have got lost en route! Maybe I hit the wrong button!

Don't worry Darren, pointers/indirect addressing aren't something you learn overnight (not in the Siemens world, anyway!). I've been successfully using it for getting on for a year now and it's still not second nature.

I didn't understand Simon's example on paper either and had to try it out to see what happened. I now know what happens, but I still can't really say that I understand it! Still, as long as I know what to watch out for, understanding can come later!
 
Cheers RMA
To be honest i thought i was making some head way and coming to terms with it. then i read the code simon posted and thought yep!
Better get the Berger book back out!
still as long as this site keeps going ill keep learning.

CHEERS GUYS............
 
Just to add some more info to the pot, referencing a variable like Motor.Speed as a parameter in an FC can have massive implications on your scan time and program space. If you remove the AR1 instruction from the FC1 example shown above, the block occupies 50 bytes of MC7 code. If you generate an FB with exactly the same instructions in it, the resultant block will only occupy 6 bytes (and by implication the FB must execute in less time).

The L Motor.Speed instruction in the FC has to examine the pointer to the structure, work out which area it is in, open the relevant DB if applicable, load AR1 with the offset to the structure element and then finally load the variable.

L Motor.Speed in an FB just needs to access the variable from its instance data.
 

Similar Topics

Hello Folks! I'm still trying to get the hang of using STL and Pointers in Step 7 (V5.5). For background, I'm writing a sample application...
Replies
7
Views
3,265
Can you help me with "generating" pointers? I have INT variable and I want to create pointer based on variable's value. For example var=30 =>...
Replies
2
Views
1,684
Hi, i've came across this code: AN #STATUS.R_REQ AN #STATUS.R_BUSY S #STATUS.R_REQ CALL "RDSYSST" REQ...
Replies
9
Views
2,246
I need a bit of help with pointers in S7. I am a AB and Omron person who has done some simple S7 programming before (but I have avoided STL...
Replies
16
Views
12,493
Have a little question how to do this: I want to do a ANY pointer wich gets a DBnr (INT) and number of bytes to send and number of bytes to send...
Replies
6
Views
2,043
Back
Top Bottom