S7-1200 & Recipes

[Paul L 0]

I have written a number of programs to use the load memory for recipes. I have followed the datasheet and it works fine! I have an array of a custom data type in a DB with load memory set. And also a DB with a single custom data type. I use the commands  READ_DBL and WRITE_DBL, and all works! The nice thing I found was, it I altered something in the program, the DB in the load memory didn't get reset and kept its data I altered via the HMI, so worked perfect for variables on a machine that was needed when running, and been able to update minor parts of the program without putting all these back to init values was great!

However, SP1 came.... BTW I had been using the original version off the DVD, some of the updates after this, but before SP1, caused havoc with the READ_DBL and WRITE_DBL commands, my once working and compiled code refused to compile after the update......

Back to SP1, I had held back for a while, and now Upd8 is out I went for it! The previous error of compiling had gone, great! But upon testing I have found a problem. I download everything fine. I alter a few parameters that get saved into the load memory via the HMI. All ok! But when I download a minor change elsewhere in the program, the DB in the load memory gets reset. Not what I need.... I haven't done anything to the program to change this, the only change is SP1 UPD8. I have read about retentative, but I need 64k of storage, and not sure it even works as I would need it to.

I will most doubt need to go back to the original install, but leaves me with slightly unstable software, and no option to use newer CPUs etc...

So, just wondering if anyone knows anything that can help!

Many thanks

[pop29684 14]

2 hours ago, Paul L said:

<snip>

But when I download a minor change elsewhere in the program, the DB in the load memory gets reset. Not what I need.... I haven't done anything to the program to change this, the only change is SP1 UPD8. I have read about retentative, but I need 64k of storage, and not sure it even works as I would need it to.

I will most doubt need to go back to the original install, but leaves me with slightly unstable software, and no option to use newer CPUs etc...

<snip>

I really doubt that the newer software is the culprit. When you "download[ed] a minor change" to the program did you selectively download modules or did you blanket load all modules? If you loaded all modules then the DB in question was overwritten by this action. Normally there is no need to reload DBs once they exist in the online project. Strict observance of this practice significantly reduces the very problem you have experienced.

There are a couple of ways (at least) to avoid this problem in the future. 1.) The easiest solution is to upload the DB data from the online project to the offline DB before making any program changes or downloads. (Remember to save the DB after this action!) This, however, is subject to the human frailty of memory. 2.) A more elegant solution that eliminates the need to remember to upload the DB data involves creating an UDT with the same structure, variable names, and variable types as the DB in question. No DB is created by the programmer in the offline project. Instead, you write a routine in a module that checks for the existence of the recipe DB. If it exists, then data is freely read from or written to the DB. If the DB does not exist, the module creates the required DB (only in the online project) using the referenced UDT. Data is read from or written to the DB only after it is created.

By the way, and just to be clear, any time a DB is downloaded to the CPU all data in the online project (CPU) DB is overwritten with the "initial" data of the DB - even if the data is selected to be retentive. Retentive simply means that the data is protected during a power-off event; it does not mean the data is protected from a download. In creating a DB in the S7 software I think it is possible to make it read only. I'm not certain if the TIA Portal software offers this feature or not.