what can u tell me about screenshot ? is it compiler fault or has ar2 got some functions which i dont know :)

Hi,

Looks if you're trying to read data outside your stat memory or a DB.

What happens if you use LAR2 P#0.0?

What heppens if you add another STAT variable?

Hi,

No, it's the "P#2.0" that causes the shift.

Hi,

It's not advisable to use AR2 inside a FB since the PLC uses it behind the scenes to access the instance variables. If you change AR2 value from 0.0 to 2.0 you create an offset resulting in variable 1becomes variable 2 etc... accessing the last variable will create a pointerto an undefined area causing an access error.

if you read variable 1the plc actually does something like

L LW[AR2,P#0.0] // == translating to L LW0+0.0 = LW 0

AR2 is set to point to P#0.0 (start of structure) at the beginning of the FB,
so reading Variable 2 is done like

L LW[AR2,P#2.0] // == translating to L LW0+2.0= LW2

if you change AR2 -> P#2.0 this results in:

L LW[AR2,P#2.0] // == translating to L LW2+2.0= LW4 == variable_3



Of course you can save AR2 before use and restore AR2 after use but i wouldn't do that ...it makes it easy to make a mistake later on and create complex errors.

Use only AR1 or create an extra pointer on the local TEMP-stack if you require more then one
pointer at the same time. Example: Define a tempvariable "PTR" as DWORD

L P#2.0// set pointer to address 2.0
T #PTR

L MW [#PTR] // readout MW[x] in this example MW2

May be this helps you / explains things.

René