Changes in AR2 can destroy local variable accesses in FB's of your project

Hi,

I was working on a peace of code in which I need to copy big amount of data from a static area of an FB into a shared DB. I used Register-indirect area crossing addressing. Now I needed to use this for both for Load and Transfer. That made me use AR1 for the source and AR2 for the Destination.

The code works perfectly fine in the test project, anyways it gives me a rather annoying warning.

"Changes in AR2 can destroy local variable accesses in FB's of your project. "

The FB works perfectly fine in its own. The question is that is there a risk that this warning causing issues with other FB's?

If yes, is there practical way of dealing with this?

MicroMan

Hi,

I was working on a peace of code in which I need to copy big amount of data from a static area of an FB into a shared DB. I used Register-indirect area crossing addressing. Now I needed to use this for both for Load and Transfer. That made me use AR1 for the source and AR2 for the Destination.

The code works perfectly fine in the test project, anyways it gives me a rather annoying warning.

"Changes in AR2 can destroy local variable accesses in FB's of your project. "

The FB works perfectly fine in its own. The question is that is there a risk that this warning causing issues with other FB's?

If yes, is there practical way of dealing with this?

 Hello,

read this if I understood well:

The use of AR2 inside a function block (FB) - S7 tools

you can try to do:

TEMP Variable : #AR2SAVE  -  DWORD

Before your job: TAR2  #AR2SAVE

After you job: LAR2  #AR2SAVE

Hi,

I decided to set up an ANY pointer and used SFC20 move the data. So there is no warning at all.

Anyways I keep in mind your suggestion, I may need to use it an other time.

Cheers!

MicroMan

<snip>

The FB works perfectly fine in its own. The question is that is there a risk that this warning causing issues with other FB's?

</snip>

As long as the FBs are not instantiated in the FB in question, there's no risk at all.

Playing with AR2 can only mess up with the current FB. Once its execution is finished the CPU registers are popped from the stack and the changes to the AR2 are gone.