Crimson 3.0 Backing up retentative values

DamianInRochester

Lifetime Supporting Member
Join Date
Jan 2011
Location
Rochester NY
Posts
1,292
I have created some retentative array tags in a G303L to serve as recipe storage. This particular unit does not have compact flash. After the operators have entered all of their recipe data in I would like to make a backup of that data so if the unit ever fails they don't lose their recipes. I don't see a way that I can back up the retentative tag values in Crimson.
 
I believe that you will need a compact flash, to do data backup... The only other way, that I can think of would be to send the data to the PLC... or to do something via serial port.
 
I believe that you will need a compact flash, to do data backup... The only other way, that I can think of would be to send the data to the PLC... or to do something via serial port.

This particular unit can't accomodate a compact flash card. No where to plug one in. Unfortunately the servo controller being used didn't have the available memory for storing the recipe data, which is why I ended up putting it in the HMI. I guess I am wondering now whether doing a project upload would bring the values with it. Worth a try I suppose.

Thanks
 
So I did an "Extract" upload of the entire project. Then I downloaded some other unrelated project to the HMI to clear it out. Then I re-downloaded the project I had uploaded from before and low and behold my values are still there. So it looks as though the upload copies the values of the retentative tags to the development file. The only other explanation is that somehow those tags didn't actually get destroyed when downloading the unrelated application. Unfortunately I don't have another fresh HMI to test the theory. I have to believe though that it is unlikely they would have survived the download.
 
The only other explanation is that somehow those tags didn't actually get destroyed when downloading the unrelated application.
I believe this is what's happening. I'm pretty sure that tag values (whether retentive or not) are not saved with the program database. Retentive tag values are only written to flash memory on 5-minute intervals. (See this thread.) If you downloaded your second application and didn't wait long enough before re-loading the first one, retentive values might be maintained. Try executing a CommitAndReset() after downloading the second to force a flash write. I'm not sure if Crimson does a full or partial flash write so make some 16,000-element retentive arrays to be sure everything is overwritten.
 
Last edited:
I believe this is what's happening. I'm pretty sure that tag values (whether retentive or not) are not saved with the program database. Retentive tag values are only written to flash memory on 5-minute intervals. (See this thread.) If you downloaded your second application and didn't wait long enough before re-loading the first one, retentive values might be maintained. Try executing a CommitAndReset() after downloading the second to force a flash write. I'm not sure if Crimson does a full or partial flash write so make some 16,000-element retentive arrays to be sure everything is overwritten.

John,
Thanks for the tips. I'll give that test a try.
 
I'm not sure how to reset a G303, but I would think that doing a complete wipe, would be the best way to test this...

I didn't think the values saved with the project, but it is cool if it does.
 
I believe this is what's happening. I'm pretty sure that tag values (whether retentive or not) are not saved with the program database. Retentive tag values are only written to flash memory on 5-minute intervals. (See this thread.) If you downloaded your second application and didn't wait long enough before re-loading the first one, retentive values might be maintained. Try executing a CommitAndReset() after downloading the second to force a flash write. I'm not sure if Crimson does a full or partial flash write so make some 16,000-element retentive arrays to be sure everything is overwritten.

OK, so I just followed your suggestions again. Made the new arrays. Used the CommitAndReset() function. Waited 10 minutes. Then I went ahead and re-downloaded the uploaded application from before.

The values are still there. Now I don't know what to think.

Only thing left I can think of to really test this is to pull the battery.
 
From page 11 of the Crimson 3 manual:

Each database created by Crimson is given a unique identifier. This identifier is used upon
download of a new database to determine if the target device should clear its internal memory
and delete any log files recorded to CompactFlash. If the identifier matches that of the
database already in the device, the database is assumed to be merely a different version of the
same file, so the data is retained. Conversely, if the identifiers are different, the data is
cleared. When you use the Save As command on the File menu to save a copy of a database
file, Crimson will ask if you want to allocate a new identifier. Select Yes if this is going to be
a new project, and select No if you are just saving a backup copy of what is essentially the
same database. This will ensure that the target device’s retentive data is cleared or preserved
as is appropriate.
Sounds like your device is not working as documented.
 

Similar Topics

Hey guys, hoping someone here could give me a little advice. I'm working with a CR1000-04000 in Crimson 3.1 and I was interested in adding the...
Replies
4
Views
156
Hi, I'm having an issue in crimson 3.0 when I create a programme using a case statement referencing a fault word that each bit needs to change the...
Replies
5
Views
309
How do you install update on Red Lion Crimson ver 3.1. Do I just need to run the exe file on the host server?
Replies
1
Views
136
Has anyone found a way to convert/replace/update the firmware on old Parker TS80xx series HMIs (i.e. TS8010, TS8006, etc) to accept Crimson...
Replies
0
Views
125
Has anyone setup communications with Red Lion 3.0 MODBUS to Baker Hughes Centrilift GCS VFD? Thanks
Replies
0
Views
99
Back
Top Bottom