Freelance Variable Value Holding Problem
PM783 is used in my automation system. My variables return zero value after that my cabinet panel energy is lost. I have a battery 3V. So I expected my variable values were holded during energy lost. How to solve this holding variable value in memory.
Voted best answer
in order to keep the values, the controller needs to do a warm start after power is back.
The restart behavior is configurable in the resource header.
In principle the controller does a warmstart, which means the variables keep their values. The "max power fail time for warmstart" parameter allows controll over the restart behaviour.
No value means always warmstart, independant how log the power was off. "0" means no warmstart but coldstart instead. That means the variables use their configured initialize values. By default, if not configured otherwise, the initialize value would be 0.0 or FALSE. Any other value determins the max power off time for a warmstart behavior. That means if the power was off longer, the controller will do a coldstart instead of a warmstart.
So what value do you have configured there and how long was the power off?
There must be something wrong, otherwise the system would keep the values.
Please check the following:
1. Had you done the BootEprom download to the controller when you installed the system or after upgrading?
2. Is the system time in the controller set to current time?
3. Do you get a battery alarm in FO?
4. Check if there is application code in the warmstart task (under system tasks) that forces a coldstart.
5. Do you use the batteries from ABB or did you buy a different type?
Which Freelance version are you running?
IF the system isn't holding the variables, as You say, then there is no way to write a program, that would hold them. So we need to find what makes You lose Your data first.
Are You sure that all variables return to initial values? For example did You change some initial values to try and see will the variable go to zero or the Initial value? What about Tags? If You have any counter or some other function block with memory in Your application check if the counter value or FB memory also resets on restart (power off and power back on). How about Your application? I understand that after the restart do the CPU still has the program and You does not load anything, only lose the values, right?
Also check all things mentioned by Henkel above.
Inaddition to above to findout/confirm that controller is performing cold start or warmstart after power on, user can write a following simple code in system task under coldSt and warmSt. upon warm or cold start WScount or CScount will get increased by one.
###under warmSt system task####
WScount :=WScount +1;
###under coldSt system task ####
CScount :=CScount +1;
So if controller performs warm start and there is default setting for power fail time then there is somewhere variables are initialsed....
If controller is performing cold start then check power fail settings or battery ... and things mentioned in previous post...
One more information that might be of interest.
In order to determien whether the controller did a warm- or cold start you could do as Sumit proposes. I prefer to look at Freelance Operation. It will tell you in the alarm page whether the controller did a warmstart or a coldstart. If the former you will also get the information how long the controller was not able to control the process.
Note I did not say: how long the power-off lastet!
That is, because the controller needs time to boot and during that time the process is still without control.
Consequently using any duration lower than the controller boot time for the "Max power fail time for warmstart" is of no use and will invariably lead to a coldstart.
The idea behind that is, that your process would allow for a certain time without process control until it reaches a state where it doesn't make sense to just continue as if nothing happened. This time is very short (almost 0 ms) for pressure driven processes and can be into several seconds up to a minute for temperature controlled processes.
This affordable duration without control is what decides if it makes sense that the controller, when back after power down, performs a warmstart or coldstart. But clearly the duration without control is not only the power-off intervall but in addition the time the controller needs to boot up after the power is back.
So the "Max power fail time for warmstart" parameter will be (and has to be) checked against the sum of power-fail duration plus Copntroller boot-up time.
I did a test with a PM802F and found the controller needs between 16 and 18 seconds for boot (the wait time during boot-up trace to enter the IP address configuration was set to 10 seconds, but I id not use the tracing. Still I'm not sure if that has an influence or not). If your process allows for 10 seconds without control and you enter that as the "Max power fail time for warmstart" parameter, then even if the power fails only for 500ms the controller will do a coldstart.