Latching by temporary varibale inside FB or FC- recomended?

Hello PowerTags

by now I think we all agree that values in TEMP variables must be (should be) considered "lost" once the execution of the FC or FB is done and the inbuilt Step 7 help on for local data confirms this by stating:

When using temporary variables, remember that they are only valid within the relevant block or are only available as previous local data for other blocks called in this block.
In particular, there is no guarantee that if you close and then re-open the block, the temporary variables will have the same values they had when the previous block call was completed. Temporary variables are by definition undetermined when a block is called and must be re-initialized again when they are used for the first time in the block.

Ican also garantee you that there is no difference in the handling of TEMP variables between FC's and FB's.

You will however have situations in which TEMP variables do retain their valuefrom one scan to another which is what you observe.
To understand why this possible, you need to appreciate that the CPU has a so called Local data stack (eachpriority class has its own Local data stack).
This is a fixed memoryarea in the RAM (size depends on CPU) in which the OS allocates the TEMP variableswhen a block is called.
When the block call is finished, the allocated memory area (which contains the values of the TEMP variables of the just finished Block) is released andmade available for usage by other Block calls (which will now put their own TEMP values into this memory area and as such "destroy" any "residue"values in them).
IfBlock calls are nested (e.g. like your FC70 calls FC71 which then calls FC 72 etc.) the TEMP variables of the calling Block are protected (as it hasn't finished its execution yet) and the nested Block(e.g. FC71) simply appends its local datato it.

An FC (or FB) may as such retainthe values of itsTEMP variables if it is the "most deeply nested" call (i.e. allocates thehighest local data in the path)or if other FC/FB calls do NOT write into their TEMP variables etc.

If the above all sounds confusing and/or ambiguous and/or non-deterministic then that is probably a good indication that you simply can NOT count on TEMP variables to retain their value (your friend simply got lucky when it worked inhis case).

Last but not least, you can find outhow much local data is allocated in the call up pathwhen you display the call structure in the Cross reference.
Attached is pic which shows the allocation for your example project (and hopefully helps in making sense of what I tried to describe above).

Ihope this helps