Beckhoff losing persistent data values

twu026

Lifetime Supporting Member
Join Date
Jan 2008
Location
Auckland
Posts
62
I am using a Beckhoff PLC (CX9010 series) for a batching process control.

There are a lot of parameters (scale factors, preset, setpoints etc) that are criticial to the control logic which I need to store in the PLC.

These variables that I wish to retain have been declared as VAR_PERSISTENT in the PLC.

My problem is that under certain circumstances the data that had been declared as persistent will lose its values and go back to defaults.

After doing some digging I have found out a few things related to the persistent data but there is still a lot of holes in my knowledge.

My understanding is this:

- The variables that are declared as VAR_PERSISTENT get stored on the Bechkoff as a file named TCPLC_T_1.wbp in the TwinCAT\Boot\ directory
- This TCPLC_T_1.wbp file is created everytime TwinCAT is placed into Configure mode OR when the WritePersistentData function block is called in the PLC program.
- When TwinCAT is placed into Run mode, the TCPLC_T_1.wbp is read and renamed to TCPLC_T_1.wb~ (which is suppose to be a backup copy).

Now, as far as I have been able to establish. If the PLC is power cycled with only the backup file (TCPLC_T_1.wb~) in the directory, the persistent data will be lost.

Here comes the question:

How is this persistent data file actually linked to the PLC program?

There must be a way the PLC program links/maps tags to that file.

Now, if I made a change to the PLC program that required a program download (not online change). Does that mean the persistent data file is no longer valid and will not load?

I have noticed that when I did a program download any of the 3 possible things could happen:

- all my persistent data are retained
- all my persistent data goes back to default values
- some of my persistent data goes back to default values and some are retained

As a side question:

When/How does PLC Control decide a full download is required and when an online change is permitted?

When/How does PLC Control decide the offline project does not match the code on the PLC and hence require a full download to go online?

There has been times that I swear I have the latest copy of the code and yet PLC Control refuses to let me go online without a full downloads (which means I risk losing my persistent data).

I personally do not like Windows/PC based control. The concept of the PLC code running as an app in a multi-purpose operating system with the data being stored as files in directories.
 
As far as I know the Persistant memory does not work on Windows CE because it requires an orderly shut down in order to write the data to the file. I have never used the UPS for the CX series which may allow it to work.

To save data that needs to survive through a power cycle, I have always used the Non-Volatile Ram (NOVRAM). There are two way to do this.

The first is to assign an address (%Qxx) to the variables that need to save their values and then link them to NOVRAM using the System Manager. There is a problem with this on the CX controllers. The NOVRAM write cycle is slow which will cause the CPU usage to jump above 60% and even max out to 80%.

The second way, which I prefer is to use the FB_NovRamReadWriteEx function block. I either use a TON or configure another Task that scans typically every 2 seconds and writes the data to NOVRAM. On a first pass scan during restart, I use the function block to read the NOVRAM.
 
I am using a Beckhoff PLC (CX9010 series) for a batching process control.

There are a lot of parameters (scale factors, preset, setpoints etc) that are criticial to the control logic which I need to store in the PLC.

These variables that I wish to retain have been declared as VAR_PERSISTENT in the PLC.

My problem is that under certain circumstances the data that had been declared as persistent will lose its values and go back to defaults.

After doing some digging I have found out a few things related to the persistent data but there is still a lot of holes in my knowledge.

My understanding is this:

- The variables that are declared as VAR_PERSISTENT get stored on the Bechkoff as a file named TCPLC_T_1.wbp in the TwinCAT\Boot\ directory
- This TCPLC_T_1.wbp file is created everytime TwinCAT is placed into Configure mode OR when the WritePersistentData function block is called in the PLC program.

Correct so far, also, when the PLC does an orderly shutdown, either from the start menu, or as Archie mentioned, with a UPS.

Here's a detailed description of Retain and Persistent variables...
http://infosys.beckhoff.com/content/1033/tcplccontrol/html/tcplcctrl_editorvardecl.htm
Scroll towards the bottom of the page.

- When TwinCAT is placed into Run mode, the TCPLC_T_1.wbp is read and renamed to TCPLC_T_1.wb~ (which is suppose to be a backup copy).

Now, as far as I have been able to establish. If the PLC is power cycled with only the backup file (TCPLC_T_1.wb~) in the directory, the persistent data will be lost.

See the link above, there's two files, the last, and the next too last. There's also a set of bits you can and should check in your code to make sure that you got good data from the files. This data is retrieved before TwinCAT starts. One other thing that gets people is that the system writes the files back to zero on startup, so in your code, on the first scan, you should check to make sure you loaded the persistants correctly, then call FB_WritePersistant one time again to get them "committed" back into the file. The logic being here thatif there's a problem you'll want to alert the operator right away before you intiate machine operation.

Here comes the question:

How is this persistent data file actually linked to the PLC program?

There must be a way the PLC program links/maps tags to that file.

Now, if I made a change to the PLC program that required a program download (not online change). Does that mean the persistent data file is no longer valid and will not load?

I have noticed that when I did a program download any of the 3 possible things could happen:

- all my persistent data are retained
- all my persistent data goes back to default values
- some of my persistent data goes back to default values and some are retained

Hope these questions are all answered by the link above.

As a side question:

When/How does PLC Control decide a full download is required and when an online change is permitted?

Not sure I know, sorry.

When/How does PLC Control decide the offline project does not match the code on the PLC and hence require a full download to go online?

There has been times that I swear I have the latest copy of the code and yet PLC Control refuses to let me go online without a full downloads (which means I risk losing my persistent data).

The PLC compares the compiled version of the program on the development PC with the compiled version on the target, so if you move just the .PRO file onto a new development PC and do a recompile, it's just like doing a "Rebuild All", and you are in effect starting over. The feature "File / Save/Mail Archive" will allow you to save all the files together in one zip file, that's the best way to move a program from one development PC to another.

I personally do not like Windows/PC based control. The concept of the PLC code running as an app in a multi-purpose operating system with the data being stored as files in directories.

Well, to each is own. However, be aware that the architects of TwinCAT are aware of the pitfalls associated with PC based control, and have made provision to keep the data integrity.

The long and the short of it, if you absolutely must have data integrity, the best solution is to use two methods, Persistant data, and the NOVRAM that Archie has already suggested.

Best of luck.
 
Thanks for all the help/advice guys. The problem I have is that there is no Beckhoff tech support in New Zealand and Beckhoff's documentation is far from complete.

We originally tried to use the NOVRAM method, but like Archie mentioned we experienced high CPU loads.

Thanks Archie, I will look into the FB_NovRamReadWriteEx, sounds like a potential work around.

Thanks Steve, I will make sure to use the "Save/Mail Archive" method to move files between development PC.
 
Last edited:
Hi twu026,

I had exactly the same questions as you with developing our product with Twincat!!

I dont use a UPS or NOVRAM as limited, I just create a persistent data backup every hour and as soon as the power is cycled, on the first scan, create a new persistent data file as I found that once the TCPLC_T_1 has been read on boot, it cant be used for the next boot for some strange reason so simply recreate it!

I have some sample code and can help you out if need more info

Regards

Matt
 
I dont use a UPS or NOVRAM as limited, I just create a persistent data backup every hour and as soon as the power is cycled, on the first scan, create a new persistent data file as I found that once the TCPLC_T_1 has been read on boot, it cant be used for the next boot for some strange reason so simply recreate it!
One thing to be cautious about is not to write to the flash memory too much. They do have limited write cycles (typical 1,000,000). If they are written to every few seconds, you can kill the memory/flash card within months.
 
Archie is right, Compact Flash cards have limited write cycles. Beckhoff sources CF cards that have a "wear leveling" feature that makes the cards last longer. The inexpensive consumer-grade cards don't have this feature, so don't last as long.

Archies advice about using a slow task to initiate NOV writes is also a recommended "best practice" for TwinCAT. Trying to do it over and over again in a fast task will cause the high CPU usage, as you've already seen.
 
i needed to make some inputs and output of Function Blocks remanent so i couldnt use the persistent variable declaration on this one, so i tried the NOVRAM like this...
VAR INPUT
input1 AT %Q : REAL;
END_VAR

so when i rescan my project in the hw manager i get these variables as many times as i have called this function block.
Then i link them to the NOVRAM of the same type and made sure the Init IO is checked.
then i do the restart and still the variables are reset to init value.
For some reason variables inside a function block cant be made remanent.

Somebody must have encountered this problem..?
 
i needed to make some inputs and output of Function Blocks remanent so i couldnt use the persistent variable declaration on this one, so i tried the NOVRAM like this...
VAR INPUT
input1 AT %Q : REAL;
END_VAR

so when i rescan my project in the hw manager i get these variables as many times as i have called this function block.
Then i link them to the NOVRAM of the same type and made sure the Init IO is checked.
then i do the restart and still the variables are reset to init value.
For some reason variables inside a function block cant be made remanent.
A function block defnition by itself is only a definition and has no place in memory. To use the function block, you declare an instance then the memory is allocated. Every instance has its own memory space, therefore different variable values. When you refer to "calling a function block", you must mean that you are executing unique instances.

To give you a quick solution, try defining an address for the declaration of the instance of the function block. Then link that instance to your NOVRAM.

VAR
fb1 AT %Q0:funcblockdef;
END VAR
 
Although the compiler will allow you to put Is and Qs in a function block variable declaration, it is not recommended.

Instead, I think you should set up the Is and Qs as Variables in the Calling POU, then pass them as inputs and outputs to the Function Block. That way, you can use the same FB for non-persistant memory, too.
 
Thanks for the quick response!
-Archie
That is a quick sollution indeed.

-SteveMaves
i have to make these input and output of some blocks remanent because sometimes a setpoint (in my case an input variable of a FB) is linked to a constant or another variable. But in other (most) cases its written to from the HMI. And my HMI faceplates are based on the function block.

In the meanwhile i made a backup sollution if anyone interests.

VAR_INPUT
var1 AT %Q* : REAL ;
END_VAR
VAR_OUTPUT
var2 AT %Q* : REAL ;
END_VAR

becomes

VAR_INOUT
var1 AT %Q* : REAL ;
var2 AT %Q* : REAL ;
END_VAR

In case a constant is linked to var1 for example there i no problem.
And when the inout parameter is not linked , when operators fill in the value, i can attach the inout parameter to the writetonovram FB wich makes it remanent on reboot.
Another benifit is that with some extra programming u can make it write to NOVRAM , not cyclic, but on change. wich reduces CPU usage.
 
Last edited:
Hi Archie,

Could you please send your sample code for FB_NovRamReadWriteEx to me.

My mail is coa_eng at yahoo.com

I have application need to save many parameters during power off.
 

Similar Topics

Hi everyone, This is my first time posting, so please forgive any omissions or mistakes. I am attempting to control the velocity of a stepper...
Replies
18
Views
741
Hello sameone have Beckhoff PLC Siemens Sinamics V90 configuration example?
Replies
0
Views
83
hello, I am using Beckhoff with TwinCAT3 and when I change or add some new hardware or for any reason, there is a mismatch in the real hardware vs...
Replies
1
Views
109
I have a Beckhoff CX7000 IPC with some digital I/O built-in and I additionally need two analog inputs 0-10V. Can I install both Ethernet terminals...
Replies
4
Views
182
Hello, We are currently working on a project that involves connecting a linear potentiometer to our Beckhoff PLC. After researching, we...
Replies
2
Views
176
Back
Top Bottom