How do I keep my old trend data retrievalble and accessible when I update or make modifications on my application project, since I have to do this many times whenever the plant grows up, but I lose the old trend data everytime I update the project ??
Solved! Go to Solution.
This is likely the case if you are storing your Trend files within a subdirectory of the Project directory.
I would advise to configure (in the trend.dbf) your Trend File locations to be outside of your Project directory.
In this way, when the project backups are restored / overwritten, the Trend Files are not touched, and when you launch the runtime again, it can find them appropriately.
thank you sir for response
Trend. dbf contains tag names and the variable tags they connect to plus some other parameter for each tag, I can not find a parameter to be set to change the trend file locations, please advice
trend.dbf also contains a column called FILENAME which is actually the path (folder) where the trend files will be stored.
If you leave this as blank, then it will place them within your Citect.ini configured Data directory (thanks @RoozeeR).
You should read up on the help for these, and configure them as appropriate so that the trend files don't get overwritten with project restores.
Help excerpt from Citect SCADA 2016
By default, Citect SCADA stores trend files in the [DATA] directory (defined by the parameter [CtEdit]Data) on the hard disk where installation occurred. However, you can use the File Name property to specify a different directory for a particular trend file.
For example, if your system includes a large number of trend tags (in excess of 1000), Citect SCADA will perform more efficiently if you distribute the associated trend files across a number of directories. To enable this, you could set the File Name property for a trend tag to the following:
This would store the trend file in a subdirectory (named "Area1") within the [DATA] directory.
It's been working for the majority of our customers... so I've got some confidence that you'll find some guidance on it in the help 😉
The help is your friend...
The DATA directory where trend files are saved is "normally" set by running the Citect SETUP wizard. In the end tis results in a setting in the Citect.INI file (CtEdit - Data parameter).
Hi @RoozeeR This has no impact on the project being restored, as the data folder is located away from project folder, maybe I am missing something, the restored project will not touch the data folder and its contents, then why data will be lost?
Hi @BevanWeiss What I found out is that DATA folder will not be overwritten when the updated backup file be restored, because it is located out side the project folder, this means that defining different folder from the default one for trend data will have no effect of the trend data exsitance, this needs more discussion to be clarified
If the Trend folders are outside the Project folder, and therefore are not being changed during a project restore, then I would suspect that the person doing the project restore may be doing something else also.
Are you able to perform the following:
1) confirm location of trend files matches expectation from DATA and Trend.dbf settings
2) Shutdown Citect runtime
3) Confirm Trend files are still correct in the location expected
4) Restore project backup
5) Confirm Trend files are still correct in the location expected
6) Start Citect runtime
7) Confirm Trend files are still correct in the location expected
As Citect can run Cicode which could technically do whatever it wanted, there is the possibility that something within the Citect project is messing with the Trend files. But I wouldn't expect this.
If you do the steps above it will narrow down where the issue is with the entire process, or where the trend files are being disrupted.
Sorry for delayed reply
I can do the mentioned task with no problem, all files are remains in place
The plant herichary composed of two servers and two clients of which one server is duty and the other one is standby
the files count in DATA folder are not the same in the servers, as it is higher by nine files in the standby server
I do not know if that helps
I don't believe historical trend files are synchronised between trend servers.
So there being a difference in the file count doesn't surprise me.
It seems that it was a user error that was causing the issue you reported in the original post.
I believe that you've now got things all sorted as you say the restore is now not deleting trend files.
I am going to confirm if trend sychronizing happens betwedn two server or not as soon as I can,
as server 1 is the main server, I am going to switch to server 2 to be the duty server and check if historical trend exist and can be displayed
How will you do this test?
I'm afraid that how you think the test will work is going to produce the wrong result.
Of course if you look at trend files currently being produced it will be fine.
What you need to do is 'remove' (i.e. move elsewhere) all the old trend files from one server, and then restart it.
My expectation is that it will not actively retrieve ALL of the old trend files from the online server.
Yes, I dont mean the test you mentioned, I only looking if both server have almost all data by switching dutu server from one another
This is precisely what I mean.
That does not test the trend server synchronisation at all.
Thato tests IO server connectivity, and that both trend servers are currently active.
You'll see here how it's supposed to work:
So to test the synchronisation, you will need to remove trend files from one of the servers.