Usage of VAR RETAIN PERSISTENT

Question

I'm using WAGO PLC PFC200 in my home automation project. I've plenty of POUs, each for one room. Each room implements IRoom interface and uses base POU for common logic like turning off all lights. For lights management, I'm using

• FbEvaluateShortLongPress from WagoAppBuilding to handle short and long press of buttons on the wall (it could also be a function block from OSCAT library)
• FbLatchingRelay from WagoAppBuilding as a toggle for PLC digital output

I want to save the state of FbLatchingRelay in case of e.g.: power drop. I want all lights which were turned off before power drop to be turned on when the power comes back.

I've solved it by declaring a FbLatchingRelay in the VAR RETAIN PERSISTENT area in my POU. But then after reading here that:

If you declare a local variable in a function block as RETAIN, CODESYS stores the complete instance of this function block in the Retain range (all data of the function block); however, only the declared RETAIN variable is treated as such.

I decided to change that in order not to waste RETAIN memory for a bunch of variables which are in POU but are not needed to be stored as RETAIN.

So right now I have something like that:

• the VAR RETAIN PERSISTENT area is only declared in my main program
• it stores structures for each room (each POU) only with needed data - FbLatchingRelay POU and few other variables
• while initializing the room (POU) I'm passing those structures to my rooms using VAR_IN_OUT
• each room (POU) uses then this data

PLC_PRG:

VAR RETAIN PERSISTENT
    BathroomPersistentData: BathroomData;
END_VAR

Bathroom(PersistData := BathroomPersistentData, xMainLightSwitch := DI1_13, xMirrorLightSwitch := DI2_3, xMirrorLightSwitchActuator => DO2_1, xMainLightSwitchActuator => DO1_11);

Bathroom POU:

VAR_IN_OUT
    PersistData: BathroomData;
END_VAR

Is this a good approach? What do you think? It complicates project a bit but I'm not wasting RETAIN memory for things which should not be there (whole POUs).

Answer 1

Yes, this is how my organization handles retain vars. This also lends itself to supporting “save to disk” solutions for other FB demands (not so much for your light states).

On the other hand, did you run out of memory by the original way? Sometimes I find we worry about things that never happen. Yes it is “wasteful” for the whole FB instance to be put in retain memory, but if your FBs are small and your device has plenty of retain memory - then nothing to worry about until later.