Digital Trends and Trend Storage on Data Change

Hi Chris,
There are some manual steps required to upgrade correctly depending on the features you used in V2.1. These changes may need to be managed manually, on the Wonderware Historian side. For example, if you upgrade from V2.1 to V3.0, any Variable Tags of data type String that were being Historized, will now have a new Wonderware Historian tag created for them, appended with .String. In V2.2 extra support for Digital Variable tags was also added, which appended .Discrete to the end of the Historian tag.
The Trend Tag names will however be unchanged. So there should be no impact there.
Can you describe the back fill feature you require? My understanding is that if the Connector is disconnected (or shutdown) for any period of time, when it starts up, it will request the trend data from the SCADA system from the time of interruption, thus back filling any missing data.
There was a feature in Citect Historian where you could poll a Variable tag for data, and then on disconnect/shutdown it would back fill from the available Trend tag data (which corresponds to the Variable tag). This feature is not available in the Connector, but it is just requesting data from the Trend Server. If there is any missing data, it is likely a bug. I believe all known issues around back filling have been resolved in V3.0 version of the Connector, so I am confident you will get a much better experience.
I also found through my experience with the Connector that you can maximise throughput performance by setting the following parameter on the Citect SCADA Trend servers:
[Trend]
ReadWatchTime=0
On the Deadband subject, I can confirm that this will not take any effect on the number of samples stored by the Trend system. The Trend system will just store the sample value (while applying the deadband) on the defined period. So even if the sample hasn't changed out of the deadband range, the Trend server will just log the previous value again. This is useful if you want to filter out noisey data sources, but not what I guess you are trying to achieve.
You could also look at Windows file compression to save some space. There will be a small hit to read and write performance, but it shouldn't impact the Trend Server.
Kind regards
Olivier

Hi Chris,
There are some manual steps required to upgrade correctly depending on the features you used in V2.1. These changes may need to be managed manually, on the Wonderware Historian side. For example, if you upgrade from V2.1 to V3.0, any Variable Tags of data type String that were being Historized, will now have a new Wonderware Historian tag created for them, appended with .String. In V2.2 extra support for Digital Variable tags was also added, which appended .Discrete to the end of the Historian tag.
The Trend Tag names will however be unchanged. So there should be no impact there.
Can you describe the back fill feature you require? My understanding is that if the Connector is disconnected (or shutdown) for any period of time, when it starts up, it will request the trend data from the SCADA system from the time of interruption, thus back filling any missing data.
There was a feature in Citect Historian where you could poll a Variable tag for data, and then on disconnect/shutdown it would back fill from the available Trend tag data (which corresponds to the Variable tag). This feature is not available in the Connector, but it is just requesting data from the Trend Server. If there is any missing data, it is likely a bug. I believe all known issues around back filling have been resolved in V3.0 version of the Connector, so I am confident you will get a much better experience.
I also found through my experience with the Connector that you can maximise throughput performance by setting the following parameter on the Citect SCADA Trend servers:
[Trend]
ReadWatchTime=0
On the Deadband subject, I can confirm that this will not take any effect on the number of samples stored by the Trend system. The Trend system will just store the sample value (while applying the deadband) on the defined period. So even if the sample hasn't changed out of the deadband range, the Trend server will just log the previous value again. This is useful if you want to filter out noisey data sources, but not what I guess you are trying to achieve.
You could also look at Windows file compression to save some space. There will be a small hit to read and write performance, but it shouldn't impact the Trend Server.
Kind regards
Olivier